CfCTを使ってみよう②
～ルール作成編～

投稿日: 2024/01/09

はじめに

こんにちは、高橋です。
今回はCustomizations for AWS Control Tower(CfCT)機能の初期設定編に続いて、CloudFormation StackSetsとSCPのそれぞれの設定と実際の設定時に気づいた点について紹介をします。

１．設定

最初にCfCTをCloudFormation StackSetsとSCPをデプロイする手順を紹介します。今回は特定のOU(SandBox)配下のアカウントに対して、CloudFormation StackSetsで管理アカウントからスイッチロール可能なIAMロールを作成し、SCPでそのロール以外がSavings Plansの購入を禁止するルールを設定してみたいと思います。

では実際に設定を行ってみたいと思います。

(1) CodeCommitからリポジトリのコピー

CfCTのテンプレートが正常にデプロイされれば、CodeCommit上にリポジトリが保存されています。実際の設定時はこれをCloud9やEC2環境等、コードを開発する環境にコピーを行います。


    $ git clone https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/custom-control-tower-configuration

(2) CloudFormation StackSets/SCP用ファイルの作成

CloudFormations StackSetsでデプロイするリソースやSCPの設定ファイルを作成します。StackSetsの設定ファイルはyaml形式でデプロイしたい環境を記載します。SCPについては設定するポリシードキュメントを記載します。CodeCommitで実際のコードは下記の通りになります。なお、yaml、json形式で記載するので、インテントがずれると環境デプロイに失敗するので、記載には注意して下さい。

CloudFormations StackSets用設定ファイル(resrict-purchase-sp-role-template)


    Resources:
        PurchaseSPRole:
            Type: AWS::IAM::Role
            Properties:
            AssumeRolePolicyDocument:
                Version: '2012-10-17'
                Statement:
                - Effect: Allow
                    Principal:
                    AWS:
                        - "arn:aws:iam::<アカウントID>:root"
                    Action: sts:AssumeRole
            RoleName: purchase-sp-role
            ManagedPolicyArns:
                - "arn:aws:iam::aws:policy/ReadOnlyAccess"
                - "arn:aws:iam::aws:policy/AWSSavingsPlansFullAccess"

SCP用設定ファイル(purchase-sp-role.json)


    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Sid": "DenySP",
                "Action": "savingsplans:CreateSavingsPlan",
                "Effect": "Deny",
                "Resource": "*",
                "Condition": {
                    "StringNotLike": {
                        "aws:PrincipalARN": [
                            "arn:aws:iam::*:role/purchase-sp-role"
                        ]
                    }
                }
            }
        ]
    }

作成したファイルはS3に保存して利用することもできますが、管理の観点からはそれぞれ専用のディレクトリを作成して、CodeCommitで管理した方がいいと思います。

(3) マニュフェストファイルの編集

コピーしたリポジトリ内に「manifest.yaml」という名前でマニュフェストファイルが保存されているので、これを編集して、先程作成したCloudFormation StackSets/SCP用ファイルを用いて環境が作成されるようにします。


    ---
    #Default region for deploying Custom Control Tower: Code Pipeline, Step functions, Lambda, SSM parameters, and StackSets
    region: ap-northeast-1 # Control Tower Home Region
    version: 2021-03-15

    resources:
    # ControlTower Custom CFN Resources - Create Additional IAM Role
        - name: create-purchase-sp-role					←①
            resource_file: stacksets/restrict-purchase-sp-role-template	←②
            deploy_method: stack_set					←③
            #Apply to the following OU(s)
            deployment_targets:
            organizational_units:
                - Sandbox						←④
    # ControlTower Custom SCPs - Additional Preventive Guardrails
        - name: deny-purchase-sp
            description: Purchase Savings Plans
            resource_file: scp/deny-purchase-sp.json
            deploy_method: scp
            # Apply to the following OU(s)
            deployment_targets:
            organizational_units:
                - Sandbox # Formerly Custom

主に設定する箇所は①～④で、以下の様に記載します。

① CloudFormation StackSetsの場合は、CloudFormationのテンプレート名に含む名前、SCPの場合はSCPのポリシー名に設定する値を記載
② (2)で作製した設定ファイルのパスを記載する。S3に保存した場合はURLを記載。
③ CloudFormation StackSetsの設定の場合は「stack_set」、SCPの場合は「scp」と記載。
④ この設定を適用したいOUの名前を記載。複数のOUに適用する場合は、複数行に分けて記載する。全体に適用する場合は「Root」と指定。

(4) 環境のデプロイ

設定が完了したら、gitコマンドでCodeCommitに更新したリポジトリを保存することで自動的に環境のデプロイが実行されます。


    git add -A 
    git commit -m 'コメント'
    git push

デプロイの状況はCodePipelineの「Custom-Control-Tower-CodePipeline」で確認することができます。全てのステップが成功しましたとなっていれば、無事環境がデプロイされたことになります。

実際にこんな感じで設定が行われています。

SandBox OUに対するSCPの設定

SandBox OU内のアカウントのロール

２．Tips

次に私が実際に試していた中で気付いた点について記載したと思います。
1つ目は失敗時のトラブルシューティングです。
デプロイ時の進行はCode Pipelineで確認することができ、失敗時にはログの表示ボタンを押すことでログを表示できますが、下記の通りにこちらからでは全く訳が分かりません。

そこで実際のデプロイのフローを見直してみると、StepFunctionにて設定はデプロイされます。

なので、実際のトラブルシューティングはこちらのログを見て行う必要があります。

このケースの場合は、テストのやりすぎでOUにアタッチできるSCPの上限(最大5つ)を超えてしまったことが原因であることが分かります。

続いてテンプレートの使いまわしによる影響についてです。今回の設定で紹介した様に、基本的にこの構成では「manifest.yaml」ファイルを使いまわすことになります。そうすると新しい設定をデプロイするとその前にデプロイしていたSCPやStackSetsはどうなるのでしょうか？結論を言うと何の影響も受けずにそのまま残り続けます。ただし、name行を同じにした場合は上書きされ、以前の設定が新しい設定に変更されてしまうので既存ポリシーを変更したい場合はいいですが、そうでない場合はご注意ください。また、作成したものがそのままということは、CfCTの仕組みからは一度デプロイしたCloud Formation StackSetsやSCPを削除することはできません。ですので、削除する場合はそれぞれのサービスの画面から手動で設定を削除する必要があります。

３．さいごに

今回は初期設定編とルール作成編とCfCTについてご紹介をしました。Control Towerもコントロール機能が拡張されだいぶ使いやすくなりましたが、CfCTはそこに運用や統制のために行いたい初期設定の自動化や独自の禁止ルールの導入などを行うことが可能で、マルチアカウント環境をより簡単に管理できるようになることがお分りいただけたのではないでしょうか。現在Control Towerを利用していて、より便利に利用したいと思った方は是非CfCTを試してみてください。