GitHub Actions の self-hosted runner と Amazon EKS を使った Docker の Build Pipeline/Build Pipeline for Docker with GitHub Actions self-hosted runner and Amazon EKS

Kubernetes Meetup Tokyo #32 on 7/28
発表資料

Transcript

1. GitHub Actions Self Hosted Runnerと Amazon EKSを使った Dockerの Build Pipeline Kubernetes Meetup Tokyo #32 2020.07.28
2. GitHub Actions Self Hosted Runnerと Amazon EKSを使った Dockerの Build Pipeline Kubernetes Meetup Tokyo #32 2020.07.28 Secureな
3. ・freee 株式会社 SRE チーム
 - 2020 年 5 月 入社
 - 元々は ネットワークエンジニア
 - オンプレネットワーク設計構築が得意分野
 - 最近は GitHub Actions に無限の可能性を感じています
 
 ・twitter
 ・@tmnkgwa4
 
 ・GitHub
 ・@naka-gawa
 
 
 Tomoaki Nakagawa 中川 智瑛
 3 freee株式会社

4. 4 アジェンダ
 1. freee が取り扱うプロダクトの特徴
 2. 従来のCIパイプラインが抱えているセキュリティ面での課題
 3. コンテナイメージを安全にビルドできる基盤について
 4. まとめ

5. 5 話すこと、話さないこと
 • 話すこと
 ◦ freee が抱えていたセキュリティ上問題となる CI パイプラインとそれに対するアプロー チ
 
 
 
 
 • 話さないこと
 ◦ CD パイプラインに関すること
 ※本セッションでの "CI" は イメージを registory に push し、いつでもデプロイできるような状態になるまでを指しています。
 

6. 6 01 Section freee のプロダクトが持つ特徴

7. freee のプロダクトが持つ特徴
 7 • freee のプロダクトは "お金" や "人" に関わる重要な情報が多い
 個人事業や
 法人の財務情報
 従業員の
 個人情報や給与情報
 従業員の
 マイナンバー情報

8. freee のプロダクトが持つ特徴
 8 • freee のプロダクトは "お金" や "人" に関わる重要な情報が多い
 
 社会インフラに近づき、多方面においてセキュリティリスクの排除が求められるようになった
 個人事業や
 法人の財務情報
 従業員の
 個人情報や給与情報
 従業員の
 マイナンバー情報

9. freee のプロダクトが持つ特徴
 9 • freee のプロダクトは "お金" や "人" に関わる重要な情報が多い
 
 社会インフラに近づき、多方面においてセキュリティリスクの排除が求められるようになった
 
 "CI" についても同じように
 セキュリティリスクの排除が求められる
 個人事業や
 法人の財務情報
 従業員の
 個人情報や給与情報
 従業員の
 マイナンバー情報

10. 10 02 Section 従来の CI におけるセキュリティリスク

11. 従来の CI パイプラインの概要
 11 • 従来の CI パイプラインとはどのようなものだったか
 ◦ シンプルに 外部 SaaS の コンピュートリソース上で CI を実行していた ◦ ただし、下記のセキュリティリスクを内包している 1. 外部 SaaS への権限譲渡問題
 2. CI 実行元の制御権問題
 3. イメージの脆弱性スキャンの管理コスト増
 freee 管理範囲
 repository
 外部 SaaS
 compute resource
 developer
 1.push
 2.actions ignition
 ecr
 3.workflow run
 4.artifact upload

12. 12 リスク1. 外部 SaaS への権限譲渡問題
 • 外部 SaaS から自社AWS のリソースを触るにはアクセスキーが必要
 • 運用開始当初は厳格に制限されていたが、長年の運用により煩雑且つ強い権限に育って しまいがち
 freee 管理範囲
 repository
 外部 SaaS
 compute resource
 developer
 1.push
 2.actions ignition
 ecr
 4.artifact upload
 3.workflow run
 s3
 code
 build
 lambda
 ...
 ...
 < 権限が強くてツラい... 

13. 13 リスク2. CI 実行元の制御権問題
 • 多くの CI サービスの場合、インスタンスが freee の管理下に居ない、もしくは管理下に置 こうとすると、CI コントロールプレーンを含め全て自社で管理する必要が出てくる
 • 漏洩したアクセスキーによる悪意のあるイメージの push をコントロールできない
 freee 管理範囲
 repository
 外部 SaaS
 compute resource
 developer
 1.push
 2.actions ignition
 ecr
 3.workflow run
 4.artifact upload
 < push 止められなくてツラい... 
 漏洩した
 アクセスキー

14. 14 リスク3. イメージ脆弱性スキャンの管理コスト増
 • 理想としてはイメージビルド時に脆弱性スキャンを掛けたい
 ◦ 深刻な脆弱性が検出された場合は push 自体を止めたい • それぞれの CI の workflow ファイルが散逸している状況だと導入するのが困難
 freee 管理範囲
 外部 SaaS
 ecr
 repository
 compute resource
 developer
 1.push
 2.actions ignition
 3.workflow run
 repository
 compute resource
 developer
 1.push
 2.actions ignition
 3.workflow run
 repository
 compute resource
 developer
 1.push
 2.actions ignition
 3.workflow run
 ...
 < workflow ファイルが大杉でツラい... 

15. 15 freee が採用した セキュアな CI の方針
 • CI 実行基盤
 ◦ CI 実行元を自社の管理下に置くことが必須条件 ◦ かと言って ビルド環境を丁寧にメンテナンスするリソースも無い ◦ CI の コントロールプレーン を SaaS に管理してもらい、ワーカープレーン を 自社で管 理する 
 • CI パイプライン（後半で詳細説明）
 ◦ テンプレート的なパイプラインを作る ◦ 一括してイメージの脆弱性スキャンを掛けることができる
