どうも、ちゃだいん（@chazuke4649）です。
AWS CloudFormation StackSets にてAWS Organizations 統合のための「信頼されたアクセス有効/無効化」が API（つまりSDK/CLI経由）で実行可能になりました。
AWS CloudFormation StackSets launches APIs to allow programmatic trust access with AWS Organizations
Activate trusted access with AWS Organizations - AWS CloudFormation
どういうこと？
信頼されたアクセスの操作は「Organizaitons側」からではなく「各サービス側」から行うことが推奨
前提として、Organizations環境で、とあるAWSサービスにてOrganizationsのマルチアカウント統制機能を借りて一元集中的に管理・運用したい場合、そのAWSサービス（CloudFormation, Security Hub, AWS Config etc）と、Organizationsの間で「信頼されたアクセス」を有効化する必要があります。
基本的には以下ドキュメントの一覧がOrganizations連携可能なAWSサービスであり、「信頼されたアクセスをサポート」がYESになっているサービスにはその有効化作業が必要と思ってよいでしょう。
AWS services that you can use with AWS Organizations - AWS Organizations
ここで注意点があり、この信頼されたアクセスの有効化/無効化は、「AWS Organizations側から実行」「各AWSサービス側から実行」のどちらも可能なのですが、現時点の注釈によると「各AWSサービス側から実行」が推奨されています。
Using AWS Organizations with other AWS services - AWS Organizations
重要
信頼されたアクセスの有効化と無効化には、信頼されたサービスのコンソールか、その AWS CLI または API のオペレーションのみを使用することを強くお勧めします。 これにより、信頼できるアクセスの有効化に必要なすべての初期化処理が信頼できるサービスによって実行可能になります。例えば、必要なリソースの作成や、信頼できるアクセスの無効にする際のリソースのクリーンアップなどです。
信頼されたサービスを使用し、信頼されたサービスによる組織へのアクセスを有効または無効にする方法については、AWS Organizations で使用できる AWS のサービス の [Supports Trusted Access] (信頼されたアクセスをサポート) 列の [Learn more] (詳細はこちら) リンクを参照してください。
Organizations コンソール、CLI コマンド、API オペレーションを使用してアクセスを無効にした場合の結果は次のようになります。
- そのサービスでは、サービスにリンクされたロールを組織のアカウントに作成できなくなります。つまり、組織の新しいアカウントに対するオペレーションをサービスがユーザーに代わって実行できなくなります。そのサービスによる AWS Organizations のクリーンアップが完了するまでは、古いアカウントに対するオペレーションは引き続き実行可能です。
- そのサービスでは、ロールにアタッチされている IAM ポリシーによって明示的に許可されていない限り、組織のメンバーアカウントのタスクを実行できなくなります。これには、メンバーアカウントから管理アカウントまたは委任管理者アカウント (該当する場合) へのデータ集約が含まれます。
- 一部のサービスはこれを検出し、統合に関連する残りのデータやリソースをクリーンアップします。一方、組織へのアクセスを停止するものの、統合を再び有効にする場合のために履歴データと設定を残しておくサービスもあります。
そうしたサービスであっても、コンソールまたはコマンドを使用して統合を無効にすると、その統合以外に用途のないリソースがクリーンアップされるようになります。組織のアカウントのリソースをクリーンアップする仕組みは、サービスによって異なります。詳しくは、AWS の他のサービスのドキュメントを参照してください。
つまり雑要約すると、「各サービス側からやる方が確実に有効化・クリーンアップできるよ、Org側からやると統合に必要ないリソースまで消しちゃったりする恐れがあるよ、その違いは各サービスごとで異なるよ」みたいな感じです。
じゃあ「基本的に各サービス側からやればいいのね」となりますが、「各サービス側からの実行方法」がサービスによって多少差があり、一部のサービスは「コンソールからのみ実行可能」で、プログラムで操作できませんでした。
AWS CloudFormationの場合、元々は「コンソールからのみ実行可能」だったのですが、今回のアップデートで「コンソールだけでなく、API（つまりSDK/CLI経由）でも実行可能」になりました、というわけです。
やってみた
検証前
まず、検証前は、信頼されたアクセスが有効化されていないことを確認します。
describe-organizations-access — AWS CLI 2.12.1 Command Reference
list-aws-service-access-for-organization — AWS CLI 2.12.1 Command Reference
% aws cloudformation describe-organizations-access
{
"Status": "DISABLED"
}
% aws organizations list-aws-service-access-for-organization
{
"EnabledServicePrincipals": [
{
"ServicePrincipal": "cloudtrail.amazonaws.com",
"DateEnabled": "2023-06-14T15:09:03.626000+09:00"
},
{
"ServicePrincipal": "config.amazonaws.com",
"DateEnabled": "2023-06-14T15:16:55.239000+09:00"
},
{
"ServicePrincipal": "controltower.amazonaws.com",
"DateEnabled": "2023-06-14T15:09:02.028000+09:00"
},
{
"ServicePrincipal": "sso.amazonaws.com",
"DateEnabled": "2023-06-14T15:42:47.754000+09:00"
}
]
}CFn APIにて実行
有効化
今回アップデートで提供開始された AWS CloudFormation API側から有効化を行います。
activate-organizations-access — AWS CLI 2.12.1 Command Reference
# 有効化する（特に何も返ってはこない）
% aws cloudformation activate-organizations-access
# 確認する
## CFn API側
% aws cloudformation describe-organizations-access
{
"Status": "ENABLED"
}
## Org API側
% aws organizations list-aws-service-access-for-organization
{
"EnabledServicePrincipals": [
{
"ServicePrincipal": "cloudtrail.amazonaws.com",
"DateEnabled": "2023-06-14T15:09:03.626000+09:00"
},
{
"ServicePrincipal": "config.amazonaws.com",
"DateEnabled": "2023-06-14T15:16:55.239000+09:00"
},
{
"ServicePrincipal": "controltower.amazonaws.com",
"DateEnabled": "2023-06-14T15:09:02.028000+09:00"
},
{
"ServicePrincipal": "member.org.stacksets.cloudformation.amazonaws.com",
"DateEnabled": "2023-06-21T15:37:32.477000+09:00"
},
{
"ServicePrincipal": "sso.amazonaws.com",
"DateEnabled": "2023-06-14T15:42:47.754000+09:00"
}
]
}Orgコンソールでも以下の通り確認できます。
IAMコンソールを見に行くと、Service-Linked Role AWSServiceRoleForCloudFormationStackSetsOrgAdmin が作成されていました。
マネージドポリシーの中身を見ると、このロールによって管理アカウント上でのAWS Organizationsの読み取り権限、メンバーアカウントへのStackSets実行権限へのスイッチロールができるようです。
無効化
今度は、今回アップデートで提供開始された AWS CloudFormation API側から無効化を行います。
deactivate-organizations-access — AWS CLI 2.12.1 Command Reference
# 無効化する
% aws cloudformation deactivate-organizations-access
# 確認する
## CFn API側
% aws cloudformation describe-organizations-access
{
"Status": "DISABLED"
}
## Org API側
% aws organizations list-aws-service-access-for-organization
{
"EnabledServicePrincipals": [
{
"ServicePrincipal": "cloudtrail.amazonaws.com",
"DateEnabled": "2023-06-14T15:09:03.626000+09:00"
},
{
"ServicePrincipal": "config.amazonaws.com",
"DateEnabled": "2023-06-14T15:16:55.239000+09:00"
},
{
"ServicePrincipal": "controltower.amazonaws.com",
"DateEnabled": "2023-06-14T15:09:02.028000+09:00"
},
{
"ServicePrincipal": "sso.amazonaws.com",
"DateEnabled": "2023-06-14T15:42:47.754000+09:00"
}
]
}Orgコンソールでも確認できました。
CFnコンソールでも無効化されていることが確認できました。
ちなみに、有効化時に作成されたIAMロールは削除されずに残っていました。
おまけ）Organizations コンソールにて実行
せっかくなので、Organizaitons側から同じく有効化/無効化をやってみます。
有効化
Organizationsはコンソールから実行します。
Organizations側から信頼されたアクセスの有効化は推奨されていないので、実行前に本当にいいのか念押しされますが、実行してみます。
有効化されました。
CloudFormationコンソールを見ると、有効化されていませんでした。
CLIでも確認してみます。
#CFn側はDISABLEのまま
% aws cloudformation describe-organizations-access
{
"Status": "DISABLED"
}
#Org側は有効化された
% aws organizations list-aws-service-access-for-organization
{
"EnabledServicePrincipals": [
{
"ServicePrincipal": "cloudtrail.amazonaws.com",
"DateEnabled": "2023-06-14T15:09:03.626000+09:00"
},
{
"ServicePrincipal": "config.amazonaws.com",
"DateEnabled": "2023-06-14T15:16:55.239000+09:00"
},
{
"ServicePrincipal": "controltower.amazonaws.com",
"DateEnabled": "2023-06-14T15:09:02.028000+09:00"
},
{
"ServicePrincipal": "member.org.stacksets.cloudformation.amazonaws.com",
"DateEnabled": "2023-06-21T17:47:09.849000+09:00"
},
{
"ServicePrincipal": "sso.amazonaws.com",
"DateEnabled": "2023-06-14T15:42:47.754000+09:00"
}
]
}追加でCFnから有効化
追加で、CloudFormationコンソールから有効化を行いました。 すると、有効化になりました。
% aws cloudformation describe-organizations-access
{
"Status": "ENABLED"
}無効化
Orgコンソールから行います。
確認をすると、有効化と違いOrganizationsコンソールからの無効化は、CloudFormation側もDISABLEに変更されました。
ちなみに、Service-linked roleは削除されてはいませんでした。
# Org側は無効化
% aws organizations list-aws-service-access-for-organization
{
"EnabledServicePrincipals": [
{
"ServicePrincipal": "cloudtrail.amazonaws.com",
"DateEnabled": "2023-06-14T15:09:03.626000+09:00"
},
{
"ServicePrincipal": "config.amazonaws.com",
"DateEnabled": "2023-06-14T15:16:55.239000+09:00"
},
{
"ServicePrincipal": "controltower.amazonaws.com",
"DateEnabled": "2023-06-14T15:09:02.028000+09:00"
},
{
"ServicePrincipal": "sso.amazonaws.com",
"DateEnabled": "2023-06-14T15:42:47.754000+09:00"
}
]
}
# CFn側も無効化
% aws cloudformation describe-organizations-access
{
"Status": "DISABLED"
}まとめ
よって、Organizations側からの処理は、有効化/無効化で挙動が完全に対になるとは言えなさそうです。ただし、これはあくまで「Organizations x CloudFormation」の場合であり、他AWSサービスの場合だとどうなるかわかりません。
つまり、Organizaitons側からだとこういった意図しない挙動の恐れがありえるため、Organizations連携/統合するための「信頼されたアクセスの有効化/無効化」は、できるだけ「各AWSサービスから実行」する方が無難といえそうです。
ただし、全てのOrganiations統合可能なAWSサービスにて、各サービス側からの実行方法がコンソールからもAPIからも可能、という状況ではない可能性があるので、各サービス単位で実施方法を検討する形になりそうです。
歯切れが悪いですが、現時点でのまとめは以上です。
4
