Cybersecurity 101:

クベルネテスセキュリティ

Kubernetes security は、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するためのオープンソースシステムです。コンテナを論理ユニットにグループ化すると、管理、保護、検出が容易になります。Kubernetes は、今日の市場における主要なコンテナ管理システムです。Kubernetes を使用してシステムを保護するには、Kubernetes を使用してアプリケーションを作成、デプロイ、実行する際に、システムの仕組みと、さまざまな種類の脆弱性がいつ、どのようにシステムに侵入するかを理解する必要があります。

大まかに言えば、Kubernetes のセキュリティは、クラウド、アプリケーションクラスタ、コンテナ、およびコード内のネイティブセキュリティに対応しています。これには、物理的なセキュリティに関する重要なベストプラクティスに従うことや、クラスタとセキュリティを確保することなど、多くのシステムやプロセスが連動し、重複していることが含まれます。 アプリケーションセキュリティ、マイクロサービスセキュリティの管理、インテリジェントなコンテナ設計標準への準拠、およびアクセス制御の管理これには、ビルド時の脆弱性のスキャン、コードの暗号化、必要な TLS ハンドシェイク、未使用のポートの保護、システム全体の定期的なスキャンも含まれます。 脆弱性 これは実稼働環境で発生する可能性があります。

リスクと課題

アプリケーションはビルド、デプロイ、ランタイムサイクルを通じて実行され、Kubernetes はアプリケーションライフサイクルの各段階で本質的なセキュリティ上の利点をもたらします。ただし、それでも多くの課題が生じる可能性があります。

アタックサーフェスの拡大

システムではおそらく無数のコンテナを使用または作成しますが、コンテナはいたるところにあります。コンテナを使用することでマイクロサービスアーキテクチャを活用し、より高速かつ高い移植性で運用できるようになりますが、コンテナを使用するとセキュリティ上の盲点が生じ、システムが脆弱性にさらされる可能性もあります。

より多くのコンテナをデプロイするにつれて、システム運用とセキュリティの可視性を維持することはますます困難になっています。さらに、個々の問題を調査したり、それに対応したり、誤って構成されたコンテナを再構成したりするタスクもあります。

悪用されたレジストリとイメージ

ビルドするイメージとそれを保存するレジストリーはどの程度安全ですか?定期的にスキャンしていますか?そうしないと、Kubernetes 環境だけでなく、ネットワーク全体のアプリケーションとシステムのセキュリティに悪影響を及ぼす可能性があります。

ネットワークエフェクト

コンテナは他のコンテナや他のネットワークエンドポイントと通信するため、侵害が発生するコンテナセキュリティ侵害されたコンテナがネットワークの他の部分に対して持っているシステムアクセスのレベルによっては、ネットワーク全体に広がる可能性があります。

これらの課題やその他の直面する可能性のある課題にうまく対処するには、ビルド、デプロイ、実行サイクルにセキュリティを組み込む必要があります。大まかに言うと、イメージには危険な脆弱性がなく、デプロイメントはセキュリティのベストプラクティスに従う必要があり、コンテナワークロードは実行時の脅威から保護されている必要があります。

コンテナのベストプラクティス

以下のセクションでは、コンテナライフサイクルの3つのステージすべてで従うべきKubernetesのベストプラクティスのいくつかについて詳しく説明します。

ビルドフェーズ

何よりもまず、コンテナイメージを保護する必要があります。そのためには、まず安全なイメージを構築し、次に脆弱性をスキャンする必要があります。

ベストプラクティスは、最小限の基本イメージを使用し、シェルや OS パッケージマネージャーを含むイメージは使用しないことです。これにより、システムに未知の脆弱性がもたらされる可能性があります。また、不要なコンポーネントの追加は避け、最新のイメージのみを使用してください。ツール、アプリケーション、およびすべてのイメージが最新であることを確認する必要があります。

定期的なスキャンはKubernetesのセキュリティの重要な部分であるため、画像の脆弱性だけでなく、OSパッケージやサードパーティのランタイムの脆弱性も特定できるスキャナーを必ず使用してください。これらのスキャンとセキュリティチェックは、継続的インテグレーション/継続的デプロイ (CI/CD) パイプラインの一部として組み込み、自動化する必要があります。たとえば、Kubernetes の Validating Admission Controller を使用すると、デプロイ前にイメージがスキャンされない場合や、イメージが 90 日以上前のものである場合に、デプロイの作成を拒否できます。

最善のセキュリティポリシーは、多層防御であることを覚えておいてください。そのため、コンテナ、クラスター、クラウド、コードなどの 1 つの領域にある脆弱性は、本番環境に影響を与える前に、またネットワークの他の部分にも及ぶ前に対処できます。

デプロイフェーズ

ワークロードをデプロイする前に、Kubernetes インフラストラクチャを安全に設定する必要があります。何をどのようにデプロイしているのかを把握し、そこから潜在的なセキュリティ脅威や違反を特定して対応できるようにする必要があります。

何を導入しているのかを正確に把握するには、次のことを理解する必要があります。

  • [コンポーネント]
  • 既知の脆弱性
  • デプロイされるポッド
  • 関連するすべてのクラスター、名前空間、ノード
  • 特権的に運営されるかどうか
  • どのデプロイメントと通信するか

