Microsoft Entra Permissions Management に AWS アカウントをオンボードしてみます。AWS アカウントの追加方法には AWS Organizations 配下のアカウントをすべて対象にする方法と AWS アカウント ID を個別に指定して追加する方法があり、今回は AWS アカウントを個別に追加する方法を試しています。
過去にも Permissions Management に AWS アカウントを追加する方法はブログ化されています。試用版を利用する方法や AWS Organizations 配下のアカウントを追加する方法が紹介されています。
AWS アカウントをオンボード
AWS のオンボードは次のドキュメントに掲載されているため、この情報を参考に設定していきます。
ざっくり分けると次の 3 つの設定に分かれていたので、各内容を見出しを分けて記載しています。オプション設定など下記以外の内容も含まれますが、主要な 3 つの設定に分けることにしました。
- Entra ID 側でアプリの登録
- AWS 側で ID プロバイダ作成
- AWS 側で オンボード用リソース作成
1. Entra ID 側でアプリの登録
Permissions Management のコンソールから歯車マークを選択して「Data Collectors」タブの「AWS」タブから「Create Configuration」を実行します。
始めに Entra ID へのアプリの登録を実施します。
今回は「Azure App Name」を入力済みのデフォルトの値mcimcienem-aws-oidc-connectorで構築することにしました。
目のマークをクリックすることで Entra ID で実行するコマンドを確認できます。
#use this script for Azure version <3.7
az ad app create --display-name "mciem-aws-oidc-connector" --identifier-uris "api://mciem-aws-oidc-app"--available-to-other-tenants false
#use this script for Azure version >3.7
az ad app create --display-name "mciem-aws-oidc-connector" --identifier-uris "api://mciem-aws-oidc-app" --sign-in-audience AzureADMyOrg
#PowerShell Script
New-AzureADApplication -DisplayName "mciem-aws-oidc-connector" -IdentifierUris "api://mciem-aws-oidc-app" `Azure ポータルの CloudShell から実行した結果です。
> az ad app create --display-name "mcimcienem-aws-oidc-connector" --identifier-uris "api://mciem-aws-oidc-app" --sign-in-audience AzureADMyOrg
{
"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#applications/$entity",
"addIns": [],cation with optional claims
"api": {
"acceptMappedClaims": null, mytestapp --identifier-uris https://mytestapp.websites.net --app-roles @m "knownClientApplications": [],
"oauth2PermissionScopes": [],
"preAuthorizedApplications": [],
"requestedAccessTokenVersion": nullure/ad/app#az_ad_app_create
}, more about the command in reference docs
"appId": "058f17be-fce3-40a7-a7ac-2c625example",
"appRoles": [],>
"applicationTemplateId": null,
"certification": null,zADAppPermission -ObjectId 9cc74d5e-1162-4b90-8696-65f3dexample -ApiId 00000003-0 "createdDateTime": "2024-03-12T05:40:05.3424278Z",7d-491f-a6b8-5f174example
"defaultRedirectUri": null,
"deletedDateTime": null,
"description": null,
"disabledByMicrosoftStatus": null,
"displayName": "mcimcienem-aws-oidc-connector",
"groupMembershipClaims": null,
"id": "636277a8-f6d6-4653-9523-3feafexample",
"identifierUris": [
"api://mciem-aws-oidc-app"
],
"info": {
"logoUrl": null,
"marketingUrl": null,
"privacyStatementUrl": null,
"supportUrl": null,
"termsOfServiceUrl": null
},
"isDeviceOnlyAuthSupported": null,
"isFallbackPublicClient": null,
"keyCredentials": [],
"notes": null,
"optionalClaims": null,
"parentalControlSettings": {
"countriesBlockedForMinors": [],
"legalAgeGroupRule": "Allow"
},
"passwordCredentials": [],
"publicClient": {
"redirectUris": []
},
"publisherDomain": "example.onmicrosoft.com",
"requestSignatureVerification": null,
"requiredResourceAccess": [],
"samlMetadataUrl": null,
"serviceManagementReference": null,
"servicePrincipalLockConfiguration": null,
"signInAudience": "AzureADMyOrg",
"spa": {
"redirectUris": []
},
"tags": [],
"tokenEncryptionKeyId": null,
"uniqueName": null,
"verifiedPublisher": {
"addedDateTime": null,
"displayName": null,
"verifiedPublisherId": null
},
"web": {
"homePageUrl": null,
"implicitGrantSettings": {
"enableAccessTokenIssuance": false,
"enableIdTokenIssuance": false
},
"logoutUrl": null,
"redirectUriSettings": [],
"redirectUris": []
}
}Azure ポータルからも作成したアプリを確認できました。
2. AWS 側で ID プロバイダ作成
次に、AWS 側で OIDC の ID プロバイダを作成します。ID プロバイダを作成する CloudFormation テンプレートを Permissions Management からダウンロードできるため、そのテンプレートを AWS 側で展開するだけとなります。IAM ロール名となる「OIDC Account Role」はデフォルトの値で作成しています。
AWS 側でダウンロードした CloudFormation テンプレートを展開します。マネジメントコンソールの CloudFomation のスタックメニューから「スタックの作成」を実施します。
ダウンロードしたテンプレートをアップロードします。なお、Permissions Management でダウンロードした際のファイル名はmciem-aws-oidc.yamlでした。
スタック名はテンプレート名を同じ名前にしました。パラメータはデフォルトのまま展開します。
このまま「ステップ 4」までデフォルトの設定のまま進めていき、最後に IAM リソースが作成されることを承認するチェックをして「送信」します。
ステータスがCREATE_COMPLETEになれば展開完了です。
ID プロバイダとそれに紐づく IAM ロールが作成されています。
IAM ロールの権限は次の通りであり、STS サービスに対する権限があります。AssumeRole 権限により Permissions Management の対象としてオンボードする AWS アカウントにアクセス（スイッチロール）できます。
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"sts:AssumeRole",
"sts:AssumeRoleWithSAML",
"sts:GetAccessKeyInfo",
"sts:GetCallerIdentity",
"sts:GetFederationToken",
"sts:GetServiceBearerToken",
"sts:GetSessionToken",
"sts:TagSession"
],
"Resource": [
"*"
],
"Effect": "Allow"
}
]
}3. AWS 側で オンボード用リソース作成
次に、Permissions Management にオンボードする AWS アカウントの設定をするのですが、その前に Logging Account の設定を確認します。この設定は CloudTrail のイベントログを集約しているアカウントがある場合にその集約アカウントを指定できるオプションの設定です。今回の環境では CloudTrail のイベントログは各アカウント内の S3 バケットに保管している環境であるため、この設定はスキップして「Next」を実行します。
次の画面でオンボードする AWS アカウントの設定をします。
「Manage Authorization Systems」の設定において、個々の AWS アカウントを指定して追加したい場合は「Enter Authorization Sytems」を選択することで指定できましｔ。「Manage Authorization Systems ( Required ) 」欄に最大 100 アカウントまで記載できます。今回は ID プロバイダを作成したアカウントと同一のアカウントだけを設定しています。
なお、次のドキュメントに 3 種類の設定の違いの説明があります。
AWS Organizations の管理アカウントの設定もあります。メンバーアカウントを自動で検出できるように設定のようです。今回は個々のアカウントを指定して追加するため、本設定はスキップしました。
最後にオンボードする AWS アカウント側の設定情報です。ID プロバイダのときと同様に CloudFormation テンプレートをダウンロードして実行するのみです。「Member Account Role」は作例される IAM ロールの名前となり、今回のデフォルトの値で作成します。
ダウンロードした CloudFormation テンプレートを AWS 側で展開します。
ID プロバイダのときと同様に CloudFortmaiton で「スタックの作成」を実行して、ダウンロードしたテンプレートをアップロードして進めます。ダウンロードしたテンプレートのファイル名はmember-account-script.yamlでした。
パラメータの指定では、「CloudTrail Bucket Name」に CloudTrail のログを保管している S3 バケットを入力する必要があります。他のパラメータはデフォルトで進めます。「OIDC Provider Account ID」には Permissions Management で設定した ID プロバイダを展開した AWS アカウント名が入力されているはずです。
なお、「Enable Controller」パラメータをtrueにすることで、Permissions Management に書き込みができる権限を与え、自動的な修復機能が利用できるようになるようです。
このまま最後までデフォルト設定で進めていき、IAM リソースの作成を確認するチェックを実施して展開します。
IAM ロールとそれに紐づく IAM ポリシーが作成されています。
IAM ロールの信頼ポリシーにおいて OIDC の ID プロバイダを作成した AWS アカウントが信頼されています。アカウント ID をマスクしていますが、ID プロバイダのあるアカウント ID となっていました。
{
"Version": "2008-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/mciem-oidc-connect-role"
},
"Action": "sts:AssumeRole"
}
]
}許可ポリシーとしては AWS 管理ポリシーのSecurityAuditと次の CloudTrail ログが保管されている S3 バケット閲覧権限が付与されていました。
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::example-cloudtrail-example*",
"arn:aws:s3:::example-cloudtrail-example*/*"
],
"Effect": "Allow"
}
]
}
Permissions Management の設定に戻り、最後の設定をします。
AWS で利用しているユーザー管理のための ID プロバイダの指定設定があります。ID プロバイダを設定しておくとそれらについても Permissions Management が読み取れるようです。今回は個々のアカウントを対象としていることからスキップするために「None」を指定して進みます。
最後に設定内容を確認して問題なければ「Verify Now & Save」を実行して完了です。
設定後の確認
設定後、しばらく待つとステータスがOnboardedになりました。
ANALYTICS 画面にも反映されていることを確認できました。
さいごに
Microsoft Entra Permissions Management に AWS アカウントをオンボードする機会があったため、試してみました。AWS 側の設定が CloudFormation で用意されており、簡易化されている点がよかったです。
また、今回は設定をスキップしましたが、Permissions Management に AWS IAM Identity Center を連携するブログもありますので紹介します。
以上、どなたかのご参考になれば幸いです。
28
