GKE セキュリティ: クラスターを保護するための 10 の戦略

セキュリティは、構成の複雑さと脆弱性の多さにより、Kubernetes が直面している主な課題の 1 つです。 Google Kubernetes Engine (GKE) などのマネージド コンテナ サービスは多くの保護を提供しますが、関連するすべての責任が免除されるわけではありません。 GKE のセキュリティとクラスターを保護するためのベスト プラクティスについて詳しくは、以下をお読みください。

GKE セキュリティの基本概要

GKE は、コンテナ イメージ、ランタイム、クラスタ ネットワーク、クラスタ API サーバーへのアクセスなど、多くのレイヤーでワークロードを保護します。

したがって、Google では、クラスタとワークロードを保護するために階層化アプローチを採用することを推奨しています。組織がワークロードを展開および維持するために適切なレベルの柔軟性とセキュリティを有効にするには、一部の設定が制限的すぎる可能性があるため、ある程度のトレードオフが必要になる場合があります。

GKE セキュリティの最も重要な側面は次のとおりです。

認証と承認。

コンポーネントと構成を含むコントロール プレーンのセキュリティ。

ノードセキュリティ。

サイバーセキュリティ。

これらの要素は CIS ベンチマークにも反映されており、Kubernetes の安全な構成に関する取り組みを構築するのに役立ちます。

CIS ベンチマークが GKE セキュリティにとって重要なのはなぜですか?

K8s のセキュリティ構成を扱うのは簡単なことではありません。

Red Hat の 2022 年 Kubernetes およびコンテナ セキュリティの現状では、深刻な問題のほぼ 4 分の 1 が修正可能な脆弱性であることが判明しました。インシデントの約 70% は構成エラーが原因で発生しました。

このベンチマークは、インターネット セキュリティ センター (CIS) によってリリースされて以来、サイバー セキュリティ メカニズムの実装と管理に関するベスト プラクティスとして世界的に認知されるようになりました。

CIS Kubernetes ベンチマークには、強力なセキュリティ体制をサポートする K8s 構成の推奨事項が含まれています。これはオープンソースの Kubernetes ディストリビューション用に書かれており、一般的に適用可能です。

CIS における GKE ベンチマークの実践

GKE のようなマネージド サービスでは、CIS ベンチマークのすべての項目を制御できるわけではありません。

このため、一部の提案は自分で直接確認したり変更したりすることはできません。これらには以下が含まれます。

制御プレーン;

Kubernetes ディストリビューション。

ノードのオペレーティング システム。

ただし、ワークロードを実行するノード、そしてもちろんワークロード自体をアップグレードするように注意する必要があります。これらのコンポーネントに関する推奨事項はすべて確認して修正する必要があります。

これを手動で行うことも、CIS ベンチマークを処理するツールを使用することもできます。たとえば、CAST AI のコンテナ セキュリティ モジュールを使用すると、クラスターに接続してから数分以内にベースラインの違いを大まかに把握できます。

また、このプラットフォームでは特定した問題に優先順位を付けるため、どの項目を最初に修正する必要があるかがわかります。クラスターをスキャンするときに、業界のベスト プラクティスに照らしてチェックを実行し、全体的なセキュリティ体制をより適切に評価し、GKE の強化をさらに計画することもできます。

GKE を保護するためのトップ 10 戦略

1. 最小権限の原則を適用する

この基本的なセキュリティ原則では、ユーザー アカウントには、意図された機能を実行するために必要な権限のみが付与されることが規定されています。

CIS GKE ベンチマーク 6.2.1 に含まれています: Compute Engine のデフォルトのサービス アカウントを使用して GKE クラスタを実行することは望ましくありません。

デフォルトでは、ノードは Compute Engine サービス アカウントにアクセスできます。幅広いアクセス権限により複数のアプリケーションに役立ちますが、GKE クラスターを実行するために必要な権限よりも多くの権限も持っています。このため、デフォルトのアカウントではなく、最小限の権限を持つサービス アカウントを作成して使用する必要があります。

2. RBACを使用して認証と承認を強化する

GKE は、ロールベースのアクセス制御 (RBAC) を通じてクラスターへのアクセスを管理するためのいくつかのオプションをサポートしています。

RBAC を使用すると、クラスターおよび名前空間レベルで Kubernetes リソースへのよりきめ細かいアクセスが可能になりますが、詳細な権限ポリシーを作成することもできます。

CIS GKE ベンチマーク 6.8.4 では、従来の属性ベースのアクセス制御 (ABAC) よりも RBAC を優先する必要性を強調しています。

別の CIS GKE ベンチマーク (6.8.3) では、ID と権限の制御が簡素化されるため、グループを使用してユーザーを管理することを推奨しています。また、ユーザーがグループに追加またはグループから削除されるときに、RBAC 構成を更新する必要がなくなります。

3. コントロールプレーンのセキュリティを強化する

共有責任モデルでは、Google が GKE コントロール プレーン コンポーネントを管理します。ただし、ノード、コンテナ、およびポッドのセキュリティ保護は引き続きお客様の責任となります。

デフォルトでは、Kubernetes API サーバーはパブリック IP アドレスを使用します。承認済みネットワークとプライベート クラスターを使用して保護することができ、これによりプライベート IP アドレスを割り当てることができます。

定期的に資格情報のローテーションを実行することで、コントロール プレーンのセキュリティを強化することもできます。プロセスを開始すると、TLS 証明書とクラスター証明機関が自動的にローテーションされます。

4. GKEインフラストラクチャを定期的にアップグレードする

