Kubernetes セキュリティのベストプラクティス

Kubernetes セキュリティのベストプラクティスを実装するには、ビルドの段階で既知のセキュリティ脆弱性を修正し、ビルドあるいはデプロイの段階で構成ミスを再構成し、ランタイムで脅威に対応し、Kubernetes インフラストラクチャ全体の安全を確保することが求められます。 

これは、最新の「Kubernetes のセキュリティの現状に関するレポート」の一環として収集された、セキュリティ上の最大の懸念事項に関する回答と一致しており、回答者の 50% 以上が、Kubernetes の高度にカスタマイズ可能な性質とコンテナのセキュリティの複雑性を起因とする構成ミスや脆弱性を懸念していることが判明しました。セキュリティの課題を克服し、アプリケーションのデプロイメントにおける速度低下を回避するために、組織は開発ライフサイクル全体を通じて Kubernetes のセキュリティを優先的に確保する必要があります。

コンテナはいたるところにある

Kubernetes は、Kubernetes クラスタにまとめられた数百 (場合によっては数千) の Linux® コンテナを管理するために使用されるオープンソースのコンテナ・オーケストレーション・プラットフォームです。コンテナ化されたマイクロサービスを接続するアプリケーション・プログラミング・インタフェース (API) に大きく依存しています。この分散性により、どのコンテナに脆弱性があるのか、どのコンテナの構成に誤りがあるのか、どのコンテナが組織に最大のリスクをもたらす可能性があるのかを迅速に調査することは困難になります。

解決策は、各コンテナの重要なシステムレベルのイベントをキャプチャするコンテナ・デプロイメントを包括的に捉えられるようにすることです。

イメージやレジストリが誤用される可能性がある

コンテナイメージ (ベースイメージとも言う) は、新しいコンテナの作成に使用される不変のテンプレートです。新しくコピーしたコンテナイメージは、目的に応じて変更することができます。

解決策は、イメージの作成方法とイメージレジストリへの保存方法を決定するポリシーを設定することです。ベースイメージは、定期的にテスト、承認、スキャンする必要があります。また、Kubernetes 環境でコンテナを起動するには、許可されたイメージレジストリのイメージのみを使用する必要があります。

コンテナ通信に制約がない

コンテナと Pod は、適切に機能するために、デプロイメント内で相互に通信する必要があります。また、他の内部および外部エンドポイントとも通信する必要があります。コンテナが侵害された場合、ハッカーが環境内を移動できるかどうかは、そのコンテナが他のコンテナや Pod とどれだけ広く通信できるかに直接関係しています。広大なコンテナ環境では、そのようなポリシーは手動で構成するには複雑すぎることから、ネットワーク・セグメンテーションの実装が非常に困難な場合があります。

解決策は、名前空間、デプロイメント、および Pod 間を移動するトラフィックを追跡し、そのトラフィックのうちどれだけが実際に許可されるかを決定することです。

コンテナの安全な通信に Red Hat がどう役立つかを知る

デフォルトのコンテナ・ネットワーク・ポリシー

デフォルトでは、Kubernetes デプロイメントは、Kubernetes アプリケーションの最小単位である Pod にネットワークポリシーを適用しません。これらのネットワークポリシーは、ファイアウォールルールのように機能し、Pod の通信方法を制御します。ネットワークポリシーがなければ、どの Pod も他のあらゆる Pod と通信できます。 

解決策は、Pod の通信を定義されたアセットのみに制限するネットワークポリシーを定義し、シークレットを環境変数として渡すのではなく、コンテナ内の読み取り専用ボリュームにマウントすることです。

コンテナと Kubernetes のコンプライアンス

Kubernetes によって促進されるクラウドネイティブ環境は (他のすべての IT 環境と同様に)、セキュリティのベストプラクティス、業界標準、ベンチマーク、そして組織内部のポリシーに準拠し、そのコンプライアンスを証明する必要があります。そのため、元々は従来のアプリケーション・アーキテクチャ用に作成された制御に Kubernetes 環境が適合するように、コンプライアンス戦略を変えることになる場合があります。

