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

CNDT 2022の発表資料です。

Transcript

1. © Chatwork KubernetesとTerraformの セキュリティ/ガバナンス向上委員会 with OPA 2022年11月21日 SRE部 古屋 啓介 Chatwork株式会社
2. 自己紹介 2 • 古屋 啓介 ◦ Chatwork株式会社 プロダクト本部 SRE部 ◦ 2022年2月入社 • 普段のおしごと ◦ AWSとイチャイチャ ▪ Aurora ▪ EKS ◦ ※セキュリティの専門家というわけではないです
3. 会社概要 3 会社名 Chatwork株式会社 代表取締役CEO 山本 正喜 従業員数 304名（2022年9月末日時点） 所在地 東京、大阪、ベトナム、台湾 設立 2004年11月11日
4. 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株式会社にて選定。
5. 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株式会社にて選定。
6. Chatworkの構成（ざっくり） 6
7. Kubernetesのセキュリティ向上について Terraformの安全な運用について AWSリソース作成のガードレールについて 1 2 3 AGENDA アジェンダ
8. Kubernetesのセキュリティ向上について 1
9. Kubernetesのセキュリティ 大丈夫ですか？
10. Kubernetesのセキュリティ 大丈夫ですか？
11. クラウドネイティブセキュリティの4C 11 • Kubernetesのドキュメントによると ◦ コード ◦ コンテナ ◦ クラスター ◦ クラウド https://kubernetes.io/ja/docs/concepts/security/overview/
12. コンテナに関する懸念事項 12 • さらに詳細に ◦ コンテナの脆弱性スキャンとOS依存のセキュリティ ◦ イメージの署名と実施 ◦ 特権ユーザーを許可しない https://kubernetes.io/ja/docs/concepts/security/overview/
13. コンテナに関する懸念事項 13 • さらに詳細に ◦ コンテナの脆弱性スキャンとOS依存のセキュリティ ◦ イメージの署名と実施 ◦ 特権ユーザーを許可しない https://kubernetes.io/ja/docs/concepts/security/overview/
14. コンテナに関する懸念事項 14 • さらに詳細に ◦ コンテナの脆弱性スキャンとOS依存のセキュリティ ◦ イメージの署名と実施 ◦ 特権ユーザーを許可しない https://kubernetes.io/ja/docs/concepts/security/overview/ 意図しないコンテナを起動させない
15. ChatworkのKubernetes無法地帯問題（言い過ぎ） 15 • 悪意のあるコンテナがデプロイされる危険性があった ◦ 起動するコンテナイメージを検査できていなかった うわっ...弊社のKubernetes、無法地帯すぎ...？
16. マニフェストレベルでデプロイ可能なイメージの制約をかけたい 16 • いつどこで？ ◦ マニフェストファイルのCI時 ◦ Kubernetes内部（kubectl apply時、apply以外のリソース生成時） 開発者 Application Manifest (helmfile) Charts ECR EKS Push Build Update Push kubectl apply Sync CI Reconciliation Loop
17. Open Policy Agent（OPA）を採用 17 • 先述の両方のタイミングで対応可能なツール ◦ ConftestでCI時の検査 ◦ GateKeeperでKubernetes内部から検査
18. OPAとは 18 • CNCFでホストされるオープンソースで汎用的なポリシーエンジン ◦ Regoという言語でポリシーを表現 ◦ Input(JSON)をPolicy(Rego)で検査するAPIを提供する
19. Regoとは 19 • OPAで利用するポリシー記述言語 • 普段使ってない脳みそが使われる感じがする ◦ 独特の書き味があって学習ハードルは高め ◦ Masayoshi MIZUTANIさんのZenn記事にお世話になりました ▪ https://zenn.dev/mizutani/books/d2f1440cfbba94
20. Conftest、Gatekeeperについて 20 • いずれもOPA/Regoの仕組みを使ったツール • Conftest ◦ Regoを利用して以下のようなコードを検査できる ▪ Kubernetesのマニフェスト ▪ TerraformコードなどのHCL • Gatekeeper ◦ Kubernetes内でOPAのポリシーチェックを回す ▪ Validating Admission Webhookを利用
21. 他社さんの事例 21 • Conftest + Gatekeeperは結構あるあるな構成 • LIFULLさんの事例 ◦ Pod Security Policyの代替として採用 ▪ https://www.lifull.blog/entry/2021/07/07/200000 • NIKKEIさんの記事 ◦ ハンズオンつき！ ▪ https://hack.nikkei.com/blog/advent20201224/
22. 運用戦略 22 • ポリシー専用のリポジトリを用意 ◦ ポリシーと検査の仕組みを密結合にしたくない • ポリシーの適用を完全自動化 ◦ ポリシーが更新されればCIとGatekeeperそれぞれに反映 ◦ Gatekeeper用のCRD生成にはKonstraintを利用
23. 実装 23 開発者 Policy(Rego) Gatekeeper Manifests Application Manifests EKS Push Admission Webhook Update CRD (Konstraint) Sync Pull CI
24. Kubernetes内部での検査フロー 24 開発者 Policy(Rego) Gatekeeper Manifests EKS Push Admission Webhook Update CRD (Konstraint) Sync
25. CIでの検査フロー 25 開発者 Application Manifest (helmfile) Charts ECR EKS Push Build Update Push kubectl apply Sync CI Reconciliation Loop
26. CIでの検査フロー 26 開発者 Policy(Rego) Application Manifests Push Pull CI
27. 検査内容 27 • 現時点 ◦ コンテナイメージ名チェック ▪ 特定の命名規則に則っているイメージ名のみ起動を許可 • これから ◦ その他穴埋め ▪ （その気になれば）色々できちゃうので仕組みで防ぐ
28. まとめ 28 • 確実なk8sマニフェスト検査ができるOPAの仕組みを採用 ◦ 意図しないコンテナの起動を防ぐ • 自動かつ柔軟な検査が可能 ◦ CIとapply時のWチェック、ポリシーの分離 • 手をかけれるかどうかがOPA採用の見極めポイントかも ◦ 作り込みとRegoの習得が必要な点に要注意 ◦ Kyvernoとかが対抗馬か
29. 参考文献 29 PairsにおけるEKSセキュリティの取り組み OPAの話も含め広範囲のセキュリティ対策について触れら れていてすごく参考になります OPA/Rego入門 再掲
30. Terraformの安全な運用について 2
31. Terraform、どうやって 運用してますか？
32. Terraform、どうやって運用してますか？ 32
33. Chatworkでは... 33 SQSが欲しいな... 開発チーム
34. Chatworkでは... 34 SQSが欲しいな... SQS 1つお願いします！ 開発チーム
35. Chatworkでは... 35 SQS 1つ入りまーす SRE部
36. Chatworkでは... 36 SQS 1つ入りまーす SRE部 .tf書いてpush
37. Chatworkでは... 37 SQS 1つ入りまーす SRE部 .tf書いてpush terraform planして
38. Chatworkでは... 38 SQS 1つ入りまーす SRE部 .tf書いてpush terraform planして plan結果をPRに添付
39. Chatworkでは... 39 SQS 1つ入りまーす SRE部 .tf書いてpush terraform planして SRE部でレビューして plan結果をPRに添付
40. Chatworkでは... 40 SQS 1つ入りまーす SRE部 .tf書いてpush terraform planして SRE部でレビューして terraform apply plan結果をPRに添付
41. Chatworkでは... 41 SQS 1つ入りまーす SRE部 .tf書いてpush terraform planして SRE部でレビューして terraform apply apply結果を... plan結果をPRに添付
42. 以前のChatwork Terraform事情 42 • 開発者主体でAWSリソースを作成できなかった ◦ AWSリソース作成は権限を持つSRE部が実施する必要あり • レビューおよび実行記録の保存がしんどい ◦ 各個人のmacからterraform apply！→GitHubにぺたぺた • Terraformのバージョン管理がつらい ◦ みんなのバージョン一生揃わない（providerも）
43. 新天地を求めて 43 • 要件 ◦ 開発者が実行可能かつPR上で運用できるスタイルにしたい ◦ tfstateをリモート管理したい ◦ 権限はIAMロール運用としたい
44. 紆余曲折 44 • Terraform Cloud ◦ 第一候補だったがIAMキー必須のためNG • GitHub Actions / Self-Hosted Runner ◦ 当時はプランの都合で選択できず...
45. 新天地、Atlantis 45 • GitHub PR上でコメント駆動terraform applyできるOSS ◦ PRのコメントでplan、レビュー後apply、みたいな • Pros ◦ 要件はすべて満たす（PR運用、tfstate、IAMロール） • Cons ◦ 運用コスト（インフラ費、人件費）
46. The Atlantis Workflow 46 https://www.runatlantis.io/
47. The Atlantis Workflow 47 https://www.runatlantis.io/
48. The Atlantis Workflow 48 https://www.runatlantis.io/
49. The Atlantis Workflow 49 https://www.runatlantis.io/
50. 運用 50 EKS terraform apply terraform apply 開発者 Terraform atlantis apply pull
51. 導入してみて 51 • 開発者体験の向上 ◦ SRE部に依頼しなくてもAWSリソースが作れる • セキュリティの向上 ◦ 権限はAtlantisさんだけが持てばよい（Atlantisさんつよつよ問題はある） • ガバナンス（※） の向上 ◦ GitHubでplan見て、レビューしてもらって、applyできる ※ここでいうガバナンスが効いている状態とは、みんなが同じやり方・同じルール下でTerraform運用できる状態を指します
52. まとめ 52 • 新天地、Atlantis ◦ Terraform運用のつらみ解消 • Terraform運用の開発者体験 / セキュリティ / ガバナンス向上に貢献 ◦ 誰でもapplyできて、セキュアで、記録が残る • Atlantisさんのお守りは考える必要アリ ◦ 良くも悪くもself-hosted
53. AWSリソース作成のガードレールについて 3
54. こんな経験、ありませんか？
55. 異常発生！ 55
56. わんわん！ 56
57. SRE部、出動！ 57 DynamoDBのWCUがサチってるな... 特にサービス影響は出てなさそうだけど... 開発のひとに聞いてみるか...
58. SRE部、出動！ 58 DynamoDBのWCUがサチってるな... 特にサービス影響は出てなさそうだけど... 開発のひとに聞いてみるか...
59. いやちょっとまて... 59 DynamoDBのWCUがサチってるな... 特にサービス影響は出てなさそうだけど... 開発のひとに聞いてみるか...
60. SRE部でワンクッション挟む意味 is ...? 60 SRE部 開発チームA 開発チームB
61. あるべき姿 61 SRE部 開発チームA 開発チームB （必要なら）
62. 課題 62 • そもそも管理チーム不明なAWSリソースがいっぱいある...
63. お掃除だ！ 63
64. タグ付けだ！ 64 管理: 開発チームA 管理: 開発チームB
65. やらないといけないこと 65 開発メンバ漏れなく周知 新しく入った人への啓蒙
66. 想定されること 66 人は忘れる生き物 口伝の漏れ
67. 仕組みで解決したい 67 • 要件 ◦ AWSリソースをどのチームが管理しているのかをタグで明確にしたい ◦ タグがない場合はAtlantisでリソース作成をブロックしたい
68. そこでAtlantis + Conftest 68 • できること ◦ Terraformのplan結果をOPAの仕組みで検査 ◦ ポリシー違反であればapply不可 https://www.runatlantis.io/docs/policy-checking.html
69. やってみた 69 • やること ◦ Atlantisサーバでpolicy_checkを有効化 ◦ Regoを書く（脳みそこねこね） ◦ Atlantisにポリシーを入れる
70. できた 70 チーム名を明記するタグがないと怒られる
71. これから 71 • Gatekeeper側と同じような仕組みにしたい ◦ ポリシーの分離と反映の自動化 • 他のポリシー導入検討 ◦ IAMの強い権限がないか、etc...
72. こんな経験、ありませんか？ OPA関係ないけどおまけ
73. なんかAWSの請求めっちゃ増えてる！ 73
74. Atlantisさん、最近なにか作りました？ 74
75. Atlantisさん、最近なにか作りました？ 75 EC2をxx台ほど...
76. Atlantisさん、最近なにか作りました？ 76 EC2をxx台ほど... あー、それかぁ...
77. 必要なら仕方ないけど、作る前にある程度料金を見れないかな... 77
78. そこでAtlantis + infracost 78 • できること ◦ Terraformのplan結果からある程度の利用料金の増減を予測 https://www.infracost.io/docs/integrations/atlantis/
79. 期待できること 79 あ、これ思ったより料金高いな... 削減できないか考えよう • Atlantisのplan結果（infracost）を見て...
80. まとめ 80 • Atlantis + ConftestでTerraformの検査を実施 ◦ Regoポリシーでplan結果の自動レビューを行う • Atlantis + infracostでコストの可視化を実施 ◦ 予期せぬコストアラートの抑止 • 仕組みで守るガードレール ◦ チェックリストや口伝に頼らない
81. Kubernetesのセキュリティ向上について Terraformの安全な運用について AWSリソース作成のガードレールについて 1 2 3 AGENDA アジェンダ
82. 全体のまとめ 82 • OPAを使ってセキュリティとガバナンスの向上を実現 ◦ Kubernetes: Conftest + Gatekeeper ◦ Terraform: Atlantis + Conftest, Atlantis + infracost • ダイジなのは運用・開発者体験を損なわないこと ◦ なるべく自動化 ◦ 適切なガードレールを敷く ◦ SRE部がボトルネックにならない • Atlantisはいいぞ ◦ 知名度低い...？ ◦ Terraform Cloud推しの人の話も聞いてみたい
83. 宣伝: 採用募集 83
84. 宣伝: 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
85. 働くをもっと楽しく、創造的に