Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
GitHub Actions の self-hosted runner と Amazon EK...
Search
Tomoaki Nakagawa
July 28, 2020
Technology
2
3.5k
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
発表資料
Tomoaki Nakagawa
July 28, 2020
Tweet
Share
More Decks by Tomoaki Nakagawa
See All by Tomoaki Nakagawa
EKS Cluster-based Canary Deploy implemented with Terraform Custom Provider
tmnakagawa
1
600
Other Decks in Technology
See All in Technology
Contract One Engineering Unit 紹介資料
sansan33
PRO
0
6.5k
Bill One 開発エンジニア 紹介資料
sansan33
PRO
4
12k
IIWレポートからみるID業界で話題のMCP
fujie
0
380
SFTPコンテナからファイルをダウンロードする
dip
0
370
ユーザーのプロフィールデータを活用した推薦精度向上の取り組み
yudai00
0
400
Perk アプリの技術選定とリリースから1年弱経ってのふりかえり
stomk
0
100
Rubyで作る論理回路シミュレータの設計の話 - Kashiwa.rb #12
kozy4324
1
310
從四件事帶你見識見識 事件驅動架構設計 (EDA)
line_developers_tw
PRO
0
110
マルチテナント+マルチプロダクト SaaS への AI Agent の組み込み方
kworkdev
PRO
2
350
ObsidianをMCP連携させてみる
ttnyt8701
2
120
RubyOnRailsOnDevin+α / DevinMeetupJapan#2
ginkouno
0
450
Long journey of Continuous Delivery at Mercari
hisaharu
1
220
Featured
See All Featured
Reflections from 52 weeks, 52 projects
jeffersonlam
351
20k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.2k
How to Think Like a Performance Engineer
csswizardry
24
1.7k
Producing Creativity
orderedlist
PRO
346
40k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
A Tale of Four Properties
chriscoyier
159
23k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
6
690
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
123
52k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
60k
Rails Girls Zürich Keynote
gr2m
94
14k
Transcript
GitHub Actions Self Hosted Runnerと Amazon EKSを使った Dockerの Build Pipeline
Kubernetes Meetup Tokyo #32 2020.07.28
GitHub Actions Self Hosted Runnerと Amazon EKSを使った Dockerの Build Pipeline
Kubernetes Meetup Tokyo #32 2020.07.28 Secureな
・freee 株式会社 SRE チーム - 2020 年 5 月 入社
- 元々は ネットワークエンジニア - オンプレネットワーク設計構築が得意分野 - 最近は GitHub Actions に無限の可能性を感じています ・twitter ・@tmnkgwa4 ・GitHub ・@naka-gawa Tomoaki Nakagawa 中川 智瑛 3 freee株式会社
4 アジェンダ 1. freee が取り扱うプロダクトの特徴 2. 従来のCIパイプラインが抱えているセキュリティ面での課題 3. コンテナイメージを安全にビルドできる基盤について 4.
まとめ
5 話すこと、話さないこと • 話すこと ◦ freee が抱えていたセキュリティ上問題となる CI パイプラインとそれに対するアプロー チ
• 話さないこと ◦ CD パイプラインに関すること ※本セッションでの "CI" は イメージを registory に push し、いつでもデプロイできるような状態になるまでを指しています。
6 01 Section freee のプロダクトが持つ特徴
freee のプロダクトが持つ特徴 7 • freee のプロダクトは "お金" や "人" に関わる重要な情報が多い
個人事業や 法人の財務情報 従業員の 個人情報や給与情報 従業員の マイナンバー情報
freee のプロダクトが持つ特徴 8 • freee のプロダクトは "お金" や "人" に関わる重要な情報が多い
社会インフラに近づき、多方面においてセキュリティリスクの排除が求められるようになった 個人事業や 法人の財務情報 従業員の 個人情報や給与情報 従業員の マイナンバー情報
freee のプロダクトが持つ特徴 9 • freee のプロダクトは "お金" や "人" に関わる重要な情報が多い
社会インフラに近づき、多方面においてセキュリティリスクの排除が求められるようになった "CI" についても同じように セキュリティリスクの排除が求められる 個人事業や 法人の財務情報 従業員の 個人情報や給与情報 従業員の マイナンバー情報
10 02 Section 従来の CI におけるセキュリティリスク
従来の 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 リスク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 リスク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 リスク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 freee が採用した セキュアな CI の方針 • CI 実行基盤 ◦
CI 実行元を自社の管理下に置くことが必須条件 ◦ かと言って ビルド環境を丁寧にメンテナンスするリソースも無い ◦ CI の コントロールプレーン を SaaS に管理してもらい、ワーカープレーン を 自社で管 理する • CI パイプライン(後半で詳細説明) ◦ テンプレート的なパイプラインを作る ◦ 一括してイメージの脆弱性スキャンを掛けることができる
16 03 Section イメージを安全にビルドできる基盤
freee が採用した CI 基盤 17 • overview runner runner ECR
ECR EKS controller repository repository 外部 SaaS freee 管理範囲 developer developer
freee が採用した CI 基盤 18 • CI workflow runner runner
ECR ECR EKS controller repository repository 1.push 外部 SaaS freee 管理範囲 1.push developer developer
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
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
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
freee が採用した CI 基盤 22 • 前述のセキュリティリスクが解消した 1. 外部
SaaS への権限譲渡問題 ◦ アクセスキーの撲滅できた 2. CI 実行元の制御権問題 ◦ 実行するワーカープレーンのみをVPCに閉じ込めることができた 3. イメージの脆弱性スキャンの管理コスト増 ◦ 集中管理なworkflowで脆弱性スキャンも可能になった
23 CI 基盤の技術スタック • 技術スタック ◦ AWS EKS with
Spot instance ◦ GitHub Actions Self-hosted Runner ◦ Actions-runner-controller(Operator)
24 CI 基盤の技術スタック • AWS EKS with Spot instance ▪
AWS の マネージド Kubernetes サービス を実行基盤とした ▪ CI は基本 Stateless のため、Spot instance と非常に親和性が高い • コストを抑えられるので多様なインスタンスを用意できる • workflow の要件に依って、リソースタイプを変更しやすい nodegroup: default nodegroup: cpu nodegroup: memory < このイメージは CPU 多めで! < このイメージは memory 多めで! このイメージは CI が整備されていればいいけど...>
25 CI 基盤の技術スタック • AWS EKS with Spot instance ▪
AWS の マネージド Kubernetes サービス を実行基盤とした ▪ CI は基本 Stateless のため、Spot instance と非常に親和性が高い • actions runner の "once" オプションを利用することで、workflow が実行され るたびに runner が作られる nodegroup: default < コケたから別の runner で再実行するね!
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 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 04 Section まとめ
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
スモールビジネスを、 世界の主役に。