TL;DR
cliコマンドで、
s3 cpなら403としか出ないが、
s3api get-objectで、
- IAMの権限不足なら
no identity-based policy allows the s3:GetObject action
- Backet policyなら
denied by a resource-based policy
403エラー
s3 cpした時に403エラーが出たことはありませんか？
私は、CICDの実装や実際にテストをしているときなどにこのエラーにたまに直面します。
この時、どの権限(バケットポリシー、IAM)で落ちたのか？、ログに出してくれよ、、と思いませんか。
そこでs3apiを使うことを推奨できます。
s3 cp のとき
s3 cpをしたときには、このエラーしか出ません。
fatal error: An error occurred (403) when calling the HeadObject operation: Forbidden
Build step 'Execute shell' marked build as failure
s3api get-object のとき
aws s3api put-object --bucket my-bucket --key test.txt --body test.txt
このようなログが出力されます。（ログはマスキングしています）
An error occurred (AccessDenied) when calling the GetObject operation: User: arn:aws:sts::111111111:assumed-role/AAAAA-Role/i-111111111 is not authorized to perform: s3:GetObject on resource: "arn:aws:s3:::AAAAbacket/AAAAfile.tar.gz" because no identity-based policy allows the s3:GetObject action
どのロールでどのバケットに掴みに行っているのか、がよりわかりやすいログが出ました。
このエラーによって、
no identity-based policy allows the s3:GetObject action
とあるので、
IAMが原因で、どのIAMが原因か、まで、わかることができます。
S3が原因のときは、
denied by a resource-based policy
のようなエラーになるので切り分けできます。
また、より詳細には、
--debugオプションを使うことで、
verboseなログを確認することもできますが、こちらはヘッダーなどの確認も含める場合に使えます。
できれば、どのポリシーや、条件で弾かれたのか、までわかるといいなと思いますが、s3apiを使うだけでも特定のロールに着目してポリシーを確認できるので、原因特定までかなり近いですね。
そもそもこれらの違いは何か。
s3 cpの方は、高レベルコマンド、と呼ばれ、よりunixライクな形で、日常使いできるコマンドです。
s3apiの方はapiを直接実行するような形なので、より詳細なエラーログが出せるようになっています。
参考リンク
以上