0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【コツコツAWS】AWS CDK - 認証や権限の初期設定 -

0
Posted at

AWS Cloud Development Kit (AWS CDK)に関して、勉強したことを残していきます。
今回はCDKを使うまでの準備、特に認証と権限の設定に関して、調べたことを残します。
(AWS CLIやNode.js, AWS CDK Toolkitといった、ライブラリのインストールの話はしていません)

概要

  • CDKを使うには認証と権限の2つの設定が必要
    ⇒ 何でユーザーを認証して、どの権限でdeploy等の操作を行うか
  • 権限 (Role)はbootstrapで作成されたものをAssumeRoleで渡すのが基本
  • VS Codeから使う場合は、Identity Centerで認証して、許可セットで権限を設定
  • SageMakerから使う場合は、NotebookやSpaceの実行権限にAssumeRoleを設定

bootstrapについて

全くCDKを知らない方はこちらで簡単にCDKやbootstrapの説明をしていますので、ご覧ください。
どの環境でも、最初のbootstrapだけは広めの権限が必要になるため、管理者権限などで最初に実行しておく方が楽そうです。

一度bootstrapをすると、以下のRoleが自動的に作られます。
(hnb659fdsは修飾子らしく、変更したければbootstrap実行時に--qualifierオプションで指定可能)

  • cdk-hnb659fds-cfn-exec-role-<account>-<region>
  • cdk-hnb659fds-deploy-role-<account>-<region>
  • cdk-hnb659fds-lookup-role-<account>-<region>
  • cdk-hnb659fds-file-publishing-role-<account>-<region>
  • cdk-hnb659fds-image-publishing-role-<account>-<region>

それぞれdeployやlookupなど、CDKが必要とする操作を許可するもので、これらを権限として渡すことになります。
(渡す際にはARNで指定する他、aws-cdk:bootstrap-roleタグが付いているので、タグ指定でも可能)

cfn-exec-roleはCloudFormationがリソースを作成する際に使用するRole。
bootstrap時に指定しなければAdministratorAccessのポリシーが付与されます。
権限を絞りたい場合は、--cloudformation-execution-policiesオプションで、ポリシーを指定することも可能。

他のAWSアカウントをデプロイ先や情報検索先として追加することもbootstrapのオプションでできるようです。
参考: CDKのドキュメント

VS CodeでCDKを使うための準備

ざっくりと以下の手順になります。

  1. Identity Centerでユーザーやグループを作成
  2. CDK用の許可セット作成し、1で作成したユーザーやグループに渡す
  3. VS CodeでSSOの設定を行い、ログインする

まず、認証はドキュメント等でもIdentity Centerを使った認証を推奨しているので、それに従います。
AWSのコンソールでIAM Identity Centerを開き、ユーザーやグループを作成。
作成したユーザーやグループに対して、以下のようなポリシーをアタッチした許可セットを割り当てます。

許可セットのポリシー例
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AssumeCDKRoles",
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "iam:ResourceTag/aws-cdk:bootstrap-role": [
            "image-publishing",
            "file-publishing",
            "deploy",
            "lookup"
          ]
        }
      }
    }
  ]
}

↑は前述した通り、bootstrapで作成されたCDK関連のRoleを渡しています。
これらのRoleは既に信頼ポリシーで、同一アカウント内のユーザー等を許可しているので、AssumeRoleの設定のみでOKです。

Identity Centerの設定が完了したら、VS Code側の設定に移ります。
aws configure ssoでSSOを設定し、AWS Toolkitやaws sso loginから作成したユーザーでログイン。
aws sts get-caller-identity --profile {設定したprofile名}でログインや権限設定ができているか確認しておくとよいかもしれません。

VS Codeでの準備は以上です。

SageMaker NotebookやStudioの場合

ローカルのIDEではなく、AWS内のサービス(今回はSageMaker)からCDKを触る場合の設定を考えます。
(使うサービスの権限を持ったユーザーで、AWSコンソールにログインしている前提)

この場合、認証部分は既に終わっているので、残りはSageMaker内でCDKを操作する際の権限を考えます。
基本的にVS Codeの時と同じです。SageMaker Notebookであれば、Notebookの実行Role、Studioであればスペースの実行Roleにbootstrapで作られたRoleをAssumeRoleできるように渡すだけです。
(前述の通り、同一アカウント内は許可されているので、AssumeRoleの設定のみでOK)
SageMaker内でCDKを使う場合の設定はこれだけです。

基本的にAssumeRoleで任せる形になってますが、以下のような流れになっているようです。

Notebookの実行Roleで開始

sts:AssumeRoleを元に、bootstrapで作成されたロールを引き受ける

cdk synthでテンプレート作成 (確認不要なら飛ばしてもOK)

cdk deployからCloudFormationにスタック作成を依頼

deploy-roleのRoleがCloudFormationにcfn-exec-roleをPassRole

CloudFormationが受け取ったRoleでリソースを作成

まとめ

VS Code, SageMakerからCDKを使う場合の認証, 権限関係の設定について確認しました。
AssumeRoleが便利なので、比較的簡単に設定できた気がします。
(調べる前はユーザー自体に広めの権限を渡すという、良くないことをしていました)

業務等で使う場合は、作成/変更するリソースをSCPやCloudFormationの実行Roleで制御し、信頼ポリシーを同一アカウント内全てでなく、用途に合わせて絞るなどの対応が必要になるのかと思います。

無事にCDKを使う準備もできたので、次からはCDKでリソースを作る内容を書いていきたいと思います。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?