本文の内容は、2021年2月18日にVíctor Jiménez Cerradaが投稿したブログ(https://sysdig.com/blog/image-scanning-admission-controller/)を元に日本語に翻訳・再構成した内容となっております。
Kubernetesのアドミッションコントローラにイメージスキャンを実装することは、Kubernetesのコンテキストを必要とするポリシーを適用し、クラスターの最後の防御ラインを作成するための興味深い戦略です。
おそらく、あなたはすでにイメージスキャンのベストプラクティスに従っており、悪用される前に脆弱性や誤った設定を検出しています。
しかし、デプロイしたすべてのものがCI/CDパイプラインや既知のレジストリを通過するわけではありません。サードパーティのイメージや、時には手動でのデプロイもあります。
アドミッションコントローラにイメージスキャンを実装することで、デプロイされたものがすべてセキュリティポリシーに適合していることを安心して確認することができます。
この記事では、Kubernetes のアドミッションコントローラとは何かを学び、アドミッションコントローラにイメージスキャンを実装する理由をレビューします。また、AnchoreをFalcoやOPAと統合する完全なDIYアプローチや、Sysdigアドミッションコントローラのようなすぐに使える商用版のアプローチを使用するなど、いくつかの戦略を評価します。
1分でKubernetesアドミッションコントローラを解説
アドミッションコントローラは、クラスター上で実行を許可するものを定義してカスタマイズするのに役立つ、強力なKubernetesネイティブ機能です。
ウォッチドッグのように、オブジェクトの永続化に先立って、Kubernetes APIへのすべてのリクエストを傍受して処理しますが、リクエストが認証されて認可された後に処理します。
Webhooksというかなり標準的なインターフェースを使って、Kubernetes APIの機能を拡張したり、カスタマイズしたりすることができます。これにより、アドミッションコントローラは任意のサードパーティのコードと簡単に統合することができます。
例えば、クラスターにデプロイされる前にイメージをスキャンする ImagePolicyWebhook を実装することができます。これにより、イメージがセキュリティポリシーに適合していない場合には、デプロイがブロックされます。
アドミッションコントローラの設定方法や webhooks のペイロードがどのようなものかについては、「5分でKubernetesのアドミッションコントローラを学ぶ」の記事で詳しく説明しています。
アドミッションコントローラにイメージスキャンを実装することは、#Kubernetes クラスタの最後の防衛線です。実装方法をご覧ください!
Tweet This Click to tweet
アドミッションコントローラにイメージスキャンを しかし、なぜでしょうか？
イメージスキャンの実装は、Kubernetesセキュリティを実装するための最初のステップの1つであるべきです。それは、脆弱性や設定ミスを検出するためのコンフィデンシャルなメカニズムです。
しかし、イメージスキャンはどこに実装すべきでしょうか？
CI/CDパイプラインの上でしょうか? レジストリの上ですか? アドミッションコントローラで? ランタイムで?
なぜどこでもないのでしょうか？
広告の女の子は、なぜ両方を持っていないのかと尋ねています。
イメージスキャンは様々な方法であなたを保護します
CI/CD パイプラインにイメージスキャンを実装することで、構築したイメージを保護することができます。これにより、シフトレフトで脆弱性や設定ミスを早期に発見し、問題になる前に対処することができます。
しかし、ビルドしなかったイメージはどうなるのでしょうか？使用しているレジストリに対してイメージスキャンを実装することで、イメージが脆弱であることを警告し、そのイメージのデプロイを避けるための措置を取ることができます。もしHarborを使って自身のレジストリをホストしている場合は、実際のレジストリにスキャンを組み込むこともできます。
そうすれば、イメージをデプロイした後もスキャンを続けることができます。脆弱性の発見には何年もかかるものもあります。イメージをデプロイした場合、そのイメージには未知の脆弱性が含まれている可能性があります。脆弱性が発見されたらすぐに対応できるように、ランタイムにイメージを継続的に再スキャンする必要があります。
イメージがスキャンされてデプロイされてから、そのイメージの脆弱性が発見されるまでの間には、ある程度の時間がかかるかもしれません。
これらすべてを行った場合、完全に安全であると言えるでしょうか？
さて、画像には、関連する多くのセキュリティ問題が列挙されていますが、これらがすべてではありません。
アドミッションコントローラでのイメージスキャンが最後の防衛線
マニュアルのデプロイが発生する可能性があります。例えば、急いでマニュアルでデプロイを実行するためにプロトコルをスキップしたり、クラスターにアクセスできる攻撃者がイメージスキャナをスキップしてイメージをデプロイしたりする可能性があります。
また、Kubernetes固有のコンテキストに依存するルールもあります。例えば、あるイメージを特定のネームスペースに制限したい場合などです。
そこで、アドミッションコントローラにイメージスキャンを実装すると便利になります。
これは、固有のコンテキストを持つ最後の防衛線です。アドミッションコントローラは、何かが永続化される前に実行されることを忘れないでください。
この戦略を実装するにはいくつかのアプローチがあります。一般的な考え方は：
イメージ検証のwebhookの流れです。デプロイメントリクエストの後、kubernetes APIはイメージ検証のwebhookを呼び出します。このwebhookはイメージスキャンをトリガーして、セキュリティポリシーを適用することができます。イメージがスキャンに合格しない場合、webhook はデプロイを中止することができます。
- Kubernetes API はイメージをデプロイする前に webhook を呼び出します。
- この webhook は、イメージがセキュリティポリシーに従っているかどうかを確認するために、セキュリティツールをチェックします。
- イメージが有効であればデプロイされます。そうでない場合はブロックされます。
方法によって異なるのは、セキュリティツールがどのように検証を処理するかということです。
セキュリティツールがオフラインになるとどうなるか？再起動するまですべての デプロイをブロックしますか? すべてのデプロイを許可しますか？理想的には、すべてのポリシーがウェブフックにキャッシュされていて、常に保護されていることが望ましいです。
イメージスキャナ間でポリシーは共有されていますか？2つの時計を持っている人は時間が分からないという言葉があるように、2つの時計を持っている人は時間が分からないことがあります。CI/CDに1つのスキャナを使用し、アドミッション・コントローラーに別のスキャナを使用している場合、両者が同じセキュリティ・ポリシーを適用していることを確認するために、特別な措置を取る必要があります。どこでも同じイメージスキャナーを使用することで、物事を簡素化します。
スキャンはいつ行われますか？デプロイ時にすべてのイメージをスキャンすると、時間がかかりすぎることがあります。最近すでにイメージをスキャンした場合、再度スキャンする必要はありませんよね？しかし、すべてのセキュリティツールがこのユースケースをサポートしているわけではありません。
スキャン結果はどのように報告されますか？スキャン結果は貴重な情報です。スキャン結果をレポートすることで、コンプライアンス態勢を監視することができます。また、チームが実行中のコンテナの脆弱性を特定して、その修正策があるかどうかを確認するのにも役立ちます。付加価値を提供するツールを探してください。
オープンソースでアドミッションコントローラにイメージスキャンを実装する
イメージスキャンをDIYで行いたい場合は、オープンソースの代替品がたくさんあります。
例えば、Anchoreイメージスキャナーは、独自のアドミッションコントローラのWebhookを提供しています。
他のオープンソースのソリューションと同様に、このアプローチでは、完全なカスタマイズ機能と、多種多様なセキュリティツールと統合する能力が得られます。
誰かが脆弱なイメージをデプロイしようとした場合にアラートを生成するために、AnchoreとFalcoを統合することができます。
また、OPA Gatekeeperを使って検証を行うこともできます。結局のところ、あなたはすでにOPAを使ってregoルールでクラスターのポリシーを定義しているかもしれません。OPA はイメージのメタデータにアクセスし、特定のレジストリから特定のネームスペースへのイメージのデプロイをブロックすることができます。この記事で紹介するすべてのユースケースをカバーするためには、OPA をイメージスキャナと手動で統合する必要があります。
他の選択肢については、このredditの会話を見てください。
DIYアプローチのいくつかの欠点：
- カスタマイズには、自分でソリューションを統合して維持するためのコストがかかります。
- デフォルトでは、Anchoreオープンソースのイメージスキャナーは、どのイメージがすでにスキャンされたかを追跡しないため、スキャンはすべてのデプロイメントで実行されます。
- また、アドミッションポリシーの管理、コンプライアンスポジションの監視、レポートの作成などの余分な機能をDIYする必要があります。
Sysdig Admission Controllerを使用したイメージスキャンの実装
Sysdigでは、セキュリティ機能を主流にするにはシンプルであることが最良の方法であると考えています。
Sysdig Admission Controller はその原則に沿ったもので、あなたの DIY 実装に何らかのインスピレーションをもたらしたり、Sysdig Secure を試してみるのに十分な面白さを感じていただけることを願っています。
このアドミッションコントローラーの新バージョンでは、検出とレポートにエンフォーシング機能が追加されています。簡単なインストールとUI上での簡単な設定の後、クラスター内のイメージはデフォルトでセキュアになります。
このアドミッションコントローラーの特徴は、以下のような重要な詳細です：
イメージを再スキャンする必要はありません。Sysdigバックエンドは、スキャン結果を一元管理するため、アドミッションコントローラーを高速化し、より迅速な導入を可能にします。イメージが最近スキャンされた場合、アドミッションコントローラーでのスキャンをスキップすることができます。
既存のスキャンポリシーを再利用できます。これにより、イメージのライフサイクルの異なるステップで行われるスキャン間の一貫性が保証されます。また、フレンドリーなUIでアドミッションポリシーを構築することができます。
フェイルプルーフです。webhookがSysdigバックエンドとの接続を失っても、スキャンポリシーを適用することができます。
また、Sysdigのトレードマークである特典をすべて搭載しています。インストールが簡単で、コンプライアンスコントロールをスキャンポリシーにマッピングし、脆弱性レポートを作成することができます。
まとめ
Kubernetes クラスターのセキュリティを確保するためには、イメージのライフサイクルのすべてのステップでイメージスキャンを実装する必要があります。
アドミッションコントローラ上のイメージスキャンは、パズルのもう一つのピースに過ぎません。これにより、Kubernetesのコンテキストに依存するポリシーを実装することができ、コントロールを迂回するマニュアルのデプロイから保護することができます。
このソリューションを実装するために使用できるオープンソースのツールがいくつかありますが、いくつかの機能を自分で構築する必要がありますので、あなたのクラスターのためにアドミッションコントローラーにイメージスキャンを実装しない言い訳はありません。
Sysdig Admission Controllerは、この問題に対するシンプルで完全なソリューションです。KubernetesネイティブコントロールとSysdigプラットフォームのパワーを活用し、Kubernetesクラスターのセキュリティを確保するために必要な可視性を提供します。数分で始めることができます。今すぐお試しください！