Tomoya Kabe
チーフエンジニアの加辺です
先日(2020/01/22)弊社で問題となったAWSのサイレントリリースがあったので記事にしようと思います
一部のプロジェクトではCodePipelineの中でCodeBuildを利用しており、そのArtifactを後続のDeployタスクに渡しているのですが、ある時を境に突然CodeBuildからのArtifactsのアップロードが失敗するようになってしまいました
構成
今回の基本的な構成は下図の通りです
見ての通り、CodeCommitやGitHubのようなものをSourceとして設定し、CodeBuildでimageをビルド&ArtifactsをS3に配置し、最後にDeployする、というシンプルなパイプラインです
エラーの中身
どこでエラーが出ているのか確認したところ、CodeBuildの中、最後のUPLOAD_ARTIFACTSでエラーが発生していました
上の図で太線にしているArtifactsの書き出し処理が今回失敗するようになった処理です
CLIENT_ERROR: Error in UPLOAD_ARTIFACTS phase: AccessDenied: Access Denied status code: 403, request id: ABCDABCDABCDABCD, host id: xxxx
見ての通り、Artifactsのアップロードをしようとして権限エラーとなってしまっていました
原因の推測と解決
CodeBuildやCodePipelineの処理内容は何も変えていないことが確認できたため、前回実行成功時のArtifactsを確認してみたところ、ArtifactsがCodeBuildのKMS鍵で暗号化されていることに気がつきました
つまり、下図のような図式であったことがわかります(実際にはArtifactsをECS Deployでは利用していません)
違和感
しかしこの図、何か違和感を覚えます
- Artifact BucketはCodeBuildに設定しているのではなく、CodePipeline側の設定値であり、本来Artifactsを配置する主体はCodePipelineであるはずで、CodeBuildの鍵で暗号化されているのは不自然です
- DeployフェーズでArtifactsを必要とする場合、CodePipelineに権限を付与していないはずのCodeBuild鍵での復号は誰ができるのでしょう？
自然なのはCodeBuildがCodePipelineの鍵でArtifactsを暗号化し、S3へアップロードすることです
推測と解決
そこで立てた推測は「AWSがCodePipelineの挙動を変更し、ArtifactsをCodePipelineの鍵で暗号化するようになった」でした
これを検証するのは簡単で、CodeBuildのRoleに「CodePipelineの鍵を用いて暗号化」の権限を付与すれば動くはずです
果たしてこれは奏功し、無事にパイプラインが走り切りました
またArtifactsはCodePipelineの鍵で暗号化されてS3にアップロードされたことが確認できました
つまり下図のような図式になったと考えられます(CMKが変更されただけです)
- CodeBuildはCodePipelineのCMKを利用してArtifactsを暗号化し、受け取ったCodePipelineがS3へとアップロードする
- 必要となればCodePipelineがDeployに対しArtifactsを復号して渡す
顛末
今回の挙動についてAWSに問い合わせた結果、予想通りの挙動変更が意図的に行われたことが確認できました
AWSは大半の変更をリリースしてくれていますが、時には知らぬ間に挙動が変更されることもあります
大抵の場合悪い方向には向かわないと考え、「どうあったら自然か」を考えた結果トラブルを解決できた事例でした