KubernetesとTerraformのセキュリティ/ガバナンス向上委員会 with OPA

by saramune

Slide 1

Slide 1 text

Slide 2

Slide 2 text

自己紹介 2 ● 古屋啓介 ○ Chatwork株式会社プロダクト本部 SRE部 ○ 2022年2月入社 ● 普段のおしごと ○ AWSとイチャイチャ ■ Aurora ■ EKS ○ ※セキュリティの専門家というわけではないです

Slide 3

Slide 3 text

会社概要 3 会社名 Chatwork株式会社代表取締役CEO 山本正喜従業員数 304名（2022年9月末日時点）所在地東京、大阪、ベトナム、台湾設立 2004年11月11日

Slide 4

Slide 4 text

Chatworkとは 4 効率的に情報共有できるグループチャット仕事の見える化ができるタスク管理見落としがなくなるファイル管理いつでも会議ができるビデオ/音声通話 * BOXIL SaaS AWARD 2022「ランキング部門コラボレーション部門賞」「ベスト評価賞（初期設定の容易さNo.1、価格の満足度No.1）」を受賞　BOXIL「Chatwork」口コミ評価 * Nielsen NetView 及びNielsen Mobile NetView Customized Report 2022年5月度調べ月次利用者（MAU:Monthly Active User）調査。 * 調査対象はChatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む47サービスをChatwork株式会社にて選定。

Slide 5

Slide 5 text

Chatworkは利用者数No.1*のビジネスチャット 5 3月リリース 10万社突破！ 20万社突破！導入社数 37万6000社以上！ (2022年9月末日時点) 30万社突破！ * Nielsen NetView 及びNielsen Mobile NetView Customized Report 2022年5月度調べ月次利用者（MAU:Monthly Active User）調査。 * 調査対象はChatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む47サービスをChatwork株式会社にて選定。

Slide 6

Slide 6 text

Chatworkの構成（ざっくり） 6

Slide 7

Slide 7 text

Kubernetesのセキュリティ向上について Terraformの安全な運用について AWSリソース作成のガードレールについて 1 2 3 AGENDA アジェンダ

Slide 8

Slide 8 text

Kubernetesのセキュリティ向上について 1

Slide 9

Slide 9 text

Kubernetesのセキュリティ大丈夫ですか？

Slide 10

Slide 10 text

Kubernetesのセキュリティ大丈夫ですか？

Slide 11

Slide 11 text

クラウドネイティブセキュリティの4C 11 ● Kubernetesのドキュメントによると ○ コード ○ コンテナ ○ クラスター ○ クラウド https://kubernetes.io/ja/docs/concepts/security/overview/

Slide 12

Slide 12 text

コンテナに関する懸念事項 12 ● さらに詳細に ○ コンテナの脆弱性スキャンとOS依存のセキュリティ ○ イメージの署名と実施 ○ 特権ユーザーを許可しない https://kubernetes.io/ja/docs/concepts/security/overview/

Slide 13

Slide 13 text

コンテナに関する懸念事項 13 ● さらに詳細に ○ コンテナの脆弱性スキャンとOS依存のセキュリティ ○ イメージの署名と実施 ○ 特権ユーザーを許可しない https://kubernetes.io/ja/docs/concepts/security/overview/

Slide 14

Slide 14 text

コンテナに関する懸念事項 14 ● さらに詳細に ○ コンテナの脆弱性スキャンとOS依存のセキュリティ ○ イメージの署名と実施 ○ 特権ユーザーを許可しない https://kubernetes.io/ja/docs/concepts/security/overview/ 意図しないコンテナを起動させない

Slide 15

Slide 15 text

ChatworkのKubernetes無法地帯問題（言い過ぎ） 15 ● 悪意のあるコンテナがデプロイされる危険性があった ○ 起動するコンテナイメージを検査できていなかったうわっ...弊社のKubernetes、無法地帯すぎ...？

Slide 16

Slide 16 text

マニフェストレベルでデプロイ可能なイメージの制約をかけたい 16 ● いつどこで？ ○ マニフェストファイルのCI時 ○ Kubernetes内部（kubectl apply時、apply以外のリソース生成時）開発者 Application Manifest (helmﬁle) Charts ECR EKS Push Build Update Push kubectl apply Sync CI Reconciliation Loop

Slide 17

Slide 17 text

Open Policy Agent（OPA）を採用 17 ● 先述の両方のタイミングで対応可能なツール ○ ConftestでCI時の検査 ○ GateKeeperでKubernetes内部から検査