解決策は、コンプライアンスの順守を監視し、監査を自動化することです。

ランタイム

Kubernetes は不変のインフラストラクチャです。コンテナの実行中はパッチを適用できません。実行中のコンテナを破棄して再作成する必要があります。不正アクセスを受けたコンテナは、クリプトマイニングやポートスキャンなど、悪意のあるプロセスを実行する可能性があります。

解決策は、侵害されたコンテナや実行中のコンテナを破棄し、危険のないコンテナイメージを再構築してから、再起動することです。

Kubernetes セキュリティは、ビルドの段階で強力なベースイメージを作成し、脆弱性スキャンのプロセスを導入することから始まります。

• 最小限のベースイメージを使用する：オペレーティングシステム (OS) のパッケージマネージャーまたはシェル (未知の脆弱性が含まれている可能性がある) を含むイメージを使用しないようにします。あるいは、後でパッケージマネージャーを削除します。
• 信頼できるソースを使用する： ベースイメージは、信頼できるソースから提供され、信頼できるレジストリにホストされているものだけを選びます。
• 不要なコンポーネントを追加しない： 経験則として、一般的なツールをイメージに含めるとセキュリティリスクになる可能性があります。
• 最新のイメージのみを使用する： コンポーネントのバージョンをアップデートします。
• イメージスキャナーを使用する： イメージ内の脆弱性を特定し、レイヤーごとに分類します。
• CI/CD パイプラインにセキュリティを統合する：重大で修正可能な脆弱性が検知されたら継続的インテグレーションのビルドを失敗させてアラートを生成させるといった、繰り返し可能なセキュリティの側面を自動化します。
• 永続的な脆弱性にラベル付けをする： 修正できない、重大ではない、またはすぐに修正する必要のない既知の脆弱性を許可リストに追加します。 
• 多層防御を実装する： ポリシーチェックと修復ワークフローを標準化して、脆弱なイメージを検出および更新します。

ワークロードをデプロイする前に、Kubernetes インフラストラクチャのセキュリティを構成します。それは、何がデプロイされているか (イメージ、コンポーネント、Pod)、どこにデプロイされているか (クラスタ、名前空間、ノード)、どのようにデプロイされているか (特権、通信ポリシー、適用されたセキュリティ)、何にアクセスできるか (シークレット、ボリューム) とそのコンプライアンス標準など、デプロイのプロセスについて可能な限り知ることから始まります。

• 名前空間を使用する： ワークロードを名前空間に分離すると、攻撃を封じ込めることができ、許可されたユーザーによるミスや破壊的なアクションの影響を制限できます。
• ネットワークポリシーを使用する： Kubernetes のデフォルトではすべての Pod が他のすべての Pod に接続できますが、アプリケーションからの Ingress および Egress トラフィックを制御するネットワーク・セグメンテーション・ポリシーやプラグインでそのデフォルトを上書きできます。
• シークレットへの権限を制限する： デプロイメントに必要なシークレットのみをマウントします。
• コンテナの特権を評価する： コンテナがその役割を果たすために必要な機能、ロール、特権のみを付与します。 
• イメージの出所を評価する： 既知のレジストリから取得したイメージを使用します。
• デプロイメントをスキャンする： スキャンの結果に基づいてポリシーを強制します。 
• ラベルとアノテーションを使用する： トリアージを効率化するために、コンテナ化されたアプリケーションを担当するチームの連絡先情報を使用して、デプロイメントにラベルまたはアノテーションを付けます。
• ロールベースのアクセス制御 (RBAC) を有効にする：RBAC は、クラスタの Kubernetes API サーバーにアクセスするためのユーザーおよびサービスアカウントの承認を制御します。

ビルドおよびデプロイメントの段階で Kubernetes の安全性を確保するためのベストプラクティスを適用すれば、セキュリティインシデントが生じる可能性は減りますが、ランタイムの脅威を特定して対応するには、プロセスアクティビティとネットワーク通信を継続的に監視する必要があります。

