本文の内容は、2021年12月30日にSysdig CTO Loris Degioanniが投稿したブログ(https://sysdig.com/blog/how-to-secure-kubernetes-os-cloud/）を元に日本語に翻訳・再構成した内容となっております。
インフラストラクチャーやワークロードがクラウドに移行し、チームがCI/CD開発プロセスを採用するにつれ、インフラストラクチャーがコードになるという新しいパラダイムシフトが起きています。インフラストラクチャーをコードとして扱うこのアプローチは非常に強力で、多くの利点をもたらし、不変性のような変革をもたらすコンセプトを可能にします。インフラストラクチャーを宣言的に定義し、アプリケーションコードと同じソースコード管理ツール（特にgit）を使ってバージョン管理を行います。新しいインスタンスの起動やOSのデプロイ（新しいコンテナのスピンアップなど）はすべてgitで宣言的に行われ、Kubernetesクラスターの境界にデプロイされます。
このトレンドの変化は、Kubernetesとgitをコントロールする人が、インフラストラクチャー、アプリケーション、ポリシーをコントロールするというように、開発者の手に多くの責任を負わせることにもなります。そして、開発者は通常、gitを所有し、サービスをYamlとして定義しているので、実際には、彼らの責任となっています。必要なのは、GitOpsのレポでYamlを変更することだけで、そこから先はパイプラインが担ってくれます。
しかし、それはまた新しいカテゴリーのリスクをもたらします。インフラストラクチャーがコードである場合、脆弱性となるバグや見落としが含まれる可能性があり、また、悪意のあるアクターが危険な行為を行うこともあります。IaCを採用したからといって、自動的にセキュリティが向上するわけではなく、逆に攻撃対象が拡大する可能性もあります。そのため、セキュリティはこの新しいパラダイムを考慮に入れて進化させる必要があります。
まず、コードを保護するのと同様に、インフラストラクチャーの定義を保護することが必須であることを認識する必要があります。そしてこのためには、インフラストラクチャーを保護する方法を「シフトレフト」する必要があります。つまり、gitに入ってくる時点でリスクを特定し、理想的にはマージする前にプルリクエストのチェックをエンフォースするのです。
KubernetesはクラウドのOSです；セキュリティはさらに右へシフトする必要がある
もう1つの紛れもない業界トレンドは、コンテナとKubernetesの使用です。大小さまざまな企業が、アプリケーションを実行するプラットフォームとしてKubernetesを採用しています。Linux OSが物理的または仮想的なハードウェア上でプロセスをオーケストレーションするのに対し、Kubernetesは分散コンピューティングプール上でサービスをオーケストレーションします。Linuxが小さなIoTデバイスからスーパーコンピューターまで、ほとんどすべてのものを動かすようになったように、Kubernetesも次第に世界中の分散型ソフトウェアアプリケーションを動かすようになると予想されます。そして、世界がクラウド化していく中で、KubernetesをクラウドのOSと定義したいと考えています。
Kubernetesはリッチで洗練された環境を提供し、アプリケーションのスケールアップを容易にします。一方で、Kubernetes上で動作するアプリケーションは、数十、数百、時には数千のサービスで構成される傾向があり、それらは互いに依存するだけでなく、多くの異なるクラウドリソースにも依存します。
これにより、複雑さが増し、それに伴いリスクも高まります。このようなリスクは、コードスキャンやイメージスキャンを中心とした「シフトレフト」型のセキュリティツールでは容易に抑えることができません。これらの静的な手法では、マイクロサービスベースのアプリケーションの爆発的な組み合わせや相互依存性を完全に把握することができないからです。Kubernetesのセキュリティを確保するには、深いランタイムセキュリティと強力なランタイムサービスコンテキストが必要です。そのためには、セキュリティを右へシフトする必要があります。
シフトレフト？シフトライト？
では、どうすればいいのでしょうか。IaCのようなトレンドは、インフラストラクチャーの定義がgitリポジトリにコミットされると同時に、シフトレフトして検証する必要があることを示しています。Kubernetesの複雑さは、実行時に深い可視性とコンテキストを必要とします。正しいアプローチとは？正解はもちろん、「シフトレフト」と「シフトライト」です。
このアプローチでは、IaCとランタイムの間で単一の真実のソースを持つことができます。ここでいう「ソース」とは、git repoに格納された物理的なソースファイル（Yamls、Terraforms、Helm chart、および/またはKustomizations）と、最終的にKubernetesクラスターにデプロイされるランタイム構成のソースの両方を指しています。前者のセキュリティを確保することは、後者に望ましい直接的な影響を与え、結果としてより安全なランタイム環境を実現します。しかし、IaCソース構成ファイルからのドリフトを見抜き、異常な活動を検出するためには、ランタイムセキュリティを導入する必要があります。
IaCとランタイム・セキュリティを組み合わせることで、セキュリティをさらに強化する機会が生まれます。アプリケーションの実行中に収集されたコンテキスト（例：どのサービスが相互に通信しているか？どのユーザーが本番環境にアクセスしているかなど）は、ポリシーの作成に利用できます。ポリシーは、gitopsを活用することで、インフラストラクチャー全体に自動的に適用され、ランタイムの安全性を高めることができます。手動での作業や人為的なミスがなくなり、同時に攻撃対象も減少します。
ソースからプロダクションまでのセキュリティ
現代のセキュアなDevOpsのための真に完全なプラットフォームは、これらの次元を包括的かつバランスよく組み合わせたものでなければなりません。開発パイプラインの初期段階にセキュリティを移行することは、今日では必須であり、広く受け入れられている方法ですが、これをIaCにも積極的に拡大する必要があります。しかし、これはランタイムにおける強力で正確な保護によって支えられなければなりません。このような好循環は、シフトレフトとシフトライトがお互いに支えあって初めて実現するものであり、これこそがセキュリティの未来だと確信しています。