Kubernetes は新しいセキュリティ機能とパッチを頻繁にリリースするため、K8s を最新の状態に保つことは、セキュリティ体制を改善する最も簡単な方法の 1 つです。

GKE はコントロール プレーンに自動的にパッチを適用し、アップグレードします。ノードの自動アップグレードにより、クラスター内のノードも自動的にアップグレードされます。 CIS GKE ベンチマーク 6.5.3 では、この設定を維持することを推奨しています。

何らかの理由で自動アップグレードを無効にする必要がある場合は、毎月アップグレードを実行し、重要なパッチについては GKE セキュリティ情報に従うことをおすすめします。

5. ノードメタデータの保護

CIS GKE ベンチマーク 6.4.1 および 6.4.2 では、ノード セキュリティに影響を与える 2 つの重要な要素について言及されていますが、これは引き続きユーザーの責任となります。

v0.1 および v1beta1 Compute Engine メタデータ サーバー エンドポイントは、メタデータ クエリ ヘッダーを適用しなかったため、2020 年に非推奨となり、シャットダウンされました。

Kubernetes に対する一部の攻撃では、VM のメタデータ サーバーにアクセスして資格情報を抽出します。これらの攻撃は、ワークロードの識別またはメタデータの非表示を使用して防ぐことができます。

6. Kubernetesダッシュボードを無効にする

数年前、攻撃者がテスラのクラウドリソースにアクセスし、それを使用して暗号通貨をマイニングしたというニュースが世界に衝撃を与えました。この場合、攻撃ベクトルは、認証や昇格された権限なしで一般に公開された Kubernetes ダッシュボードでした。

Tesla のパスに従わないようにしたい場合は、CIS GKE ベースライン 6.10.1 に準拠することをお勧めします。この標準では、GKE 上で実行する場合は Kubernetes Web UI を無効にする必要があることが明確に規定されています。

GKE 1.10 以降では、K8s ダッシュボードはデフォルトで無効になっています。次のコードを使用することもできます。

gcloud コンテナ クラスタ更新 CLUSTER_NAME \

--update-addons=KubernetesDashboard=無効

7. NSA-CISAフレームワークに従う

CIS Kubernetes ベンチマークは、安全な運用環境を構築するための強固な基盤を提供します。しかし、さらに進んでみたい場合は、セキュリティ プログラムに NSA-CISA Kubernetes 強化ガイドを追加する余地を確保してください。

NSA-CISA レポートでは、Kubernetes エコシステムの脆弱性について概説し、クラスター セキュリティを構成するためのベスト プラクティスを推奨しています。

脆弱性スキャン、誤った構成の特定、ログの確認、認証に関する推奨事項を提供し、一般的なセキュリティ上の課題に適切に対処できるようにします。

8. オンラインセキュリティを強化する

GKE で実行されるほとんどのワークロードは、クラスターの内外で実行されている他のサービスと通信する必要があります。ただし、クラスターを通過するトラフィックを制御することはできます。

まず、ネットワーク ポリシーを使用してコンテナー間の通信を制限できます。デフォルトでは、すべてのクラスター Pod IP アドレスはネットワーク経由でアクセスできます。 Pod を通過するトラフィックを定義し、構成されたラベルと一致しないトラフィックを停止することで、名前空間内の接続をロックダウンできます。

次に、ネットワーク ロード バランサーを使用して Kubernetes Pod のバランスをとることができます。これを行うには、コンテナ ラベルに一致するロード バランサ サービスを作成する必要があります。 Kubernetes Pod のポートにマッピングされた外部向け IP が用意され、kube-proxy を使用してノード レベルで承認されたトラフィックをフィルター処理できるようになります。

9. Google Cloud リソースへのコンテナ アクセスを保護

コンテナとポッドは、Google Cloud 内の他のリソースにアクセスする必要がある場合があります。これを行うには、ワークロード ID、ノード サービス アカウント、サービス アカウント JSON キーを使用する 3 つの方法があります。

Google Cloud リソースにアクセスするための最も簡単で安全なオプションは、ワークロード ID を使用することです。この方法により、GKE 上で実行されているポッドが Google Cloud サービス アカウントにアクセスできるようになります。

アプリケーション固有の Google Cloud サービス アカウントを使用して認証情報を提供し、侵害が発生した場合に取り消すことができる必要最小限の権限をアプリケーションに付与する必要があります。

10. GKEで構成されたキーマネージャーを取得する

CIS GKE ベンチマーク 6.3.1。 Cloud KMS で管理されるキーを使用して Kubernetes シークレットを暗号化することをお勧めします。

Google Kubernetes Engine には、シークレットを管理するためのいくつかのオプションが用意されています。 GKE では Kubernetes シークレットをネイティブに使用できますが、管理するキーとアプリケーション レイヤ シークレットの暗号化を使用して、アプリケーション レイヤでこれらのシークレットを保護することもできます。

また、Hashicorp Vault のようなシークレット マネージャーもあり、GKE でシークレットを管理するための一貫性のある本番環境対応の方法を提供します。必ず選択肢を検討し、最適なソリューションを選択してください。

GKE のセキュリティを数分で評価

Kubernetes エコシステムは成長を続けていますが、セキュリティ構成の課題も増えています。 GKE コンテナのセキュリティを常に最優先にするには、潜在的な脅威を特定し、効果的に追跡できる必要があります。

Kubernetes セキュリティ レポートを使用すると、CIS ベンチマーク、NSA-CISA フレームワーク、その他のコンテナ セキュリティのベスト プラクティスを基準に GKE クラスターをスキャンして、脆弱性を特定し、構成ミスを検出して優先順位を付けることができます。わずか数分でクラスターのセキュリティ状況を包括的に把握できます。