GitHub Actionsに「強い」AWSの権限を渡したい / AWS credentials on Actions

Transcript

1. GitHub Actionsに「強い」AWSの権限を渡したい 2021.05.14 ⾯⽩法⼈カヤック 藤原俊⼀郎 @fujiwara

2. @fujiwara SREチーム所属 2011年〜カヤック(10年!) ISUCON 1,2,5優勝、ISUCON 3,8出題 github.com/kayac/ecspresso Amazon ECS デプロイツール

   github.com/fujiwara/lambroll AWS Lambda デプロイツール

3. 最近の仕事 ぼくらの甲⼦園ポケット ECS 移⾏ 2014年リリースの⻑寿ゲーム before: EC2 (ondemand & spot)

   after: ECS (Fargate & EC2 spot 100%) Perl5.16→5.30 ログ処理をKinesis+Lambdaに API に CloudFront 導⼊ EC2 & Chef 全廃

4. 最近の悩み AWSのリソースの管理は基本 Terraform で⾏っている (アプリケーションだけ ecspresso / lambroll) terraform plan

   とその通知は tfnotify github.com/mercari/tfnotify を使って GitHub Actions / CircleCI で実⾏している 現状 terraform apply は各⾃の⼿元(⼀部は専⽤EC2)で実⾏している apply も CI/CD 環境で実⾏したい！

5. 現状、terraform apply を CI/CD 環境で実⾏していない理由 実⾏に「強い」権限が必要 (⼤抵 Administrator 権限と同等) 強すぎる

   IAM User のアクセスキーを外部に預けたくない アクセスキーは環境変数に設定される リポジトリへの書き込み権限を取得されると、奪取される可能性がある Classi の事故 corp.classi.jp/news/2416/ フィッシングからGitHubアクセス キーをコードに書いていなくても、CIをいじって実⾏されたらキーは抜かれる GitHubで全員にMFA強制はなかなか難しい (外部の⼈も全員強制になる)

6. でも本当はやりたい 開発者、運⽤者の⼿元が安全とは限らない ⼈に依存しない環境で実⾏できるようにしておきたい 条件 権限は安全に保ちたい GitHubリポジトリの書き込み権が奪われてもAWSの権限は渡したくない うっかり誤クリックや誤mergeでは発動したくない 狙ったタイミングで、特定の⼈だけが発動したい

7. 作戦1 - AssumeRole with MFA MFA を使って assume role して「強い」権限を得る作戦

8. 作戦1 - AssumeRole with MFA IAM Userを作ってアクセスキーを発⾏する sts:AssumeRole だけを付与する MFAを必須にする(QRコードは控えておく)

   ユーザーのIAM Policy { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::123456789012:role/TerraformApply", "Condition": { "BoolIfExists": { "aws:MultiFactorAuthPresent": "true" } } }

9. 作戦1 - AssumeRole with MFA terraform apply ⽤の「強い」 IAM Role

   を作る 作った IAM User を信頼する assume role policy { "Effect": "Allow", "Action": "sts:AssumeRole", "Principal": { "AWS": "arn:aws:iam::123456789012:user/GitHubActions" }, "Condition": { "BoolIfExists": { "aws:MultiFactorAuthPresent": "true" } } }

10. 作戦1 - AssumeRole with MFA GitHub Actionsで、 . IAM User

    のアクセスキーを secrets に設定 このキーが取られてもMFAがないとなにもできない . manual trigger のジョブを作る MFA token⼊⼒欄も定義する name: apply on: workflow_dispatch: inputs: token-code: description: 'mfa code' required: true github.blog/changelog/2020-07-06-github-actions-manual-triggers-with- workflow_dispatch/

11. 作戦1 - AssumeRole with MFA

12. 作戦1 - AssumeRole with MFA . secrets のアクセスキーを設定 . aws

    sts assume-role をマニュアル⼊⼒した MFA token で実⾏ . 「強い」Roleの権限を取得できる！ jobs: manual: runs-on: ubuntu-latest steps: - name: Configure AWS Credentials uses: aws-actions/configure-aws-credentials@v1 with: aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} aws-region: ap-northeast-1 - name: aws sts AssumeRole with MFA run: | OUTPUT=`aws sts assume-role \ --role-arn arn:aws:iam::123456789012:role/TerraformApply \ --role-session-name github-actions \ --duration-seconds 900 \ --serial-number arn:aws:iam::123456789012:mfa/GithubActions \ --token-code ${{ github.event.inputs.token-code }}` echo AWS_ACCESS_KEY_ID=`echo $OUTPUT | jq -r .Credentials.AccessKeyId` >> $GITHUB_ENV echo AWS_SECRET_ACCESS_KEY=`echo $OUTPUT | jq -r .Credentials.SecretAccessKey` >> $GITHUB_ENV echo AWS_SESSION_TOKEN=`echo $OUTPUT | jq -r .Credentials.SessionToken` >> $GITHUB_ENV shell: bash

