Kubernetes ネイティブセキュリティのメリット

コンテナセキュリティには、コンテナを中心とするアプローチと Kubernetes ネイティブのアプローチの 2 つの主要なアプローチがあります。 

コンテナを中心とするプラットフォームはコンテナレベルで動作し、コンテナイメージとコンテナランタイムの保護に重点を置いています。これらのツールは、インラインプロキシやシムなどの手法を使用してコンテナ間の通信を制御するなど、コンテナレベルで制御を提供します。

Kubernetes ネイティブセキュリティは、Kubernetes レイヤーで動作します。Kubernetes からコンテキストを取得し、Kubernetes が強制できるようにポリシーを Kubernetes にプッシュします。

Kubernetes ネイティブセキュリティは、Kubernetes との緊密な統合を利用して、コンテキストを取得し、Kubernetes のネイティブコントロールを活用します。このアーキテクチャは、豊富なコンテキストと知見を提供し、Kubernetes 固有の脅威を検出することにより、2 つの主要な方法でセキュリティを向上させます。

Kubernetes ネイティブセキュリティは、セキュリティはコンテナ化されたアプリケーションを管理するシステムと連携した場合に最も効果的に実装されるという原則に基づいています。 

セキュリティ・プラットフォームが Kubernetes ネイティブと見なされるには、次の特性を備えている必要があります。

• Kubernetes API サーバーと直接統合して、Kubernetes のワークロードとインフラストラクチャをじかに可視化する
• Kubernetes ソフトウェア自体の脆弱性を評価する
• デプロイメント、名前空間、サービス、Pod など、Kubernetes オブジェクトモデル内のリソースに基づいて、ポリシー管理を含むセキュリティ機能を構築する
• Kubernetes 固有のアーティファクト (ワークロードマニフェストなど) と構成からの宣言型データを分析する
• 組み込みの Kubernetes セキュリティ機能を使用して、可能な限り強制を処理し、自動化、スケーラビリティ、信頼性を向上させる
• クラウドネイティブ・ツールチェーンの一般的なツールの統合とサポートを含む、Kubernetes アプリケーションとしてデプロイし、実行する

Kubernetes ネイティブセキュリティは、コンテナだけでなく Kubernetes デプロイメントの構成も可視化します。 

また、ワークロードがどのように分離されているか、または分離されているかどうかを理解することも重要です。Kubernetes では、デフォルトで、すべてのデプロイメントが名前空間の内外で他のすべてのデプロイメントと通信できるようになっています。ネットワークポリシー設定を詳細に可視化することで (できれば YAML ファイルのテキストを読み取るのではなく視覚的な形式で)、どのワークロードが分離されていないのかがわかります。

総合的なセキュリティ体制を理解するには、Kubernetes の構成 (ロールの権限、シークレットへのアクセス、ネットワークトラフィックの許可、コントロールプレーンのコンポーネントの設定など) がロックダウンされ、ベストプラクティスに従い、アプリケーションの実行に必要な特権の範囲が可能な限り最小限であるようにしなければなりません。

他のコンピューティングリソースと同様に、多くの組織はクラウドで Kubernetes を実行することを選択します。クラウドで Kubernetes を実行するには複数の方法があります。

• セルフマネージド Kubernetes
• Kubernetes の商用ディストリビューション
• マネージド Kubernetes サービス

どのモデルを選択した場合でも、デプロイメントのセキュリティを保護する責任はユーザーとクラウドプロバイダーが「共有」します。典型的な共有責任モデルは Kubernetes、特にマネージド Kubernetes サービスに適用されますが、セキュリティの責任という点でどこに境界線があるのかがわかりにくいことがあります。

マネージド Kubernetes サービスを使用すると、クラウドプロバイダーは Kubernetes コントロールプレーンを管理します。ここには、クラスタを制御する Kubernetes コンポーネントと、クラスタの状態と構成に関するデータが含まれます。

サービスには通常、コントロールプレーンの設定、ノードの冗長性の有効化が含まれます。また、多くの場合、クラウドプロバイダーのインフラストラクチャの一部がダウンした際の停止を防ぐために、ノードをさまざまなリージョンで実行することも含まれます。

通常、クラウドプロバイダーは次のことを行います。

• Kubernetes を最新の状態に保つ
• コントロールプレーンに継続的にパッチを適用する
• ノード OS のパッチを提供する場合がある (多くの場合、選択した OS によって異なる)
• コンテナ向けに最適化された OS イメージをノードに提供する
• 脆弱性スキャナーを提供する場合がある (ただし、ユーザーはスキャン結果に基づいて許可あるいは拒否するアドミッション・コントローラーを使用するなどのポリシーを作成する必要がある)