また、何にアクセスできるか、導入環境がセキュリティ要件やポリシー要件にすでに準拠しているか、違反しているのかを把握する必要があります。

そこから、デプロイフェーズの推奨事項を実装できます。これには、名前空間を使用して機密性の高いワークロードを分離して潜在的な攻撃を封じ込めること、権限のあるユーザーが行ったエラーや悪意のあるアクションの影響を制限すること、ポッドとクラスター間のトラフィックを経由して制御することが含まれます。 ネットワークセグメンテーション コンテナ間の不正な横移動を防止します。

原則として、コンテナのアクセス権限を含め、システム内の任意のユーザーによるアクセス権限を常に評価する必要があります。必要な機能を実行するのに必要な権限と機能のみをコンテナに付与してください。

また、未知のソースからコードをデプロイしないでください。Kubernetes では、既知のレジストリーまたは権限のあるレジストリーからのイメージのみを使用することになります。開発者やプログラマーなどの関連するビジネスリソースは、デプロイメントに正しい名前やエイリアスを付ける方法を知っている必要があります。そうすれば、関係するチームがセキュリティ上の問題が発生した場合に対処できるようになります。

ランタイムフェーズ

ランタイム環境を可視化し、ランタイムの脅威が発生したときにそれを検出して対応することで、Kubernetes のセキュリティ上の課題を管理できます。

これには、プロセスアクティビティの監視、異なるコンテナとコンテナ化されたサービス間のネットワーク通信、およびコンテナ、コンテナ化されたサービス、およびサードパーティ、クライアント、または外部サーバー間の通信が含まれます。

観測されたアクティビティと予想されるアクティビティを比較することで、疑わしいアクティビティを特定して阻止できます。脆弱性スキャンを実行中のデプロイにも適用することで、以前には見られなかった実行時の脆弱性を検出しやすくなります。読み取り専用のルートファイルシステムなど、Kubernetes に組み込まれているコントロールの多くは、ソフトウェアのインストールを必要とする攻撃を防ぐことができます。ネットワークトラフィックを監視して、不要な、またはセキュリティで保護されていない通信を制限する必要があります。

ビルトイン機能

ビルド、デプロイ、ランタイムの各段階におけるKubernetesのセキュリティは重要ですが、セキュリティの問題には総合的に取り組む必要があります。つまり、まずインフラストラクチャのセキュリティから始めて、まずシステムの全体像を把握し、次にシステムのより詳細なクラスタ/コンテナ/コードビューを見ることで、ネットワークを拡大または縮小する必要があります。

Kubernetes は常に可能であれば最新バージョンに更新してください。また、Kubernetes がデータアクセスに使用するキーバリューストアである etcd を保護してください。すべてのクライアント接続が TLS 経由でのみ提供されるようにし、コンテナライフサイクルのできるだけ早い段階でセキュリティを積極的に組み込んでください。また、Kubernetes のネイティブコントロールについてもよく理解しておいてください。

以下は、コンテナオーケストレーションを強化できるビルトインKubernetes機能の例です。

  • オープンポリシーエージェント (OPA): OPA では、ポリシーをコードとして指定できる高レベルの宣言型言語を使用してポリシーの適用を統一します。これにより、ポリシーに関する意思決定の負担がソフトウェアから取り除かれます。OPA を使用すると、Kubernetes API サーバーを再コンパイルまたは再構成しなくても、Kubernetes オブジェクトに必要なカスタムポリシーを適用できます。
  • ポッドセキュリティポリシー (PSP):PSP を使用して、特定のポッドがシステムに受け入れられるために実行する必要がある条件を定義します。セキュリティコンテキストを使用して適用される PSP セキュリティ設定により、特定のポッドの権限とアクセス制御を定義することもできます。
  • ロールベースのアクセス制御 (RBAC): RBAC は承認の決定を管理します。これにより、管理者は特定のユーザーまたはユーザーセットに対するロールバインディングと権限を使用してアクセスポリシーを動的に設定できます。
  • ネットワークポリシー: ポッドのグループ同士や他のネットワークエンドポイントとの通信方法を規定する通信ポリシー。

これらのツールやその他の組み込みツールをいつ、どこで、どのように使用して Kubernetes を正しく活用するかを学ぶには時間がかかることがあります。これと同じことが、徹底的な防御の確保、セキュリティ上の脆弱性の発生時の特定と対処、クラスターの保護、ポッドセキュリティの確保、脆弱性の軽減にも当てはまります。 アタックサーフェス、およびネットワークトラフィックの管理。ただし、Kubernetes が設計したコンテナのスケーラビリティ、複製性、シンプルな管理、迅速なデプロイを実現するには、Kubernetes のセキュリティを確保することが重要です。

結論

Kubernetes に初めて参入する場合は、サードパーティの Kubernetes スペシャリストが、組織が構築するアプリケーションの種類と必要なデプロイの種類に基づいて、クラスタオーケストレーションを迅速に導入して実行できるよう支援します。

さらに詳しく

その方法をご覧ください ゼロトラストセグメンテーション Kubernetes や RedHat OpenShift プラットフォームを含むコンテナデプロイメントを保護します。

Assume Breach.
影響を最小限に抑えます。
レジリエンスを高めます。

ゼロトラストセグメンテーションについて詳しく知る準備はできていますか?