Cloud Automatorで対象リソース、操作権限を限定したユーザーを利用する

記事タイトルとURLをコピーする

こんにちは、技術4課の城です。
今回は掲題のCloud Automator(以降、CA)の利用方法を紹介します。

やりたいことと条件

  • 個別のシステム担当者に対し、EC2、RDS(Aurolaを除く)の起動、停止ジョブのみ設定可能
  • 担当している以外のシステムの起動、停止は不可
  • Applicationタグにてシステムが判別

実現方法

  • CAのグループ機能を利用
  • グループに割り当てるクレデンシャルのIAMポリシーにて権限制御
    • 多雨小リソースの限定についてはIAMポリシーのCondition要素を利用

具体例のイメージ

  • システム担当者のCAユーザーAはCAのグループ:Alfaに属している
  • CAグループAlfaにはEC2,RDSのApplicationタグがAlfaであるリソースの起動、停止が許可されたクレデンシャルを登録
  • システムAlfaのEC2:ServerAlfaに対する起動ジョブは成功する
  • システムBetaのEC2:ServerBetaに対する起動ジョブはジョブ作成はできるもののIAMポリシーの権限不足により失敗する

IAM設定

CAはアクセスキー、シークレットアクセスキーを必要とするのでIAMユーザーを利用します。
管理をシンプルにするため、ポリシー変数を利用して共用できる形を検討しました。
利用するリソース数としては、下記のようになります。

・IAMポリシー:1
・IAMグループ:1
・IAMユーザー:システム数

IAMポリシー

下記のアクセス権限にて作成します。
アプリケーションタグのValueがIAMユーザー名と一致していればEC2,RDSの起動、停止が可能な内容です。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",
                "ec2:StopInstances"
            ],
            "Resource": "arn:aws:ec2:*:*:instance/*",
            "Condition": {
                "StringEquals": {
                    "ec2:ResourceTag/Application": "${aws:username}"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "rds:StopDBInstance",
                "rds:StartDBInstance"
            ],
            "Resource": "arn:aws:rds:*:*:db:*",
            "Condition": {
                "StringEquals": {
                    "rds:db-tag/Application": "${aws:username}"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances",
                "rds:DescribeDBInstances"
            ],
            "Resource": "*"
        }
    ]
}

IAMグループ

CA用のIAMグループを一つ作成します。
作成したIAMポリシーをアタッチします。
各システムのCAグループ用のIAMユーザーは全てこちらに所属させます。

IAMユーザー

各システムに設定しているApplicationタグのValueをユーザー名とします。
今回はApplication:Alfaのリソースを操作したいので、Alfaとしました。
プログラムによるアクセスにチェックをしておき、アクセスキー、シークレットアクセスキーを記録しておきます。

CAの設定

ユーザーの追加

システム担当者のユーザーを追加します。
ユーザー追加についてはマニュアル:ユーザー管理を参考にしてください。

グループの追加

グループを追加し、前項のユーザーをグループメンバーに追加します。
グループの管理についてはマニュアル:グループの管理を参考にしてください。
アクセスキー、シークレットアクセスキーは前項にて作成したIAMユーザーのものを利用します。

ジョブを作成

イメージ図のServerAlfa、ServerBetaに対する起動ジョブを作成しみます。
EC2インスタンス起動ジョブ作成については[マニュアル:EC2:インスタンスを起動]を参考にしてください。
今回はそれぞれ即時実行ジョブを作成してみます。
【ServerAlfaの起動ジョブ】

【ServerBetaの起動ジョブ】

実行結果

想定通りですが、ServerAlfaの起動ジョブは成功し、ServerBetaの起動ジョブは失敗します。
【ServerAlfaのジョブ実行結果】

【ServerBetaのジョブ実行結果】
実行結果を見ると、エラーメッセージ: UnauthorizedOperation: You are not authorized to perform this operation.と出力されているので、意図した通り権限不足でジョブ実行が失敗しています。

さいごに

CAのグループ機能とIAMポリシーを利用しての権限制御を紹介しました。
IAMポリシーでは色々な形で権限制御が可能です。
権限を適切に設定することで、情報システム全体の管理者からシステム担当者へ利用権限を委任することが出来るかと思います。

最後にちょっと宣伝ですが、Cloud AutomatorはAMIの取得、インスタンスタイプ変更などをスケジューリングできたりと、手前味噌ながら便利なツールとなっています。
是非、利用してみてはいかがでしょうか。

どなたかの助けになれば幸いです。

城 航太 (記事一覧)

営業部カスタマーサクセス課・課長

AWSへの移行、AWSアカウントセキュリティ、ネットワーク広く浅くといった感じです。最近はAmazon WorkSpacesやAmazon AppStream2.0が好きです。APN Ambassador 2019,2020