IAM

前回投稿でAWS CodePipelineのクロスアカウント設定（前半）ではリソース配布元のアカウントAの内容中心に書いた。後半は配布先となるアカウントBの設定内容を書いていく。 前回投稿 AWS CodeDeployでクロスアカウントデプロイ実行（パイプラインあり-1） 繰り返しになるけれども、前提条件をおさらいとして記載。 やりたいこと AWSの異なるアカウント間で、CodePipelineによりCodeDeployからec2インスタンスにリソースをデプロイする。ソースはリソース配布側のCodeCommit。この記事では配布元を開発環境/アカウントA、配布先を検証環境/アカウントBとして話を進める。 主な参考ページ 他のリソースを使用するパイプラインを CodePipeline で作成するAWSアカウント 主な構成要素 これも前回書いているが、こっちにも書いておかないとわけわからなくなるので再掲。 1-資材配布元（アカウントA） ① CodeCommitリポジトリ（ec2にローカルリポジトリを作成〜資材格納） ② KMSキー (両方のアカウントにアクセス許可する) ③ S3バケット (アカウントBにアクセス許可するバケットポリシーを付与） ④ CodePipelineが使用するサービスロール ⑤ CodePipleline定義（コンソールで作成したパイプライン定義JSONをCLIから更新） 2-資材配布先（アカウントB） ① CodeDeploy定義（アプリケーション/デプロイメントグループ） ② ec2用のIAMロール（CodeDeployがアカウントAのKMSキー、S3にアクセスするためのポリシーを付与） ③ ②のIAMロールをアタッチしたデプロイ先ec2 ④ クロスアカウント用サービスロール（CodeDeployとS3操作にassumeする） 上記アイテムを作成済みとして、作業概要は前回記事に記載した。以降、アカウントB側で用意するアイテムの内容を書く。 2-① CodeDeploy定義 アカウントBのコンソールにて、アプリケーションとデプロイメントグループを作成する。詳細は割愛。 2-② ec2用のIAMロール KMSとS3用のインラインポリシーを作成する。AWS参考ページでは2つに分けていたが統合しても問題ないと思う。 KMS用インラインポリシー { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kms:DescribeKey", "kms:GenerateDataKey*", "kms:Encrypt", "kms:ReEncrypt*", "kms:Decrypt" ], "Resource": [ "arn:aws:kms:us-east-1:[アカウントAのID]:key/[Key ID]" #KMSのARN ] } ] } S3用インラインポリシー...

前回投稿ではパイプラインなしでAWS クロスアカウントデプロイをやった。次はパイプラインを使ってやってみる。長くなるので前半/後半に分ける。 やりたいこと AWSの異なるアカウント間で、CodePipelineによりCodeDeployからec2インスタンスにリソースをデプロイする。ソースはリソース配布側のCodeCommit。この記事では配布元を開発環境/アカウントA、配布先を検証環境/アカウントBとして話を進める。（ec2はオートスケールもなくただ単に配布するだけなので単一アカウントだったら簡単な話なんだが、アカウント跨ぐとなるとめっちゃ面倒くさい…） 主な参考ページ 他のリソースを使用するパイプラインを CodePipeline で作成するAWSアカウント 基本的にこのページの通りにやればOK。アカウントA側で一度単一アカウント用の適当なパイプラインを作成して、そのJSON定義を取得。それをクロスアカウント用に編集してCLIからアップデートする。ちなみに上記リンクは日本語版だが機械翻訳の文章がまともな日本語ではなくイラッとくるので、ほぼオリジナルの英語版を参考にした。 参考までに、以下クラメソさんの記事。当初これのBuildをDeployに置き換えてやってみたが失敗した。不足か誤りがあるんだろうがいきなりやったこともありわけがわからなすぎて頓挫。先述のAWS公式の方がやりたいことに近かったため仕切り直しした。 クロスアカウントCodeBuild + パイプライン例 CodePipelineでアカウントをまたいだパイプラインを作成してみる 制約事項 クロスアカウントのパイプラインはマネジメントコンソールから作成不可のため、aws cliから作成/更新する CodeDeployの定義とデプロイ先のec2は同一アカウントであること クロスアカウントでパイプラインを組む場合、アーティファクト格納用S3バケットの暗号化キーはKMSを使用する（AWS デフォルトの暗号化キーはNG） 主な構成要素 2アカウント間で各種アイテムを用意することになり、混乱しがちなのでまとめておく。前回投稿では配布先となるアカウントB側にS3バケットがある構成だったが、今回は逆。ただし構成的にはこちらの方が自然かと思う。 1-資材配布元（アカウントA） ① CodeCommitリポジトリ（ec2にローカルリポジトリを作成〜資材格納） ② KMSキー (両方のアカウントにアクセス許可する) ③ S3バケット (アカウントBにアクセス許可するバケットポリシーを付与） ④ CodePipelineが使用するサービスロール ⑤ CodePipleline定義（コンソールで作成したパイプライン定義JSONをCLIから更新） JSON取得コマンド $ aws codepipeline get-pipeline --name [パイプライン名] > [パイプライン名].json 2-資材配布先（アカウントB） ① CodeDeploy定義（アプリケーション/デプロイメントグループ） ② ec2用のIAMロール（CodeDeployがアカウントAのKMSキー、S3にアクセスするためのポリシーを付与） ③ ②のIAMロールをアタッチしたデプロイ先ec2 ④ クロスアカウント用サービスロール（CodeDeployとS3操作にassumeする） 作業概要 上記各リソースを作成済として、以下の作業を行う。 アカウントAの作業用端末またはec2にログイン。1-⑤のパイプライン定義JSONを適当なパスに配置し、パイプラインをアップデートする $ cd /path/to/json $ aws codepipeline update-pipeline --cli-input-json file://[パイプライン名].json アップデートしたパイプラインを実行する $ aws codepipeline start-pipeline-execution --name [パイプライン名] アカウントBでは特に作業なし。デプロイステータスが成功になったら、ec2に資材がデプロイされていることを確認する。...

AWS環境で、クロスアカウントでCI/CDしたい。とりあえずBuildフェーズはいらなくてDeployだけでいい。Deployの実行はパイプラインあり/なし両方可能。どちらも単一アカウント内なら複雑な設定もなく比較的容易にできることはわかっているが、クロスアカウントとなると何かと面倒だ。でもやってみる。ここではまずはパイプラインなしとする。 参考 異なる AWS アカウントでアプリケーションをデプロイする （上記ページにリンクあり。assumeロールの設定は以下参考） IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任 環境前提 配布元となるAWS開発環境(Dev)にCodeCommitのローカルリポジトリがあり、そこから別アカウントの検証環境(Stg)にデプロイする。その先には本番環境がある想定だが構成は同じになるはず。 ① 配布元(Dev) ② 配布先(Stg) 概要 ①配布元のアカウントから②配布先のec2にデプロイ可能とするため、②配布先アカウント側で①アカウントのassumeを可能とするIAMロールを作成する。（ロールAとする）① 配布元アカウント側でロールAにassumeし、デプロイを実行する。 基本的に必要となるのはIAM周りの設定であり、ネットワーク系の特別な実装は必要ない。 作業内容 配布先②アカウントにて、配置用のS3バケットを作成する。IAMロールのポリシーでバケットへのアクセス権限を定義するため、バケットポリシーは設定しなくても問題なし。(注1) 配布先②アカウントにて、①がassumeするためのロールAを作成する。 ロールAで定義する内容 (1) 信頼ポリシーで②のアカウントIDを指定してassumeを許可する。このときrootか②側のIAMロールどちらかを指定する。 rootに設定した場合は、①アカウントでデプロイを実行するユーザのグループにassume可能とするインラインポリシーを適用する。 IAMに設定した場合は、①アカウントでデプロイを実行するec2にこのIAMロールを適用する。実行環境がec2の場合はこれでよいが、クライアント端末の場合はrootにする。 インラインポリシー例 (①アカウントで設定) デプロイ実行ユーザが所属するグループの画面を開き、[アクセス許可] タブ –> [アクセス許可の追加] –> [インラインポリシーの作成] [JSON] タブ選択 以下の内容を設定する。 { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::②配布先のアカウントID:role/ロールA" } } (2) ①のアカウントが資材配置用のS3にアクセスするための権限を定義したポリシーを適用する。ちゃんと書いてないけど以下にcodedeploy, ec2の操作権限も追加する。codedeployの権限は何が必要かわからないのでとりあえず全許可にしておいた。ECSへのデプロイだとec2のterminate権限が必要みたいだが、今回の場合ec2は参照のみでOKだと思う。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": "arn:aws:s3:::staging-app" #検証環境の資材格納バケット名 }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": "arn:aws:s3:::staging-app/*" } ] } ②配布先アカウントにて、deployのアプリケーションとデプロイメントグループを作成する。詳細は割愛。 ①配布元アカウントのec2（または同アカウントのcredentialsをセットした端末）にログインし、ロールAにスイッチする。ちなみにマネジメントコンソールでもスイッチして作業可能だが、deployのpushコマンドがCLIでしかできないため、ここではCLI前提で話を進める。 この時先で作成したロールAにスイッチするため、以下のコマンドを実行する。...