ユーザーには、常に Kubernetes ワークロードを保護する責任があります。それには次のようなセキュリティの側面が含まれます。

• コンテナイメージ：そのソース、コンテンツ、および脆弱性
• デプロイメント：ネットワークサービス、ストレージ、特権
• 構成管理：ロール、グループ、ロールバインディング、サービスアカウント
• アプリケーション：シークレット管理、ラベル、アノテーション
• ネットワーク・セグメンテーション：クラスタ内のネットワークポリシー
• ランタイム：脅威の検出とインシデント対応

Kubernetes ネイティブセキュリティのプラットフォームには、いくつかの重要な利点があります。 

保護の強化 

Kubernetes ネイティブセキュリティは、Kubernetes だけでなくコンテナの脆弱性の発見にもつながる Kubernetes の宣言型データに関連付けることによって、より豊富な知見を提供します。 

運用効率の向上 

インフラストラクチャの管理とセキュリティに同じフレームワークを使用すると、Kubernetes の習得が加速されるのに加え、Kubernetes コンテキストによって脅威の検出とリスク評価の優先順位付けが迅速化されます。

運用リスクの軽減 

Kubernetes のネイティブコントロールを利用することで、セキュリティが Kubernetes のペースとスケーラビリティを備えるようになります。ポリシーが Kubernetes に組み込まれていれば、外部コントロールとオーケストレーターの間に競合は生じません。

Kubernetes ネイティブセキュリティは、一貫性のない構成、調整の欠如、およびユーザーエラーに起因する運用上の問題を軽減するのに役立ちます。

Kubernetes に関してほとんどのユーザーが学習途上にあることを考えると、ユーザーまたはサービスアカウントに完全なクラスタ管理権限を付与するなど、Kubernetes ロールベースのアクセス制御 (RBAC) を使用して昇格された特権を付与したり、必要のない場合でもデプロイメントがシークレットをプルできるようにすることで Kubernetes シークレットを不必要に公開したりするといった間違いは起こりがちです。

Kubernetes ネイティブセキュリティのプラットフォームは、これらの構成ミスを自動的かつ継続的に特定できます。

セキュリティ制御を Kubernetes に直接埋め込むと、障害が発生した場合に、セキュリティが有効になっていないすべてのトラフィックをフェールオープンして許可したり、フェールクローズしてすべてのアプリケーション・トラフィックを中断したりする別個の制御ソフトウェアを使用するリスクも排除されます。

Kubernetes オーケストレーターにポリシー制御を強制することで、セキュリティは Kubernetes 自体のすべてのスケーラビリティとそれに含まれるさまざまなポリシー強制のオプションを即座に取得します。 

対照的に、インラインプロキシやシムを使用して強制すると、単一障害点、スケーラビリティの課題、パフォーマンスの制限が生じます。

Kubernetes により、たとえば、ネットワークポリシーを適用してトラフィックをセグメント化する、アドミッション・コントローラーを使用して Kubernetes API サーバーに送信される要求にポリシーを適用する、シークレットを使用して機密性の高い資格情報を保存する、ロールベースのアクセス制御 (RBAC) を適用して特定のユーザーとサービスアカウントに特定の機能を承認するといったことが可能になります。

コンテナ・ネットワーク・インタフェース (CNI) に準拠するネットワークプラグインなどの追加の標準化されたツールを Kubernetes ネイティブセキュリティのプラットフォームと組み合わせて使用し、必要に応じてそれらの追加ツールを変更することもできます。

Kubernetes は、インフラストラクチャ・サービスのプロビジョニングおよび運用のための単一の統合プラットフォームを提供することにより、アプリケーション開発チームと運用チーム全体のワークフローを効率化し、統合します。 

その同じ統合アプローチ (全員が信頼できる共通のソースを利用して作業し、同じインフラストラクチャを使用している) は、Kubernetes ネイティブセキュリティのプラットフォームをデプロイする際にセキュリティにも拡張できます。 

このアプローチは、短時間で習得できるようにし、より迅速な分析と修復を可能にすることで、時間と費用を節約します。

DevOps チームとセキュリティチームが異なるツールを使用している場合、構成方法で競合が発生しやすくなります。 

DevOps は、2 つのノード間のトラフィックを許可する Kubernetes ネットワークポリシーを指定する場合があり、セキュリティは、そのトラフィックをブロックする別個の制御ソフトウェアを介して制御機能を導入することがあります。

DevOps は Kubernetes の設定を見て、トラフィックが流れているのだからアプリケーションは動作しているはずだと考えます。そして、別個の制御ソフトウェアによって実行される制御は彼らに見えないため、アプリケーションが失敗する理由がまったくわからなくなってしまう場合があります。

DevOps チームとセキュリティチームが同じ構造を使用してコンテナ化されたアプリケーションを構築出荷、および保護する場合、習得するべきインタフェース、ツール、モデルは少なくなります。 

