Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
GitHub Actionsに「強い」AWSの権限を渡したい / AWS credentials on Actions
FUJIWARA Shunichiro
May 14, 2021
Technology
7
11k
GitHub Actionsに「強い」AWSの権限を渡したい / AWS credentials on Actions
FUJIWARA Shunichiro
May 14, 2021
Tweet
Share
More Decks by FUJIWARA Shunichiro
See All by FUJIWARA Shunichiro
1年間のポストモーテム運用とそこから生まれたツール sre-advisor / SRE NEXT 2022
fujiwara3
6
6k
気軽に始めるGraviton2マネージドサービスによるコスト最適化 / Amazon Game Tech Night #23
fujiwara3
4
1.3k
Amazon Auroraを活用したソーシャルゲームの複数ワールドデータ統合 / AWS Dev Day Online Japan
fujiwara3
10
4.8k
ecspresso exec
fujiwara3
0
640
シングルバイナリにこだわる - AWS Lambda編 / Nature Bath vol.6
fujiwara3
4
1.9k
がんばらないスポットインスタンス運用 / Spot-instance-Matsuri
fujiwara3
1
2.8k
knockrd / kichijojipm23
fujiwara3
1
170
Webサービスを1日10回デプロイするための取り組み / SRE NEXT 2020
fujiwara3
22
24k
クラウドネイティブな監視をMackerelで / Mackerel Day#2
fujiwara3
4
3.8k
Other Decks in Technology
See All in Technology
What's new in Vision
satotakeshi
0
220
Building smarter apps with machine learning, from magic to reality
picardparis
4
3.2k
【個人的】オブジェクト指向の現在地
toranoana
0
190
さいきんのRaspberry Pi。 / osc22do-rpi
akkiesoft
6
5.3k
紙にまつわる苦しみを機能化してきた カミナシの歴史
kaminashi
0
1.4k
20220622_FinJAWS_あのときにAWSがあったらこうできた
taketakekaho
0
120
Camp Digital 2022: tailored advice
kyliehavelock
0
150
ソフトウェアテスト自動化、一歩前へ
yoshikiito
6
1.1k
LINEのB2Bプラットフォームにおけるトラブルシューティング2選
line_developers
PRO
4
310
How to start with DDD when you have a Monolith
javujavichi
0
360
UIKitのアップデート #WWDC22
akatsuki174
4
350
スタートアップと技術選定と AWS
track3jyo
PRO
2
350
Featured
See All Featured
The Straight Up "How To Draw Better" Workshop
denniskardys
225
120k
Teambox: Starting and Learning
jrom
123
7.7k
Designing Experiences People Love
moore
130
22k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
10
3.4k
In The Pink: A Labor of Love
frogandcode
131
21k
Clear Off the Table
cherdarchuk
79
280k
Making the Leap to Tech Lead
cromwellryan
113
7.4k
Agile that works and the tools we love
rasmusluckow
319
19k
Code Reviewing Like a Champion
maltzj
506
37k
GraphQLの誤解/rethinking-graphql
sonatard
28
6.6k
Raft: Consensus for Rubyists
vanstee
126
5.5k
Atom: Resistance is Futile
akmur
255
20k
Transcript
GitHub Actionsに「強い」AWSの権限を渡したい 2021.05.14 ⾯⽩法⼈カヤック 藤原俊⼀郎 @fujiwara
@fujiwara SREチーム所属 2011年〜カヤック(10年!) ISUCON 1,2,5優勝、ISUCON 3,8出題 github.com/kayac/ecspresso Amazon ECS デプロイツール
github.com/fujiwara/lambroll AWS Lambda デプロイツール
最近の仕事 ぼくらの甲⼦園ポケット ECS 移⾏ 2014年リリースの⻑寿ゲーム before: EC2 (ondemand & spot)
after: ECS (Fargate & EC2 spot 100%) Perl5.16→5.30 ログ処理をKinesis+Lambdaに API に CloudFront 導⼊ EC2 & Chef 全廃
最近の悩み AWSのリソースの管理は基本 Terraform で⾏っている (アプリケーションだけ ecspresso / lambroll) terraform plan
とその通知は tfnotify github.com/mercari/tfnotify を使って GitHub Actions / CircleCI で実⾏している 現状 terraform apply は各⾃の⼿元(⼀部は専⽤EC2)で実⾏している apply も CI/CD 環境で実⾏したい!
現状、terraform apply を CI/CD 環境で実⾏していない理由 実⾏に「強い」権限が必要 (⼤抵 Administrator 権限と同等) 強すぎる
IAM User のアクセスキーを外部に預けたくない アクセスキーは環境変数に設定される リポジトリへの書き込み権限を取得されると、奪取される可能性がある Classi の事故 corp.classi.jp/news/2416/ フィッシングからGitHubアクセス キーをコードに書いていなくても、CIをいじって実⾏されたらキーは抜かれる GitHubで全員にMFA強制はなかなか難しい (外部の⼈も全員強制になる)
でも本当はやりたい 開発者、運⽤者の⼿元が安全とは限らない ⼈に依存しない環境で実⾏できるようにしておきたい 条件 権限は安全に保ちたい GitHubリポジトリの書き込み権が奪われてもAWSの権限は渡したくない うっかり誤クリックや誤mergeでは発動したくない 狙ったタイミングで、特定の⼈だけが発動したい
作戦1 - AssumeRole with MFA MFA を使って assume role して「強い」権限を得る作戦
作戦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" } } }
作戦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" } } }
作戦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/
作戦1 - AssumeRole with MFA
作戦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
作戦1 - AssumeRole with MFA いいところ Actionsに設定されているアクセスキー単体では何もできないので漏洩が怖くない 実⾏時に⼈が MFA token
を⼊⼒するのでうっかり誤発動しない 再実⾏しても token が有効期限切れになっているので動かない いまいちなところ MFAの設定を複数⼈で共有する必要がある (QRコード) IAM User の MFA はひとつしか作れないため MFA token の取得から実⾏までに時間が掛かると有効期限が切れる Actionsの環境起動に10〜20秒かかるので、残り時間を⾒極めて投⼊が必要
作戦2 - CloudShell exports credentials AWS CloudShellが持っている権限を頂いてしまおう作戦
作戦2 - CloudShell exports credentials AWS CloudShell マネージメントコンソールを開いている⼈の権限が設定されている 外部へのネットワークアクセスが可能
作戦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" }
作戦2 - CloudShell exports credentials AWS_CONTAINER_CREDENTIALS_FULL_URI http://localhost:1338/latest/meta-data/container/security-credentials つまり CloudShell の
localhost:1338 に外部から繋げれば CloudShell が持っているアクセスキーを取得できるのでは…?
作戦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に繋がる
作戦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", ...
作戦2 - CloudShell exports credentials まとめ . 「強い」権限を持っている⼈が CloudShell を起動
. CloudShell で cloudflared を起動して外部に localhost:1338 を公開する . $AWS_CONTAINER_AUTHORIZATION_TOKEN と公開URLをActionsに⼊⼒ . Actions からURLにアクセスしてアクセスキーを取得
作戦2 - CloudShell exports credentials いいところ 強い権限を持った⼈間 (マネージメントコンソールにログインできている) がいるときだ け、その⼈の権限をその場で渡せる
cloudflared を停⽌したり CloudShell を閉じればアクセスできなくなる 閉じてしまえばうっかり再実⾏しても権限は取れない 渡したアクセスキー⾃体にも有効期限がある CloudShellは無操作だと20〜30分で停⽌される いまいちなところ cloudflared の中をアクセスキーが通過するのをどう考えるか Cloudflareがここで変なことはしないと信頼するかどうかによる AWSが同様のサービスを出してくれたら万事解決では…?
まとめ AWS外に強すぎる権限のアクセスキーを保管しないために、いろいろ考えてみました . AssumeRole with MFA 作戦 実はMFAなしでも簡易的な対策になる キーだけでは sts:AssumeRole
しかできない とはいえassume roleの⼿順は .github/workflows に書いてあるのでちゃんと読まれ たら危ない . CloudShell exports credentials 作戦 没案: Self Hosted Runner EC2でActionsの実⾏環境を⽤意して強い権限を設定しておけば…? workflowをいじられたら強い権限でなんでもできてしまう うっかり再実⾏を防げない