CNDT 2022、ChatworkのSREがコンテナセキュリティのための新しいツールを紹介

CNDT 2022から、Chatwork株式会社のSREによるKubernetesのセキュリティ導入事例を解説するセッションを紹介する。セッションのタイトルは「KubernetesとTerraformのセキュリティ／ガバナンス向上委員会 with OPA」、若干ジョークじみた名称だが、内容としてはAWS上に構築されているChatworkのインフラストラクチャーで実行されるコンテナにポリシーを適用してセキュリティを強化したというのが前半で、後半はTerraformを使ってインフラストラクチャーをデプロイする際に開発者がセルフサービスで行えるようにした事例を利用したツール、Atlantis、Conftest、infraTestなどの紹介も含めて解説するものだ。

●動画：KubernetesとTerraformのセキュリティ／ガバナンス向上委員会 with OPA

セッションを担当したのはChatworkのSRE部所属のエンジニアである古屋啓介氏だ。

セッションを行う古屋氏。OPAのユースケースがメインだがAtlantisの解説も

セッションは3つのトピックが扱われていた。前半がコンテナ実行にポリシーを適用するためにOPA（Open Policy Agent）を使って悪意のあるコンテナが実行されないようにしたという話で、Kubernetesのドキュメントに沿ってセキュリティを強化するためのポイントを解説。ここではコンテナに含まれるコード及び依存するライブラリーの脆弱性スキャンが必要であること、イメージに対する署名を実施すること、特権ユーザーを許可しないことなどを挙げた。

コンテナにおけるセキュリティ強化ポイントを解説

ただしここからは2番目のポイント、実行されるコンテナイメージに対する署名を、意図しないコンテナを実行しないことと同じ意味であると解釈して実施した強化のための施策がイメージの命名規則を作り、それを守らないイメージは実行しないことであるというのがこのトピックの要点である。

Kubernetes無法地帯問題

そのためにコードが修正されイメージがビルドされて更新されるCIが実行され、Kubernetesのマニフェストが更新されるタイミングとKubernetesのクラスターリソースが生成、変更されるタイミングでチェックを行うことように変更したことを解説した。

2つのタイミングでイメージの命名をチェックする

このポリシーチェックに使われているのが、OPAだ。古屋氏はOPAの説明を行い、ポリシーの記述に使われているRegoという言語についても簡単に説明を行った。OPAはKubernetes以外のインフラストラクチャーでも使われるツールだが、Regoという言語を使うことについてPythonなどに比べて新しい体験であり、学習のハードルが高いこともコメントしている。そして関連するツールとしてConftestとGatekeeperを併せて使っているとして簡単にツールの説明を行った。

OPAと一緒に使われているConftestとGatekeeperを紹介

またポリシー専用のGitHubリポジトリを作成し、ポリシーとその検査を分離したかったと説明。またポリシーの適用は自動化されていると説明した。

ポリシーの検査はイメージの命名規則だけ。他のポリシーも検討中だという

コンテナイメージの命名規則を定めて、それに従ったイメージ名が付与されているのかをチェックするのが「意図しないコンテナの実行」ということだが、最近、多くのカンファレンスで取り上げられることが多くなったSigstoreが実行するイメージへの署名と署名のログを取るというものとは異なり、脆弱性のチェックという部分もここでは特に説明されていないのが残念だ。今回のスコープには入っていなかったということだろうが、別の機会にぜひ、解説を聞いてみたいところだ。

イメージに対するポリシーチェックにOPAを使った部分のまとめ

このパートのまとめとしてOPAの採用とポリシーと検査の分離などについて説明したが、ポイントはOPAのRegoの習得コストと自社のニーズにあった作り込みのコストを負担できるか？ であると説明した。

次のパートはTerraformがSREの業務分担となっており、新しいAWSのリソースを使いたいと開発者が考えた時に必ずSREが間に入らないといけないという業務フローを改善したという内容だ。

新しいAWSのリソースを追加する際にSREが関与しなければいけない問題を解決

リソース作成のフローに必ずSREが関わる必要があり、各自がGitHubにそのログを残すというのも面倒だったとして、新しいソリューションを探していたという。候補としてはHashiCorpが提供するTerraform CloudやGitHub Actionsなどが挙げられていたが、当時の状況では最適ではなかったとして選択されたのが、Atlantisというオープンソースソフトウェアだったと説明。

Terraformのセルフサービスを実現するAtlantis

●参考：Atlantis公式ページ

Atlantisを使うことによって、GitHubにプルリクエストを送るだけでリソースに対する変更が記録され、Terraformが起動され実行されるとしてSREが間に入らないセルフサービスが実現できたと説明した。

GitHubにプルリクエストを送ることでAWSリソースの変更が可能

このパートのまとめとしては、AtlantisによってTerraformを運用する課題が解決されたと説明。ただしAtlantis自体はマネージドサービスではなく個別にSRE側で運用する必要があるとコメントして、便利なツールではあるもののあくまでもアップデートなどの対応は必要であることを強調した。

Atlantisの利点、欠点をまとめ

最後のパートではトラブル発生時にこれまではSREがログの確認から対応するべき開発チームに連絡していたというフローの改善に関連する内容だ。トラブル発生の対策は開発チームが直接行うことがベストだとして、そのためにはAWSに存在するさまざまなリソースに対して「誰がオーナーなのか？」を整理する必要がでてきたことがこの部分の背景になる。

トラブル時はそれに関連する開発チームが直接対応するべき

そこでTerraformを使ってAWSのリソースを操作する際に必ずオーナーとなる開発チームのタグが付与されるようにポリシーを作成し、その検査のためにAtlantisとConftestを使ったというのがこのパートの要点だ。

AtlantisとConftestでTerraformのポリシーチェックを実行

このスライドでは実際にチーム名が書かれていないリクエストが失敗する実例を使って説明している。

チーム名が書かれていないTerraformの実行がエラーになっている例

また追加としてAWSのリソースを無制限に使ってしまうことでコストが跳ね上がる例から、Terraformが実行されてコストが発生する前にその概算を計算することができないだろうか？ という課題に対して、AtlantisとInfracostの組み合わせで解決したことを説明した。

AtlantisとInfracostでAWSのコスト変動を事前に計算

Infracostの概要は以下の公式サイトを参照されたい。Terraform以外にもGitHub ActionsやGitLab、Azure Pipelines、Jenkins等にも対応しているという。

●参考：Infracostの公式ページ

Infracostを使ってコストの変動を事前に知ることができる

このパートのまとめとしてはAtlantisとConftestでインフラに対するリクエストのポリシーチェックを実施し、Infracostによるコストの可視化、仕組みをフローに組み込んでチェックリストに頼らないシステムとなったことなどを紹介した。

終わりに全体のまとめとしてOPAを使ってセキュリティとガバナンスを向上させたこと、自動化することの利点などを紹介。最後のAtlantisについてはまだ日本でのユースケースが少ないということから、Terraform Cloudとの比較を知りたいなどを説明しセッションを終えた。

OPAによるポリシーチェックがイメージの命名規則だけというのは、あくまでも最初のステップということだろう。これからどこまでコンテナセキュリティが強化されるのか、注目していきたい。