DevOps は、Kubernetes マニフェストファイルを使用して、特定のアプリケーションが必要とするリソースを定義します。同じアセットを使用してセキュリティコンテキストを収集し、ポリシーを適用すると、複雑さが軽減され、セキュリティ成果が向上します。 

Kubernetes ネイティブセキュリティは、Kubernetes をセキュリティポリシーの信頼できるソースとして扱い、セキュリティ、運用、DevOps、サイト信頼性エンジニアリング (SRE) の各チームのすべての人が同じ信頼できるソースを利用して作業します。 

さらに、セキュリティの問題は、これらのチームが日常的に使用する Kubernetes オブジェクトとリソースに直接関連付けられるため、運用はさらに単純化されます。

Kubernetes ネイティブの強制機能をセキュリティポリシーに使用すると、別個のセキュリティソフトウェアを実装することで生じる運用上のリスクを回避できます。

コンテナは、インシデントが広範囲に広がる可能性があること、コンテナによって処理が必要なデータが大量に生成されること、一時的なものであるために従来のインシデント対応が役に立たないことなど、クラウドネイティブ・アプリケーションのさまざまな面でセキュリティを複雑にします。

Kubernetes ネイティブセキュリティを使用すると、コンテナへの脅威をより正確に検出でき、組織が使用する環境にセキュリティを効果的に適用するために必要な時間と労力を削減できます。

Kubernetes コンテキストでは、予想される動作が明確です。その結果、Kubernetes ネイティブセキュリティによって、より忠実に異常を識別でき、Pod の強制終了などの強制オプションをより確実に適用できます。

同時に、Kubernetes コンテキストを使用すると、誤検出やアラート疲れも軽減されます。

Kubernetes ネイティブセキュリティは、セキュリティタスクに対してリスクベースのアプローチを取る機能も提供します。 

デプロイメントには多くのポリシー違反が含まれている可能性があります。しかし、どこから始めればよいのでしょうか。ここでも、Kubernetes コンテキストが役立ちます。 

クラスタが開発中か本番環境にあるか、インターネットに公開されているかどうか、アプリケーションがどの程度重要か、疑わしいプロセスが現在クラスタ上で実行されているかどうかなど、Kubernetes メタデータのさまざまな側面をまとめると、今、チームは何に注意を向ける必要があるのかがわかります。 

Kubernetes 固有の脆弱性、特に Kubernetes API サーバーを危険にさらす脆弱性を検出することは、予防、特定、修正のために特に重要です。Kubernetes ネイティブセキュリティのツールは、これらの脆弱性を自動的に特定できます。

Kubernetes API サーバーとの統合により、Kubernetes クラスタで実行されているコンテナと、デプロイメント、デーモンセット、サービス、Pod、その他のリソースなどの Kubernetes リソースの両方に対してセキュリティ監視が提供されます。

Kubernetes デプロイメントの広く開かれた性質により、別の脅威ベクトルも存在します。Kubernetes は何よりもまずインフラストラクチャを運用するためのプラットフォームなので、運用を容易にするために、デフォルトではすべてのコンポーネントが必ずしも安全であるとは限りません。 

Kubernetes ネットワークポリシーを適用して通信を制限するのは、Kubernetes デプロイメントを保護するためのもう 1 つの重要な要素です。Kubernetes ネイティブセキュリティのプラットフォームは、ネットワーク・アクティビティのベースラインを自動的に設定し、アプリケーションにサービスを提供するために必要な通信パスを特定し、正しい YAML ファイルを作成してネットワークアクセスの範囲を縮小できます。

Kubernetes ネイティブのプラットフォームの自動セキュリティ設定により、Kubernetes レイヤーで脅威を継続的に特定して阻止できます。

Kubernetes ネイティブセキュリティにより、高い可搬性と再利用も可能になります。Kubernetes が実行されるすべての場所で実行される単一の標準化されたアプローチに従うことで、ポリシーがすべての環境に一貫して適用されるようになります。 

Kubernetes ネイティブセキュリティを使用すると、ユーザーは、クラスタ内のすべてのホストでシステムレベルの制御を構成するのではなく、デプロイメント内のすべてのポッドに適用する必要がある、ネットワークポリシーなどの単一の構成を指定できます。 

ポリシーを CI/CD システムと Kubernetes のアドミッション・コントローラーのフレームワークに関連付けることで、ソフトウェア開発ライフサイクルの早い段階で制御ポリシーを適用するのが容易になり、ランタイムの露出を防ぐことができます。 

また、アドミッション・コントローラーなどの Kubernetes コンストラクトを利用することで、セキュリティを Kubernetes ツールチェーンに深く結び付けることができます。