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

by Tomoaki Nakagawa

Slide 1

Slide 1 text

GitHub Actions Self Hosted Runnerと Amazon EKSを使った Dockerの Build Pipeline Kubernetes Meetup Tokyo #32 2020.07.28

Slide 2

Slide 2 text

GitHub Actions Self Hosted Runnerと Amazon EKSを使った Dockerの Build Pipeline Kubernetes Meetup Tokyo #32 2020.07.28 Secureな

Slide 3

Slide 3 text

・freee 株式会社 SRE チーム  - 2020 年 5 月入社  - 元々はネットワークエンジニア  - オンプレネットワーク設計構築が得意分野  - 最近は GitHub Actions に無限の可能性を感じています    ・twitter  ・@tmnkgwa4    ・GitHub  ・@naka-gawa      Tomoaki Nakagawa 中川智瑛  3 freee株式会社 

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

従来の 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 

Slide 12

Slide 12 text

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  ...  ...  < 権限が強くてツラい...  

Slide 13

Slide 13 text

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 止められなくてツラい...   漏洩した  アクセスキー 

Slide 14

Slide 14 text

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 ファイルが大杉でツラい...  

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

16 03 Section イメージを安全にビルドできる基盤 

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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 

Slide 20

Slide 20 text

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 

Slide 21

Slide 21 text

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 

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

23 CI 基盤の技術スタック  ● 技術スタック    ○ AWS EKS with Spot instance   ○ GitHub Actions Self-hosted Runner   ○ Actions-runner-controller(Operator)

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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  

Slide 27

Slide 27 text

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 

Slide 28

Slide 28 text

28 04 Section まとめ 

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

スモールビジネスを、  世界の主役に。 