Slide 18

Slide 18 text

OPAとは 18 ● CNCFでホストされるオープンソースで汎用的なポリシーエンジン ○ Regoという言語でポリシーを表現 ○ Input(JSON)をPolicy(Rego)で検査するAPIを提供する

Slide 19

Slide 19 text

Regoとは 19 ● OPAで利用するポリシー記述言語 ● 普段使ってない脳みそが使われる感じがする ○ 独特の書き味があって学習ハードルは高め ○ Masayoshi MIZUTANIさんのZenn記事にお世話になりました ■ https://zenn.dev/mizutani/books/d2f1440cfbba94

Slide 20

Slide 20 text

Conftest、Gatekeeperについて 20 ● いずれもOPA/Regoの仕組みを使ったツール ● Conftest ○ Regoを利用して以下のようなコードを検査できる ■ Kubernetesのマニフェスト ■ TerraformコードなどのHCL ● Gatekeeper ○ Kubernetes内でOPAのポリシーチェックを回す ■ Validating Admission Webhookを利用

Slide 21

Slide 21 text

他社さんの事例 21 ● Conftest + Gatekeeperは結構あるあるな構成 ● LIFULLさんの事例 ○ Pod Security Policyの代替として採用 ■ https://www.lifull.blog/entry/2021/07/07/200000 ● NIKKEIさんの記事 ○ ハンズオンつき！ ■ https://hack.nikkei.com/blog/advent20201224/

Slide 22

Slide 22 text

運用戦略 22 ● ポリシー専用のリポジトリを用意 ○ ポリシーと検査の仕組みを密結合にしたくない ● ポリシーの適用を完全自動化 ○ ポリシーが更新されればCIとGatekeeperそれぞれに反映 ○ Gatekeeper用のCRD生成にはKonstraintを利用

Slide 23

Slide 23 text

実装 23 開発者 Policy(Rego) Gatekeeper Manifests Application Manifests EKS Push Admission Webhook Update CRD (Konstraint) Sync Pull CI

Slide 24

Slide 24 text

Kubernetes内部での検査フロー 24 開発者 Policy(Rego) Gatekeeper Manifests EKS Push Admission Webhook Update CRD (Konstraint) Sync

Slide 25

Slide 25 text

CIでの検査フロー 25 開発者 Application Manifest (helmﬁle) Charts ECR EKS Push Build Update Push kubectl apply Sync CI Reconciliation Loop

Slide 26

Slide 26 text

CIでの検査フロー 26 開発者 Policy(Rego) Application Manifests Push Pull CI

Slide 27

Slide 27 text

検査内容 27 ● 現時点 ○ コンテナイメージ名チェック ■ 特定の命名規則に則っているイメージ名のみ起動を許可 ● これから ○ その他穴埋め ■ （その気になれば）色々できちゃうので仕組みで防ぐ

Slide 28

Slide 28 text

まとめ 28 ● 確実なk8sマニフェスト検査ができるOPAの仕組みを採用 ○ 意図しないコンテナの起動を防ぐ ● 自動かつ柔軟な検査が可能 ○ CIとapply時のWチェック、ポリシーの分離 ● 手をかけれるかどうかがOPA採用の見極めポイントかも ○ 作り込みとRegoの習得が必要な点に要注意 ○ Kyvernoとかが対抗馬か

Slide 29

Slide 29 text

参考文献 29 PairsにおけるEKSセキュリティの取り組み OPAの話も含め広範囲のセキュリティ対策について触れられていてすごく参考になります OPA/Rego入門再掲

Slide 30

Slide 30 text

Terraformの安全な運用について 2

Slide 31

Slide 31 text

Terraform、どうやって運用してますか？

Slide 32

Slide 32 text

Terraform、どうやって運用してますか？ 32

Slide 33

Slide 33 text

Chatworkでは... 33 SQSが欲しいな... 開発チーム

Slide 34

Slide 34 text

Chatworkでは... 34 SQSが欲しいな... SQS 1つお願いします！開発チーム

Slide 35

Slide 35 text

Chatworkでは... 35 SQS 1つ入りまーす SRE部

Slide 36

Slide 36 text

Chatworkでは... 36 SQS 1つ入りまーす SRE部 .tf書いてpush

Slide 37

Slide 37 text

Chatworkでは... 37 SQS 1つ入りまーす SRE部 .tf書いてpush terraform planして