• コンテキスト情報を使用する：疑わしいアクティビティを検出するために、Kubernetes のビルドとデプロイの時間情報を使用して、ランタイムに実行予定のアクティビティと実際のアクティビティを評価します。
• 実行中のデプロイメントをスキャンする：コンテナイメージで最近発見されたものと同じ脆弱性について、実行中のデプロイメントを監視します。
• 組み込みの制御を使用する： Pod のセキュリティコンテキストを構成して、その機能を制限します。
• ネットワークトラフィックを監視する： ライブのネットワークトラフィックを観察して、Kubernetes ネットワークポリシーで許可されているものと比較し、予期しない通信を特定します。
• 許可リストを使用する： アプリケーションのランタイムの通常の過程で実行されるプロセスを特定して、許可リストを作成します。
• 同様にデプロイされた Pod のランタイムのアクティビティを比較する： 大幅な逸脱があるレプリカには調査が必要です。
• 疑わしい Pod をゼロにスケーリングする： Kubernetes のネイティブコントロールを使用して、疑わしい Pod をゼロにスケーリングするか、インスタンスを破棄して再起動するように Kubernetes に自動的に指示することで、侵害を封じ込めます。

Kubernetes のセキュリティの対象は、イメージやワークロードだけではありません。セキュリティには、クラスタ、ノード、コンテナエンジン、さらにはクラウドなど、Kubernetes インフラストラクチャ全体が含まれます。

• Kubernetes のアップデートを適用する： Kubernetes ディストリビューションをアップデートすると、セキュリティパッチが適用され、新しいセキュリティツールがインストールされます。
• Kubernetes API サーバーを保護する：Kubernetes API サーバーは、Kubernetes コントロールプレーンへのゲートウェイです。非認証アクセスや匿名アクセスを無効にし、kubelet と API サーバー間の接続に TLS 暗号化を使用します。非定型の API 呼び出しを可視化するために、監査ログも有効にする必要があります。
• etcd を保護する：etcd は、Kubernetes がデータアクセスに使用する Key-Value ストアです。kubelet を保護して攻撃対象を最小化する：--anonymous-auth=false フラグを指定して kubelet を起動することにより、kubelet への匿名アクセスを無効にし、NodeRestriction アドミッション・コントローラーを使用して、kubelet がアクセスできるものを制限します。

クラウドセキュリティ

コンテナをホストする、または Kubernetes を実行するクラウドの種類 (パブリッククラウド、プライベートクラウド、ハイブリッドクラウド、またはマルチクラウド) に関係なく、次のような Kubernetes ワークロードを保護する責任は、クラウドプロバイダーではなく、常にクラウドユーザーにあります。

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

セキュリティの目標は脆弱性とセキュリティのリスクを最小限に抑えることであり、コンテナと Kubernetes を使用してもこれは変わりません。

• コンテナのライフサイクルの早い段階でセキュリティのベストプラクティスを組み込む：Kubernetes セキュリティにより、開発者および DevOps チームは、本番環境に対応するアプリケーションの構築とデプロイを自信を持って行えるようになります。
• Kubernetes ネイティブのセキュリティ制御を使用する：ネイティブコントロールにより、セキュリティ制御がオーケストレーターと衝突するのを防ぎます。 
• Kubernetes に修復を優先させる。

クラウドネイティブ・アプリケーションと基盤のインフラストラクチャをセキュリティ保護するには、組織のセキュリティアプローチを大きく変化させる必要があります。組織は、アプリケーション開発ライフサイクルの早期段階で制御を適用し、組み込みの制御を使用してポリシーを適用することで運用上の問題や拡張性の問題を防止し、短期化が進むリリーススケジュールに対応する必要があります。

Red Hat® Advanced Cluster Security for Kubernetes は Kubernetes ネイティブのセキュリティ・プラットフォームで、クラウドネイティブ・アプリケーションの構築、デプロイ、実行をあらゆる場所でより安全に行えます。アプリケーションの構築プロセスのセキュリティを向上させ、アプリケーション・プラットフォームと構成を保護し、ランタイムの問題を検出して対応するために役立つソリューションです。