16. 16 03 Section イメージを安全にビルドできる基盤

17. freee が採用した CI 基盤
 17 • overview
 runner
 runner
 ECR
 ECR EKS
 controller
 repository
 repository
 外部 SaaS
 freee 管理範囲
 developer
 developer

18. freee が採用した CI 基盤
 18 • CI workflow
 runner
 runner
 ECR
 ECR
 EKS
 controller
 repository
 repository
 1.push
 外部 SaaS
 freee 管理範囲
 1.push
 developer
 developer

19. freee が採用した CI 基盤
 19 • CI workflow
 runner
 runner
 ECR
 ECR
 EKS
 controller
 repository
 repository
 1.push
 外部 SaaS
 freee 管理範囲
 developer
 developer
 1.push
 2.actions ignition
 2.actions ignition

20. freee が採用した CI 基盤
 20 • CI workflow
 runner
 ECR
 ECR
 EKS
 controller
 repository
 repository
 1.push
 2.actions ignition
 外部 SaaS
 freee 管理範囲
 3.workflow run
 ※後半で説明
 runner
 3.workflow run
 developer
 developer
 1.push
 2.actions ignition
 集中管理的な
 workflow

21. freee が採用した CI 基盤
 21 • CI workflow
 runner
 集中管理的な
 workflow
 ECR
 ECR
 EKS
 controller
 repository
 repository
 1.push
 4.artifact upload
 外部 SaaS
 freee 管理範囲
 3.workflow run
 4.artifact upload
 ※後半で説明
 runner
 3.workflow run
 developer
 developer
 1.push
 2.actions ignition
 2.actions ignition

22. freee が採用した CI 基盤
 22 • 前述のセキュリティリスクが解消した
 
 1. 外部 SaaS への権限譲渡問題
 ◦ アクセスキーの撲滅できた
 
 2. CI 実行元の制御権問題
 ◦ 実行するワーカープレーンのみをVPCに閉じ込めることができた
 
 3. イメージの脆弱性スキャンの管理コスト増
 ◦ 集中管理なworkflowで脆弱性スキャンも可能になった

23. 23 CI 基盤の技術スタック
 • 技術スタック
 
 ◦ AWS EKS with Spot instance 
 ◦ GitHub Actions Self-hosted Runner 
 ◦ Actions-runner-controller(Operator)
24. 24 CI 基盤の技術スタック
 • AWS EKS with Spot instance
 ▪ AWS の マネージド Kubernetes サービス を実行基盤とした ▪ CI は基本 Stateless のため、Spot instance と非常に親和性が高い • コストを抑えられるので多様なインスタンスを用意できる • workflow の要件に依って、リソースタイプを変更しやすい nodegroup: default
 nodegroup: cpu
 nodegroup: memory 
 < このイメージは CPU 多めで！ 
 < このイメージは memory 多めで！ 
 このイメージは CI が整備されていればいいけど...> 

25. 25 CI 基盤の技術スタック
 • AWS EKS with Spot instance
 ▪ AWS の マネージド Kubernetes サービス を実行基盤とした ▪ CI は基本 Stateless のため、Spot instance と非常に親和性が高い • actions runner の "once" オプションを利用することで、workflow が実行され るたびに runner が作られる nodegroup: default
 < コケたから別の runner で再実行するね！ 

26. 26 CI 基盤の技術スタック
 • GitHub Actions Self-hosted Runner
 ◦ CI 実行のコンピュートリソースを自社管理下に配置する機能 
 
 
 
 
 
 ◦ runner となるコンピュートリソースを GitHub を登録する必要がある repository
 compute resource
 developer
 ecr
 repository
 compute resource
 developer
 ecr
 [GitHub Actions]
 [GitHub Actions Self-hosted Runner] 
 2.config generate
 1.get tokens for runners 
 3.Send the config to GitHub 

27. 27 CI 基盤の技術スタック
 • Actions-runner-controller(Operator)
 ▪ Kubernetes を拡張し、Self-hosted runner の登録削除 step を自動化する Operator • runner pod が作成する際に、controller が GitHub への登録を実行する ▪ runner pod 内では ベースコンテナは runner 、サイドカーとして docker コンテナ が起動している https://github.com/summerwind/actions-runner-controller Controller
 actions-runner-controller 
 runner
 Deployment
 runner
 runner
 runner
 runner
 runner
 runner
 runner
 Replicaset
 token
 host docker
 priviledge
 container
 docker
 runner
 container
 runner pod
 regist/remove
 Job Listen
 token
 request
 token
 reply

28. 28 04 Section まとめ

29. 29 まとめ
 • セキュアな CI 実行基盤として、Self-hosted は必須機能
 ◦ コントロールプレーンのみを外部 SaaS に委譲しつつ、自社運用範囲を worker のみ に制限できる点は魅力的 
 • Kubernetes with spot instance の組み合わせによる CI 実行基盤という選択肢は非常に 有効
 
 • Stateless が故に取りづらい施策もあるので今後実装していく
 ◦ docker build 時の layer cache 問題 ▪ remote cache なら導入は容易だが、RW の遅延 ◦ build 時のログを s3 にとって置かないと調査しにくくなる ▪ GitHub 側の設定で戦えなくも無いがきちんとログを取っておく必要がある • ACTIONS_STEP_DEBUG と ACTIONS_RUNNER_DEBUG
30. スモールビジネスを、
 世界の主役に。