Slide 38

Slide 38 text

Chatworkでは... 38 SQS 1つ入りまーす SRE部 .tf書いてpush terraform planして plan結果をPRに添付

Slide 39

Slide 39 text

Chatworkでは... 39 SQS 1つ入りまーす SRE部 .tf書いてpush terraform planして SRE部でレビューして plan結果をPRに添付

Slide 40

Slide 40 text

Chatworkでは... 40 SQS 1つ入りまーす SRE部 .tf書いてpush terraform planして SRE部でレビューして terraform apply plan結果をPRに添付

Slide 41

Slide 41 text

Chatworkでは... 41 SQS 1つ入りまーす SRE部 .tf書いてpush terraform planして SRE部でレビューして terraform apply apply結果を... plan結果をPRに添付

Slide 42

Slide 42 text

以前のChatwork Terraform事情 42 ● 開発者主体でAWSリソースを作成できなかった ○ AWSリソース作成は権限を持つSRE部が実施する必要あり ● レビューおよび実行記録の保存がしんどい ○ 各個人のmacからterraform apply！→GitHubにぺたぺた ● Terraformのバージョン管理がつらい ○ みんなのバージョン一生揃わない（providerも）

Slide 43

Slide 43 text

新天地を求めて 43 ● 要件 ○ 開発者が実行可能かつPR上で運用できるスタイルにしたい ○ tfstateをリモート管理したい ○ 権限はIAMロール運用としたい

Slide 44

Slide 44 text

紆余曲折 44 ● Terraform Cloud ○ 第一候補だったがIAMキー必須のためNG ● GitHub Actions / Self-Hosted Runner ○ 当時はプランの都合で選択できず...

Slide 45

Slide 45 text

新天地、Atlantis 45 ● GitHub PR上でコメント駆動terraform applyできるOSS ○ PRのコメントでplan、レビュー後apply、みたいな ● Pros ○ 要件はすべて満たす（PR運用、tfstate、IAMロール） ● Cons ○ 運用コスト（インフラ費、人件費）

Slide 46

Slide 46 text

The Atlantis Workﬂow 46 https://www.runatlantis.io/

Slide 47

Slide 47 text

The Atlantis Workﬂow 47 https://www.runatlantis.io/

Slide 48

Slide 48 text

The Atlantis Workﬂow 48 https://www.runatlantis.io/

Slide 49

Slide 49 text

The Atlantis Workﬂow 49 https://www.runatlantis.io/

Slide 50

Slide 50 text

運用 50 EKS terraform apply terraform apply 開発者 Terraform atlantis apply pull

Slide 51

Slide 51 text

導入してみて 51 ● 開発者体験の向上 ○ SRE部に依頼しなくてもAWSリソースが作れる ● セキュリティの向上 ○ 権限はAtlantisさんだけが持てばよい（Atlantisさんつよつよ問題はある） ● ガバナンス（※）の向上 ○ GitHubでplan見て、レビューしてもらって、applyできる ※ここでいうガバナンスが効いている状態とは、みんなが同じやり方・同じルール下でTerraform運用できる状態を指します

Slide 52

Slide 52 text

まとめ 52 ● 新天地、Atlantis ○ Terraform運用のつらみ解消 ● Terraform運用の開発者体験 / セキュリティ / ガバナンス向上に貢献 ○ 誰でもapplyできて、セキュアで、記録が残る ● Atlantisさんのお守りは考える必要アリ ○ 良くも悪くもself-hosted

Slide 53

Slide 53 text

AWSリソース作成のガードレールについて 3

Slide 54

Slide 54 text

こんな経験、ありませんか？

Slide 55

Slide 55 text

異常発生！ 55

Slide 56

Slide 56 text

わんわん！ 56

Slide 57

Slide 57 text

SRE部、出動！ 57 DynamoDBのWCUがサチってるな... 特にサービス影響は出てなさそうだけど... 開発のひとに聞いてみるか...

Slide 58

Slide 58 text

SRE部、出動！ 58 DynamoDBのWCUがサチってるな... 特にサービス影響は出てなさそうだけど... 開発のひとに聞いてみるか...

Slide 59

Slide 59 text

いやちょっとまて... 59 DynamoDBのWCUがサチってるな... 特にサービス影響は出てなさそうだけど... 開発のひとに聞いてみるか...

Slide 60

Slide 60 text

SRE部でワンクッション挟む意味 is ...? 60 SRE部開発チームA 開発チームB