13. 作戦1 - AssumeRole with MFA いいところ Actionsに設定されているアクセスキー単体では何もできないので漏洩が怖くない 実⾏時に⼈が MFA token

    を⼊⼒するのでうっかり誤発動しない 再実⾏しても token が有効期限切れになっているので動かない いまいちなところ MFAの設定を複数⼈で共有する必要がある (QRコード) IAM User の MFA はひとつしか作れないため MFA token の取得から実⾏までに時間が掛かると有効期限が切れる Actionsの環境起動に10〜20秒かかるので、残り時間を⾒極めて投⼊が必要

14. 作戦2 - CloudShell exports credentials AWS CloudShellが持っている権限を頂いてしまおう作戦

15. 作戦2 - CloudShell exports credentials AWS CloudShell マネージメントコンソールを開いている⼈の権限が設定されている 外部へのネットワークアクセスが可能

16. 作戦2 - CloudShell exports credentials CloudShell で設定されている AWS_ の環境変数 $

    env | grep AWS_ |sort AWS_CONTAINER_AUTHORIZATION_TOKEN=******* AWS_CONTAINER_CREDENTIALS_FULL_URI=http://localhost:1338/latest/meta-data/container/security-credentials AWS_DEFAULT_REGION=ap-northeast-1 AWS_EXECUTION_ENV=CloudShell AWS_REGION=ap-northeast-1 これでアクセスキーが取得できる $ curl -H"Authorization: $AWS_CONTAINER_AUTHORIZATION_TOKEN" \ $AWS_CONTAINER_CREDENTIALS_FULL_URI { "LastUpdated": "1970-01-01T00:00:00Z", "Type": "", "AccessKeyId": "ASIAUSOAHXO5WFCZF5GW", "SecretAccessKey": "xxxxxxxxxx", "Token": "xxxxxxxxxxxx" "Expiration": "2021-05-13T06:09:04Z", "Code": "Success" }

17. 作戦2 - CloudShell exports credentials AWS_CONTAINER_CREDENTIALS_FULL_URI http://localhost:1338/latest/meta-data/container/security-credentials つまり CloudShell の

    localhost:1338 に外部から繋げれば CloudShell が持っているアクセスキーを取得できるのでは…?

18. 作戦2 - CloudShell exports credentials cloudflared - Argo Tunnel client

    github.com/cloudflare/cloudflared ngrok みたいなやつ by Cloudflare CloudShell にインストールして起動。バイナリを置くだけ $ curl -sL https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-amd64.tgz | tar zxvf - cloudflared $ ./cloudflared tunnel --url localhost:1338 ( 略) 2021-05-13T06:00:37Z INF +-----------------------------------------------------------+ 2021-05-13T06:00:37Z INF | Your free tunnel has started! Visit it: | 2021-05-13T06:00:37Z INF | https://hardcover-mixing-bs-madness.trycloudflare.com | 2021-05-13T06:00:37Z INF +-----------------------------------------------------------+ 表⽰されるURL(毎回異なる)にアクセスするとCloudShellのlocalhost:1338に繋がる

19. 作戦2 - CloudShell exports credentials これでどこからでも ($AWS_CONTAINER_AUTHORIZATION_TOKENがあれば) HTTPSで取得できる $ curl

    -H"Authorization: $AWS_CONTAINER_AUTHORIZATION_TOKEN" \ https://hardcover-mixing-bs-madness.trycloudflare.com/latest/meta-data/container/security-credentials { "LastUpdated": "1970-01-01T00:00:00Z", "Type": "", "AccessKeyId": "ASIAUSOAHXO54XC5257P", ...

20. 作戦2 - CloudShell exports credentials まとめ . 「強い」権限を持っている⼈が CloudShell を起動

    . CloudShell で cloudflared を起動して外部に localhost:1338 を公開する . $AWS_CONTAINER_AUTHORIZATION_TOKEN と公開URLをActionsに⼊⼒ . Actions からURLにアクセスしてアクセスキーを取得

21. 作戦2 - CloudShell exports credentials いいところ 強い権限を持った⼈間 (マネージメントコンソールにログインできている) がいるときだ け、その⼈の権限をその場で渡せる

    cloudflared を停⽌したり CloudShell を閉じればアクセスできなくなる 閉じてしまえばうっかり再実⾏しても権限は取れない 渡したアクセスキー⾃体にも有効期限がある CloudShellは無操作だと20〜30分で停⽌される いまいちなところ cloudflared の中をアクセスキーが通過するのをどう考えるか Cloudflareがここで変なことはしないと信頼するかどうかによる AWSが同様のサービスを出してくれたら万事解決では…?

22. まとめ AWS外に強すぎる権限のアクセスキーを保管しないために、いろいろ考えてみました . AssumeRole with MFA 作戦 実はMFAなしでも簡易的な対策になる キーだけでは sts:AssumeRole

    しかできない とはいえassume roleの⼿順は .github/workflows に書いてあるのでちゃんと読まれ たら危ない . CloudShell exports credentials 作戦 没案: Self Hosted Runner EC2でActionsの実⾏環境を⽤意して強い権限を設定しておけば…? workflowをいじられたら強い権限でなんでもできてしまう うっかり再実⾏を防げない