こんにちは！たつみんです！
AWSマネジメントコンソールへのSSOをOktaで実施しようとBrowse App CatalogからAWSと検索するとSAMLに対応したAWS IAM Identity CenterとAWS Account Federationの2つが確認できます。
この記事ではそれぞれの設定方法に触れながら最終的にどちらがおすすめか考えてみました。
- 2023.10.02 アカウントフェデレーション方式のAWSサインインエンドポイント(リージョン)を指定する方法を追加しました。
3行まとめ
- AWS Account Federation方式は煩雑な印象だよ
- 公式CLIツール AWS CLI v2が使えるのはAWS IAM Identity Center方式だよ
- 特別な理由がない限りAWS IAM Identity Center方式がおすすめだよ
AWS IAM Identity Center方式
特徴
- OktaではSSOとユーザーとグループのProvisioningを行う
- AWS側でProvisioningされたユーザーに対してAWSアカウントを割り当てを行う
- Okta管理者とAWS管理者それぞれ役割分担が容易
- AWSアカウントを事前に作成しておく必要がある
SSO設定
- Browse App CatalogからAWS IAM Identity Centerを検索しAdd integrationをクリックします。
- Application labelはそのままとし、Doneをクリックします。
- Sign onタブに移動し、View Setup Instructionsをクリックします。
以降はView Setup Instructionsの内容に沿って設定を進めます。
- Sign onタブの下部にあるSAML Signing Certificates内のアクションからView IdP metadataをクリックします。
- 別タブで以下のような内容が表示されます。この内容部分をコピーし、テキストエディタ等に貼り付け、metadata.xmlとしてファイル保存します。
- AWSマネジメントコンソールにアクセスし、サービス>セキュリティ、ID、およびコンプライアンスからIAM Identity Centerをクリックします。
- リージョンを確認し、問題がなければ有効にするをクリックします。
- 表示される推奨されるセットアップ手順のステップ1 アイデンティティソースを選択をクリックします。
- アクションからアイデンティティソースを変更をクリックします。
- 外部IDプロバイダーを選択し、次へをクリックします。
- 表示されている以下の2つを値をOkta Sign OnタブのAdvanced Sign-on Settings内にそれぞれの項目に貼り付けけて保存します。
IAM Identity Center Assertion Consumer Service (ACS) の URL
IAM Identity Center の発行者 URL
さらにAWS側のIdP SAMLメタデータに手順5.で保存したmetadata.xmlファイルを選択し、次へをクリックします。 - 以下の画面で指示に従い承諾と入力し、アイデンティティソースを変更をクリックします。
- 成功すると以下のようにアイデンティティソースを IAM Identity Center から外部 ID プロバイダー (IdP) に正常に変更しました。と表示されます。
Provisioning設定
- AWS側の設定画面に表示されている自動プロビジョニングの有効にするをクリックします。
- 以下のようにSCIMエンドポイントとアクセストークンが表示されます。
このトークンは有効期限が1年間のため定期的なローテーションが必要となります。
- OktaでProvisioningタブに移動し、Editをクリック後にEnable API integrationにチェックを入れBase URLに手順2.のSCIMエンドポイントを貼り付けます。この時に/v2/から最後の/を削除し、/v2とする必要があります。
API Tokenに同じく手順16.のアクセストークンを貼り付けます。
- Test API Credentialsをクリックし、以下のようにAWS IAM Identity Center was verified successfully!と表示されたら、Saveをクリックします。
- To AppでCreate UsersとUpdate User Attributesについてチェックを入れ、Saveをクリックします。
Deactivate Usersについては必要に応じてチェックを入れますが、動作確認後にするほうが無難です。
- Assignmentsタブでユーザーをアサインします。
- 次にPush Groupsでグループを指定します。
ここでは事前に作成しておいたAWS Administrator Access GroupとAWS Read Only Access Groupという2つのグループを指定しています。
- AWS IAM Identity Center上にユーザーとグループが作成されていることを確認します。
AWSアカウントとの紐付け
ここまでの作業によってAWS IAM Identity Center上にユーザーやグループは作成されていますが、AWSアカウントとは紐付けされていません。
実際にこの段階ではOktaからSSOを実施するとSSO自体は成功しますがAWS側で利用できるリソースがないため以下のようにYou do not have any applicationsと表示されます。
そこで以下の手順でOktaユーザーをAWSアカウントとの紐付けを行います。
ここではあらかじめプロダクトごとに開発環境、ステージング環境、本番環境を想定したAWSアカウントを事前に作成しています。
- IAM Identity Centerのマルチアカウント許可のAWSアカウントに移動し、割り当てを行いたいAWSアカウントにチェックを入れ、ユーザーまたはグループを割り当てをクリックします。
- 割り当てをしたいグループを選択し、次へをクリックします。
この画面ではユーザータブに移動し、ユーザーを個別に指定することもできます。
- 選択したグループに対して割り当てを行う許可セットを選択し、次へをクリックします。
選択すべき許可セットがない場合は許可セットの作成を実行します。
- 確認画面で内容を確認後、送信をクリックします。
- 以下のようにAWSアカウントに許可セットが適用されていることを確認します。
- 手順1.から手順4.までを繰り返し必要なAWSアカウントとグループ(もしくはユーザー)と許可セットの紐付け作業を実施します。
動作確認
- OktaダッシュボードからAWS IAM identity Centerをクリックします。
- 以下のようにAWS Accountをクリックします。
- 利用できるAWSアカウントが表示されるのでクリックします。
- さらに許可セットが表示されるのでクリックします。
- マネジメントコンソールが表示されます。
CLIについて
AWS CLI v2を利用します。まずは以下を参考にインストールからしましょう。
AWS CLI v2のインストールが完了したら以下のようにターミナルからaws configure ssoを実行し、SSOに必要な情報を入力します。
$ aws configure sso SSO session name (Recommended):my-sso-okta SSO start URL [None]: https://example.awsapps.com/start SSO region [None]:ap-northeast-1 SSO registration scopes [sso:account: access]: sso: account: access
この時に必要なstart URLやregionの情報はIAM Identity Centerのダッシュボードに記載されている情報を利用します。
コマンドを実行するとブラウザが立ち上がります。すでにOktaにログイン済みで追加認証の必要性がなければ以下のような画面が表示されます。ログインをしていない状態もしくは認証ポリシー設定によって追加認証が求められた場合は認証操作を行います。
認証操作が完了するとターミナル上では以下のように利用できるAWSアカウントが表示されますので選択し、Enterをします。
There are 2 AWS accounts available to you. |> ProductA-Stg, tatsumi+ProductA-Stg@cloudnative.co.jp (898354487792) ProductA-Dev, tatsumi+ProductA-Dev@cloudnative.co.jp (738860711435)
次にそのAWSアカウントに紐づく許可セットが表示されますので選択し、Enterをします。
There are 2 AWS accounts available to you. Using the account ID 738860711435 There are 2 roles available to you. > ReadOnlyAccess AdministratorAccess
次にプロファイルを作成するためにデフォルトとして指定するclient Regionやoutput formatそして名前を入力し、Enterをします。
[CLI default client Region [None]: ap-northeast-1 [CLI default output format [None]: json [CLI profile name [ReadOnlyAccess-738860711435]: ProductA-Dev_ReadOnlyAccess
作成されたプロファイルについてget-caller-identityコマンドで確認してみます。
$ aws st get-caller-identity --profile ProductA-Dev_ReadOnlyAccess
{
"UserId": "AROA2YB4HXYFTSSLDDOJC:tatsumi@cloudnative.co.jp",
"Account": "738860711435"
"Arn": "arn: aws: sts:: 738860711435:assumedrole/AWSReservedSSO_ReadOnlyAccess_19df826175ceac56/tatsumi@cloudnative.co.jp"
}
次回以降は以下のようなコマンドを実行することでプロファイルに基づいた内容でCLIを利用することが可能となります。
$ aws sso login --profile ProductA-Dev_ReadOnlyAccess
サインアウトする場合は以下のコマンドを実行します。
$ aws sso logout
AWS Account Federation方式
特徴
- Okta側でアサイン時に利用させるSAML User Roleを指定する
- SAML User Roleの作成と反映が若干手間
- Okta管理者とAWS管理者の連携が重要
- CLIツールに課題あり
SSOアプリの作成
- Browse App CatalogからAWS Account Federationを検索しAdd integrationをクリックします。
- Application labelはそのままとし、Doneをクリックします。
なお、Your AWS Login URLはSAML時には利用されないためデフォルト値のままとしています。
- Sign onタブに移動し、Sign on methodsをSAML 2.0を選択し、View Setup Instructionsをクリックします。
以降はView Setup Instructionsの内容に沿って設定を進めます。
- 手順にあるMetadata DocumentのURLをブラウザで開きます。
- この内容部分をコピーし、テキストエディタ等に貼り付け、metadata.xmlとしてファイル保存します。
- AWSマネジメントコンソールにアクセスし、サービス>セキュリティ、ID、およびコンプライアンスからIAMをクリックします。
- 左側のメニューからID プロバイダをクリックします。
- プロバイダを追加をクリックします。
- プロバイダのタイプをSAMLを選択し、プロバイダ名はOktaなどわかりやすい名前を入力します。
メタデータドキュメントに手順5.で作成したmetadata.xmlファイルを選択し、プロバイダを追加をクリックします。
- 以下のようにIDプロバイダが作成されます。プロバイダ名のOktaをクリックします。
- ARNが表示されますのでこれをコピーし控えておきます。
SAML User Role設定
- AWS IAM画面の左側のメニューからロールをクリックし、利用したいロールがある場合はそのロール名をクリックします。
ここでは新規作成を行うため、ロールを作成をクリックします。
- 信頼されたエンティティを選択でSAML 2.0 フェデレーションを選択し、Oktaを選択し、プログラムと AWS マネジメントコンソールへのアクセスを許可するを選択し、次へをクリックします。
- 許可を追加で許可ポリシーを選択し、次へをクリックします。
ここではReadOnlyAccessを選択し進めています。
- ロール名を入力します。また、信頼されたエンティティを選択するで以下のようになっていることを確認し、ロールを作成をクリックします。
"Federated":<SSOアプリの作成の手順11.で確認したARN>
- 一覧画面で作成したロールが表示されていることを確認します。
API設定
ここではSAML User Role情報をOktaへ連携するAPIを利用するための設定を行います。
- AWS IAM画面の左側のメニューからユーザーをクリックし、ユーザーを追加をクリックします。
- ユーザー名を入力し、次へをクリックします。
- 許可の設定でポリシーを直接アタッチするを選択し、ポリシーの作成をクリックします。
- 新しいタブで開いたポリシーエディタをJSON形式に変更し、View Setup Instructionsに記載の内容に沿って以下の画像のように設定をし、次へをクリックします。
- ポリシー名を入力し、ポリシーの作成をクリックします。
- ユーザー作成のタブに戻り、許可ポリシーの更新ボタンをクリックします。
- 作成したポリシー名で検索し、選択後に次へをクリックします。
- 対象ユーザーと許可ポリシーに誤りがないことを確認し、ユーザーの作成をクリックします。
- 以下のようにユーザーが作成されたことを確認します。
- 作成されたユーザーをクリックし、セキュリティ認証情報タブに移動します。
- アクセスキーの項目でアクセスキーの作成をクリックします。
- 主要なベストプラクティスと代替案にアクセスするについて該当しそうなものを選択します。
選択肢によって代替案を提案されることもありますが、アクセスキーが必要なため次へをクリックします。
- 説明タグについては必要であれば設定し、アクセスキーを作成をクリックします。
オプションのため今回は何も入力せずに進めました。
- 表示されるアクセスキーとシークレットアクセスキーを控えておきます。CSVファイルでダウンロード可能なため念の為ダウンロードし、完了をクリックします。
アカウントフェデレーション設定
- Okta管理画面のAWS Account Federationアプリの画面に戻ります。
- Sign onタブのIdentity Provider ARNにSSOアプリの作成の手順11.で確認したARNを入力し、Save をクリックします。
- Provisioningタブに移動し、Configure API Integrationをクリックします。
- Enable API integrationにチェックを入れることでAccess KeyとSecret Keyを入力できるようになりますので、API設定の手順14.で控えておいた値を入力します。
- Test API Credentialsを実行し、以下のように
AWS Account Federation was verified successfully!となったことを確認し、Saveをクリックします。
- ProvisioningタブのTo Appへ移動し、Create UsersとUpdate User Attributesにチェックを入れ、Saveをクリックします。
なお、この設定は通常のProvisioning設定によるユーザー作成や属性の更新を行うためではなくAPIを活用するために必要な操作となります。
- ユーザーをアサインします。この時に、SAML User Roles設定で作成した項目が表示されていますので選択します。
動作確認
- OktaダッシュボードからAWS Account Federationをクリックします。
- アサイン時にSAML User Rolesが単一である場合はそのままAWSマネジメントコンソールが表示されます。
もし、アサイン時にSAML User Rolesを何も選択をしていない場合は以下のようにNot authorized to perform sts:AssumeRoleWithSAMLというエラーが発生します。
SAML User Roleを追加する場合
まず、SAML User Role設定の操作を繰り返します。次にOktaのアサイン画面で追加したSAML User Roleを表示するために以下の操作が必要となります。
- Okta管理画面でアプリケーションの一覧画面に移動し、MoreからRefresh Application Dataをクリックします。
- アプリケーションAWS Account FederationのAssignmentsタブで既存ユーザーの編集ボタンをクリックすると以下のように追加されたSAML User Roleが表示されるようになります。
- 実際に複数のSAML User Roleを割当てた場合にSSOを実行すると以下のようにSAML User Roleを選択する画面が表示されるようになります。
AWSサインインエンドポイント(リージョン)を指定する方法
AWS Account FederationをAWSやOktaのドキュメントを参照してセットアップするとAWSサインインエンドポイントが米国東部 (バージニア北部)となります。AWS Connectインスタンスなどがアジアパシフィック (東京)にある場合はレイテンシが発生することがあるため、AWSサインインエンドポイントにアジアパシフィック (東京)を追加します。
AWSサインインエンドポイントの情報は下記を参照します。今回はアジアパシフィック (東京)なのでエンドポイントap-northeast-1.signin.aws.amazon.comを必要な箇所に追加します。
具体的な追加の手順は以下を参考に進めました。
検証した手順は以下のとおりです。
SSOアプリの作成の手順3.でAdvanced Sign-on Settings内のACS URL (optional & only relevant to SAML SSO)にhttps://ap-northeast-1.signin.aws.amazon.com/samlを設定します。
SAML User Role設定の手順4.で作成した信頼されたエンティティの信頼ポリシーを編集し、以下のようにSAML:audにhttps://ap-northeast-1.signin.aws.amazon.com/samlを追記します。もちろん複数のSAML User Roleを設定しているう場合は必要なSAML User Roleについて同じ操作を実施します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::199446661983:saml-provider/Okta"
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:aud": [
"https://signin.aws.amazon.com/saml",
"https://ap-northeast-1.signin.aws.amazon.com/saml"
]
}
}
}
]
}
CLIについて
以下の内容によればOktaではAWS SSO(AWS IAM Identity Centerの旧名称)を利用している場合にAWS CLI v2をサポートしていると明言されていますが、AWS Account Federationの場合については言及されていません。
そのため非公式ツールとしてsaml2awsといったツールが代替候補として上がりますが、MFAにおけるNumber Challengeに対応できていないなど完全な状態ではありません。
そのため本ブログ記事ではsaml2awsの詳細については割愛します。
まとめ
AWS IAM Identity Center方式とAWS Account Federation方式について設定手順を確認しながら一通り見てきました。それぞれの良さがありつつもAWS Account Federation方式ではSAML User Roleが追加される度にアサインの調整が必要なためやや煩雑な印象を受けました。
AWS Organizationsを活用しAWSアカウントを管理するといった事例をよく聞くこともあるため、AWS IAM Identity Center方式のほうが相性がいいのではないでしょうか。また、CLIにおいてもAWS CLI v2の利用を前提とするならAWS IAM Identity Center方式を採用するほうが幸せなのではないかと思います。
これまでどちらの方式も検証でちょっとやってみたことはありましたが比較を行う前提であらためて検証を行ったことでより理解が深まった様に思います。特にAWSの考え方については慣れていない部分が多かったので最初は戸惑うこともありましたがSSOを実現するという観点では大枠を理解できるようになりました。
この記事が同じような悩みを抱える情シス担当に届くといいなと思っています。
それではまた別の記事で?