Slide 61

Slide 61 text

あるべき姿 61 SRE部開発チームA 開発チームB （必要なら）

Slide 62

Slide 62 text

課題 62 ● そもそも管理チーム不明なAWSリソースがいっぱいある...

Slide 63

Slide 63 text

お掃除だ！ 63

Slide 64

Slide 64 text

タグ付けだ！ 64 管理: 開発チームA 管理: 開発チームB

Slide 65

Slide 65 text

やらないといけないこと 65 開発メンバ漏れなく周知新しく入った人への啓蒙

Slide 66

Slide 66 text

想定されること 66 人は忘れる生き物口伝の漏れ

Slide 67

Slide 67 text

仕組みで解決したい 67 ● 要件 ○ AWSリソースをどのチームが管理しているのかをタグで明確にしたい ○ タグがない場合はAtlantisでリソース作成をブロックしたい

Slide 68

Slide 68 text

そこでAtlantis + Conftest 68 ● できること ○ Terraformのplan結果をOPAの仕組みで検査 ○ ポリシー違反であればapply不可 https://www.runatlantis.io/docs/policy-checking.html

Slide 69

Slide 69 text

やってみた 69 ● やること ○ Atlantisサーバでpolicy_checkを有効化 ○ Regoを書く（脳みそこねこね） ○ Atlantisにポリシーを入れる

Slide 70

Slide 70 text

できた 70 チーム名を明記するタグがないと怒られる

Slide 71

Slide 71 text

これから 71 ● Gatekeeper側と同じような仕組みにしたい ○ ポリシーの分離と反映の自動化 ● 他のポリシー導入検討 ○ IAMの強い権限がないか、etc...

Slide 72

Slide 72 text

こんな経験、ありませんか？ OPA関係ないけどおまけ

Slide 73

Slide 73 text

なんかAWSの請求めっちゃ増えてる！ 73

Slide 74

Slide 74 text

Atlantisさん、最近なにか作りました？ 74

Slide 75

Slide 75 text

Atlantisさん、最近なにか作りました？ 75 EC2をxx台ほど...

Slide 76

Slide 76 text

Atlantisさん、最近なにか作りました？ 76 EC2をxx台ほど... あー、それかぁ...

Slide 77

Slide 77 text

必要なら仕方ないけど、作る前にある程度料金を見れないかな... 77

Slide 78

Slide 78 text

そこでAtlantis + infracost 78 ● できること ○ Terraformのplan結果からある程度の利用料金の増減を予測 https://www.infracost.io/docs/integrations/atlantis/

Slide 79

Slide 79 text

期待できること 79 あ、これ思ったより料金高いな... 削減できないか考えよう ● Atlantisのplan結果（infracost）を見て...

Slide 80

Slide 80 text

まとめ 80 ● Atlantis + ConftestでTerraformの検査を実施 ○ Regoポリシーでplan結果の自動レビューを行う ● Atlantis + infracostでコストの可視化を実施 ○ 予期せぬコストアラートの抑止 ● 仕組みで守るガードレール ○ チェックリストや口伝に頼らない

Slide 81

Slide 81 text

Kubernetesのセキュリティ向上について Terraformの安全な運用について AWSリソース作成のガードレールについて 1 2 3 AGENDA アジェンダ

Slide 82

Slide 82 text

全体のまとめ 82 ● OPAを使ってセキュリティとガバナンスの向上を実現 ○ Kubernetes: Conftest + Gatekeeper ○ Terraform: Atlantis + Conftest, Atlantis + infracost ● ダイジなのは運用・開発者体験を損なわないこと ○ なるべく自動化 ○ 適切なガードレールを敷く ○ SRE部がボトルネックにならない ● Atlantisはいいぞ ○ 知名度低い...？ ○ Terraform Cloud推しの人の話も聞いてみたい

Slide 83

Slide 83 text

宣伝: 採用募集 83

Slide 84

Slide 84 text

宣伝: Chatwork SRE部のセッション 84 ● ArgoCDとGitHub Actions Self Hosted Runnerを使ってリリース時間を1/4にした話 ○ 11/21 15:20- ○ Track C ○ Ryo Sakamoto ● SLO策定までの道とChaosEngineeringを使った最適解の見つけ方 ○ 11/22 13:20- ○ Track A ○ Shinya Sasaki

Slide 85

Slide 85 text

働くをもっと楽しく、創造的に