AWS DevOps Agent のエージェントスペースに対するアクセス制御をどうすればいいか考えたので試してみた
こんにちは。クラウド事業統括本部コンサルティング1部の桑野です。
ようやく熱い季節が過ぎ去り、徐々に肌寒さを感じるようになってきました。2月生まれの私は涼しくなってきてウキウキしています。
前置きはこの辺にしておき、皆さんは AWS DevOps Agent のアクセス制御をどのように行っていますか？
エージェントスペースごとに使えるユーザーを細かく分けたい場面も出てくるんじゃないかと思います。
DevOps Agent ではマネジメントコンソールからオペレーターアクセス（IAM 経由の起動）、もしくは Identity Center のユーザーをエージェントスペースに登録することによる AWS access portal のアプリケーション 経由でウェブアプリにアクセスして調査をすることができます。
小さく運用する分にはあまり気にしなくても問題ないかもしれませんが、用途ごとにエージェントスペースを構築し、さらに使えるユーザーを細かく分けたいとなると結構苦労するかもしれません。
IAM ロールで制御しようとした場合、エージェントスペースごとに許可セットやポリシーを用意してユーザーに割り当てる必要があり、運用負荷が発生するんじゃないかなと思いました。
今回は、IAM Identity Center（以下 IdC）のユーザーアクセスと SCP を組み合わせて、エージェントスペースの利用権限を AWS アカウントの権限から分離できるか検証してみました。
先にまとめ
エージェントスペースを使えるユーザーを分けたい場合は、以下の形で制御するのが良さそうです。
- エージェントスペースを使えるユーザーは、IdC のユーザーアクセスへの登録で決める
- 管理者以外のオペレーターアクセス（IAM 経由の起動）は、SCP で拒否する
- 管理者以外によるユーザーアクセスの登録・削除も、SCP で拒否する
このようにすることで、明示的に IdC のユーザーを登録しない限りウェブアプリにアクセスすることができなくなります。
エージェントスペースへの IdC ユーザーの登録は管理者相当の権限を持つユーザー以外編集できないため、管理者相当の権限を持たないユーザーがウェブアプリにアクセスできる人を勝手に追加・削除するという心配もなくなります。
この方法であれば、エージェントスペースが増えたとしても許可セットやポリシーを増やす手間を減らしつつ制御ができそうです。
図で示すと以下のイメージです。
前提
以下の前提条件で検証を行なっていきます。
- 東京リージョンのエージェントスペースを使用
- エージェントスペースの ウェブアプリと IdC の連携は設定済み
- SCP は管理アカウントから設定し、検証用のメンバーアカウントで操作
IdC 連携の設定手順は、以下の記事で紹介されています。
Identity Center 未設定の状態から連携するまでをスクリーンショット付きて丁寧に解説してくださっています。
DevOps Agent と Identity Center をまずは組み合わせてみたいという方はぜひご覧いただければと思います。
背景・課題
ウェブアプリへのアクセス経路
DevOps Agent のウェブアプリには、主に 2 つのアクセス経路があります。
表で整理してみました。
| アクセス経路 | 操作 | アクセスできるかを決めるもの |
|---|---|---|
| IdC 経由（ユーザーアクセス） | AWS アクセスポータルの「アプリケーション」から開く | エージェントスペースのユーザーアクセスへの登録 |
| IAM 経由（オペレーターアクセス） | マネジメントコンソールの「IAM経由で起動する」から開く | コンソールで使っている IAM ロールの権限 |
詳しくは以下の公式ドキュメントをご覧いただけると良いと思います。
今回のユースケース
たとえば、IdC の許可セットとして ReadOnly、PowerUser、Administrator の 3 種類を用意し、開発者には PowerUser を割り当てている環境を考えます。
IdC を使っていない場合でも、上記のようなロールを持ったユーザーで運用しているという状況をイメージいただくと良いと思います。
IAM 経由で ウェブアプリを開くときは、aidevops:CreateOneTimeLoginSession というアクションが使われます。
PowerUserAccess は IAM や Organizations などの一部サービスを除いてすべてを許可するポリシーなので、aidevops のアクションも許可されています。
実際に PowerUser の許可セットで「IAM経由で起動する」を試したところ、ウェブアプリにアクセスできました。
AIDevOpsAgentFullAccess という権限も同様にウェブアプリにアクセスできます。
このままだとエージェントスペースごとに利用者を分けたくても、aidevops:CreateOneTimeLoginSession 相当の権限を持っている状況をなんとかしない限りはいろんなエージェントスペースのウェブアプリにアクセスできてしまいます。
それならオペレーターアクセスを使えないようにして、ウェブアプリへのアクセスを IdC のユーザーアクセスに一本化すれば解決しそうな予感がしますね。
ただ、IdC に一本化した場合、それはそれで今度はユーザーアクセスの登録や削除を考慮しないといけないです。
ユーザーアクセスに IdC ユーザーが登録されているかどうかでウェブアプリを利用できる人が決まるため、ユーザーアクセスの登録・削除を誰ができるのかも制御する必要が出てきます。
ユーザーアクセスの登録・削除は、コンソール上ではエージェントスペースの画面から操作します。
ただし、実際に呼ばれるのは aidevops のアクションではなく、IdC の sso:CreateApplicationAssignment と sso:DeleteApplicationAssignment です。
PowerUserAccess では sso のアクションも許可されているため、PowerUser を持つ開発者は自分自身をユーザーアクセスに登録できてしまいます。これでは、管理者が利用者を決めても、開発者が自分で登録すれば使えるようになってしまいますね。
図で示すと以下の通りかなと思います。
じゃあどうすればいいの？
そこで、以下の 2 つを組み合わせることを考えてみました。
- ウェブアプリの利用は、IdC 経由のユーザーアクセスに一本化する
- 管理者以外の許可セットでは、オペレーターアクセスとユーザーアクセスの登録・削除を SCP で拒否する
これで、普段どの許可セットを使っているかに関係なく、管理者がユーザーアクセスに登録したユーザーだけがエージェントスペースを使える状態になるはずです。
では早速検証してみましょう！
IdC のユーザーアクセスについて検証
まずは AWS アカウントに対する権限が小さくても、IdC 経由なら ウェブアプリを使えるかを確認してみました。
検証用ユーザーに ReadOnlyAccess だけを設定した許可セットを割り当てて、マネジメントコンソールから DevOps Agent を開きました。
エージェントスペースの一覧を読み込む段階で、権限不足のエラーになりました。
ReadOnly の権限では、コンソールからエージェントスペースを開くことはできないことがわかりますね。
次に、管理者でエージェントスペースの ウェブアプリ設定を開き、「ユーザーアクセス」の「追加」から検証用ユーザーを登録しました。
検証用ユーザーで AWS アクセスポータルを開くと、「アプリケーション」に DevOps Agent のエージェントスペースが表示されていますね。検証用ユーザーの許可セットは ReadOnlyAccess のままです。
ここからウェブアプリにアクセスすることができます。
チャットで質問を送ると、応答も返ってきますね。
AWS アカウント側の権限を増やさなくても、ユーザーアクセスに登録してさえいれば ウェブアプリにアクセスできることが確認できました。
ウェブアプリを使えるかどうかは、許可セットとは別に決められることが分かりますね。
エージェントスペースの利用は、IdC 経由のユーザーアクセスに一本化するということは実現ができそうです。
SCP で管理者以外の操作を拒否する
残る課題は以下の 2 点です。
- IAM 経由で ウェブアプリを開くことができる
- PowerUser などの許可セットで、ユーザーアクセスを自由に登録・削除することができる
この 2 つを、管理者以外は実行できないように SCP で拒否します。
なお、コンソール上ではエージェントスペースの「ユーザーアクセス」から操作しますが、登録・削除で呼ばれるのは aidevops ではなく IdC 側の sso:CreateApplicationAssignment と sso:DeleteApplicationAssignment です。そのため、SCP にはこの 2 つのアクションも含めています。
適用した SCP はこちらです。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyDevOpsWebAppAccessAndAuthChangesExceptAdmin",
"Effect": "Deny",
"Action": [
"aidevops:CreateOneTimeLoginSession",
"aidevops:EnableOperatorApp",
"aidevops:DisableOperatorApp",
"aidevops:UpdateOperatorAppIdpConfig"
],
"Resource": "*",
"Condition": {
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/*/AWSReservedSSO_AWSAdministratorAccess_*",
"arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_AWSAdministratorAccess_*"
]
}
}
},
{
"Sid": "DenyIdentityCenterApplicationAssignmentsExceptAdmin",
"Effect": "Deny",
"Action": [
"sso:CreateApplicationAssignment",
"sso:DeleteApplicationAssignment"
],
"Resource": "*",
"Condition": {
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/*/AWSReservedSSO_AWSAdministratorAccess_*",
"arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_AWSAdministratorAccess_*"
]
}
}
}
]
}
| ステートメント | 拒否する操作 |
|---|---|
| 1 つ目 | オペレーターアクセス（IAM 経由のログイン）と、Web アプリの有効化・無効化・IdP 設定の変更 |
| 2 つ目 | ユーザーアクセスへのユーザー・グループの登録・削除 |
どちらも、AWSAdministratorAccess という名前の許可セットから作られた IAM ロールだけを例外にしています。許可セット名は環境に合わせて変更することで応用ができると思います。
動作確認
SCP を適用した状態で、管理者と管理者以外の許可セットで同じ操作を試しました。
| 操作 | 許可セットに付与したポリシー | 結果 |
|---|---|---|
| IAM 経由で ウェブアプリを起動 | PowerUserAccess |
拒否 |
| IAM 経由で ウェブアプリを起動 | AdministratorAccess |
成功 |
| ユーザーアクセスの登録・削除 | PowerUserAccess |
拒否 |
| ユーザーアクセスの登録・削除 | AdministratorAccess |
成功 |
PowerUser の許可セットで「IAM経由で起動する」を押すと、「オペレーターアクセスの起動に失敗しました」というエラーになりました。aidevops:CreateOneTimeLoginSession というアクションが SCP で明示的に拒否されています。
User: arn:aws:sts::<member-account-id>:assumed-role/AWSReservedSSO_PowerUser-test_<suffix>/<user-name>
is not authorized to perform: aidevops:CreateOneTimeLoginSession
on resource: arn:aws:aidevops:ap-northeast-1:<member-account-id>:agentspace/<agent-space-id>
with an explicit deny in a service control policy: arn:aws:organizations::<management-account-id>:policy/<organization-id>/service_control_policy/<policy-id>
ユーザーアクセスの登録についても、sso:CreateApplicationAssignment というアクションが SCP で拒否されました。
User: arn:aws:sts::<member-account-id>:assumed-role/AWSReservedSSO_PowerUser-test_<suffix>/<user-name>
is not authorized to perform: sso:CreateApplicationAssignment
on resource: arn:aws:sso::<management-account-id>:application/<instance-id>/<application-id>
with an explicit deny in a service control policy: arn:aws:organizations::<management-account-id>:policy/<organization-id>/service_control_policy/<policy-id>
削除も同様に、sso:DeleteApplicationAssignment というアクションが SCP で拒否されています。
User: arn:aws:sts::<member-account-id>:assumed-role/AWSReservedSSO_PowerUser-test_<suffix>/<user-name>
is not authorized to perform: sso:DeleteApplicationAssignment
on resource: arn:aws:sso::<management-account-id>:application/<instance-id>/<application-id>
with an explicit deny in a service control policy: arn:aws:organizations::<management-account-id>:policy/<organization-id>/service_control_policy/<policy-id>
一方で IAM 経由の起動が拒否されるユーザーでも、ユーザーアクセスに登録されていれば IdC 経由で ウェブアプリを開くことができました。
管理者以外は IAM 経由で ウェブアプリを開けず、ユーザーアクセスの登録・削除もできない状態になりました。
ウェブアプリを使えるユーザーは、管理者がエージェントスペースのユーザーアクセスに登録したユーザーだけという仕組みが実現できてそうですね。
注意点
今回の SCP では、sso:CreateApplicationAssignment と sso:DeleteApplicationAssignment を Resource: "*" で拒否しています。そのため、DevOps Agent だけでなく、IdC アプリケーションへの割り当てを使う他のサービスも制限の対象になります。
たとえば Amazon Q Business や AWS Transform でも、同じ API でユーザー・グループを割り当てます。
対象を DevOps Agent に限定したい場合は、Resource に DevOps Agent の IdC アプリケーション ARN を指定する方法がありそうでした。ただし、エージェントスペースを追加するたびに ARN の管理が必要なのでちょっと煩わしいかも...と感じました。
ただ、他のサービスも含めて、アプリケーションへの割り当ては管理者が行う方針にしてしまえば運用の観点では大きく問題にはならないと私は考えています。
自分の探し方が悪くて見つからなかっただけかもしれませんが、サービス単位でアプリケーションの登録・削除アクションを制御できる方法があるといいなと思いました。
まとめ
IdC のユーザーアクセスと SCP を組み合わせて、エージェントスペースの利用権限を AWS アカウントの権限から分離できるか検証しました。
ユーザーアクセスに登録すれば、AWS アカウント側が ReadOnly でも ウェブアプリを使えました。
ただしそれだけだと IAM 経由のオペレーターアクセスでも ウェブアプリにアクセスできてしまうため、オペレーターアクセスの機能とユーザーアクセスの登録・削除を特定の許可セット以外から実行できないようにする工夫を組み合わせました。
検証の範囲では、エージェントスペースごとに許可セットを増やさずに制御できることを確認できました。
ただし、SSO 側の拒否は他のサービスにも影響します。
導入する場合は、IdC アプリケーションへの割り当てを誰が担当するのかもあわせて検討したいところですね。
この記事がどなたかの役に立てば幸いです。
最後までご覧いただきありがとうございました。
