クラスタのセキュリティの強化

Kubernetes の開発ペースは速く、新たなセキュリティ機能がしばしば登場します。このページでは、Google Kubernetes Engine クラスタを強化するための最新ガイダンスを実践する方法について説明します。

このガイドでは、クラスタの作成時にお客様の操作が必要となる価値のあるセキュリティ対策を優先します。重要性の低い機能、デフォルトでセキュアな設定、作成後に有効にできる項目についてはドキュメントの後半でご説明します。セキュリティ トピックの概要については、セキュリティの概要をお読みください。

セキュリティ状況の分析を使用すると、こうした推奨事項の多く、またその他構成の誤りが自動的に確認されます。

下記の推奨事項は CIS GKE ベンチマークの推奨事項に関するもので、これが指定されています。

GKE インフラストラクチャを逐次アップグレードする（デフォルト: 2019-11-11）

CIS GKE ベンチマークの推奨事項: 6.5.3.ノードの自動アップグレードが GKE ノードに対して有効になっていることを確認する

セキュリティを向上させる最も簡単な方法の 1 つに、Kubernetes のバージョンを最新の状態に保つことがあります。Kubernetes は頻繁に新しいセキュリティ機能を導入し、セキュリティ パッチを提供しています。

セキュリティ パッチの詳細については、GKE セキュリティに関する情報を参照してください。

Google Kubernetes Engine では、コントロール プレーンへのパッチやアップグレードが自動的に行われます。ノードの自動アップグレードでも、クラスタ内のノードが自動的にアップグレードされます。

ノードの自動アップグレードを無効にする場合は、自身の都合に合わせて、毎月アップグレードすることを推奨します。古いクラスタでは、ノードの自動アップグレードを有効にする設定にしたうえで、重要なパッチについて GKE セキュリティ情報に厳密に従ってください。

詳細は、ノードの自動アップグレードをご覧ください。

コントロール プレーンとノードへのネットワーク アクセスを制限する

CIS GKE ベンチマークの推奨事項: 6.6.2. VPC ネイティブ クラスタを優先する、6.6.3. マスター認証ネットワークが有効であることを確認する、6.6.4.クラスタが非公開エンドポイント有効と公開アクセス無効で作成されていることを確認する、6.6.5. クラスタがプライベート ノードで作成されていることを確認する

クラスタ コントロール プレーンとノードのインターネットへの公開を制限する必要があります。これらの設定は、クラスタ作成時のみ行えます。

GKE のクラスタ コントロール プレーンとノードには、任意の IP アドレスからアクセスできる、インターネット上でルーティング可能なアドレスがデフォルトで付与されています。

GKE のクラスタ コントロール プレーンについては、限定公開クラスタの作成をご覧ください。ネットワーク レベルの保護を提供できる限定公開クラスタには、次の 3 種類があります。

  • パブリック エンドポイント アクセスが無効: コントロール プレーンとノードの両方へのインターネット アクセスをすべて防ぐ、最も安全なオプションです。Cloud Interconnect と Cloud VPN を使用してオンプレミス ネットワークから Google Cloud への接続を構成している場合に適しています。これらを用いれば、企業ネットワークとクラウド VPC を効率的に接続できます。
  • パブリック エンドポイント アクセスが有効、承認済みネットワークが有効（推奨）: このオプションにより、定義するソース IP アドレスからコントロール プレーンへのアクセスが制限されます。これは、既存の VPN インフラストラクチャがない場合や、リモート ユーザーや支社が企業 VPN や Cloud Interconnect / Cloud VPN を使用せずに公共のインターネット経由で接続する場合に適しています。
  • パブリック エンドポイント アクセスが有効、承認済みネットワークが無効: この設定はデフォルトで、インターネット上の誰でもコントロール プレーンにネットワーク接続できるようにします。

ノードへの直接的なインターネット アクセスを無効にするには、クラスタ作成時に gcloud ツールで --enable-private-nodes オプションを指定します。

これにより GKE が内部 IP アドレスを持つノードをプロビジョニングするように指示するため、公共のインターネット経由でノードに直接アクセスすることはできません。

少なくとも承認済みネットワークとプライベート ノードを使用することをおすすめします。これにより、以下がコントロール プレーンにアクセス可能になります。

  • 承認済みネットワークで許可された CIDR。
  • クラスタの VPC 内のノード。
  • Google がお客様のコントロール プレーンを管理するために本番環境で実行する内部ジョブ。

これは、クラスタ作成時の次の gcloud フラグに対応します。

  • --enable-ip-alias
  • --enable-private-nodes
  • --enable-master-authorized-networks

グループ認証（ベータ版）

CIS GKE ベンチマークの推奨事項: 6.8.3. GKE 向け Google グループで Kubernetes RBAC ユーザーを管理することを検討する

この設定は、クラスタ作成時にのみ有効にできます。

グループを使用してユーザーを管理する必要があります。グループを使用すると、ID 管理システムと ID 管理者を使用して ID を制御できます。グループ メンバーシップを調整するだけで、メンバーをグループに追加または削除するたびに RBAC の構成を更新する必要がなくなります。

Google グループを使用してユーザー権限を管理するには、クラスタの作成時に GKE 用 Google グループを有効にする必要があります。これにより、同じ権限を持つユーザーを簡単に管理でき、ID 管理者は、ユーザーの一貫した一元管理ができるようになります。

GKE 用 Google グループを有効にするには、ユーザー アクセスを管理するための Google グループ、gke-security-groups を作成し、クラスタの作成時に gcloud でフラグ --security-group を設定します。

コンテナノードを選択する

次のセクションでは、安全なノード構成の選択について説明します。

シールドされた GKE ノードを有効にする

CIS GKE ベンチマークの推奨事項: 6.5.5。シールドされた GKE ノードが有効になっていることを確認する

シールドされた GKE ノードは強固で検証可能なノード ID と完全性を備え、GKE ノードのセキュリティが高められているので、すべての GKE クラスタでこれを有効にすることをおすすめしています。

シールドされた GKE ノードを有効にするには、クラスタの作成時または更新時に gcloud でオプション --enable-shielded-nodes を指定します。シールドされた GKE ノードを有効にするときは、セキュアブートも有効にしてください。サードパーティの未署名のカーネル モジュールが必要な場合は、セキュアブートを使用しないでください。セキュアブートを有効にするには、クラスタを作成する際に gcloud でフラグ --shielded-secure-boot を指定します。

containerd ランタイムで強化されたノードイメージを選択する

Containerd を使用した Container-Optimized OS（cos_containerd ）イメージは、Container-Optimized OS イメージのバリアントであり、containerd がメインのコンテナ ランタイムとして Kubernetes に直接統合されています。

containerd は Docker のコアランタイム コンポーネントで、Kubernetes Container Runtime Interface（CRI）にコアコンテナ機能を提供するように設計されています。完全な Docker デーモンよりもはるかに簡潔なので、攻撃対象領域が小さくなります。

クラスタで cos_containerd イメージを使用するには、クラスタの作成時またはアップグレード時に gcloud でフラグ --image-type=cos_containerd を指定します。

コンテナを実行するためにカスタムビルドされ、最適化され、強化されていることから cos_containerd は GKE の推奨イメージとなっています。

Workload Identity を有効にする

CIS GKE ベンチマークの推奨事項: 6.2.2。専用の Google Cloud サービス アカウントとワークロード ID を優先的に使用する

Google API への認証方法には Workload Identity がおすすめです。サービス アカウントを使用した Google Cloud への認証で説明されているように、ノードのサービス アカウントを使用したり、サービス アカウントのキーを Secret にエクスポートしたりする以前の方法の代わりにこの方法を使用できます。

Workload Identity は、メタデータ隠蔽機能に代わるものでもあり、この 2 つに互換性はありません。メタデータ隠蔽機能で保護された機密メタデータは Workload Identity でも保護されます。

GKE Sandbox によるワークロード分離の強化

CIS GKE ベンチマークの推奨事項: 6.10.4。信頼できないワークロードの場合は特に、ワークロードの分離を強化するために GKE Sandbox の使用を検討する

GKE Sandbox は、セキュリティに新たなレイヤを追加し、悪意のあるコードからクラスタノードのホストカーネルを保護します。

GKE Sandbox の使用方法については、GKE Sandbox によるワークロード分離の強化をご覧ください。

権限

最小限の権限の Google サービス アカウントを使用する

CIS GKE ベンチマークの推奨事項: 6.2.1. GKE クラスタの実行時に Compute Engine のデフォルト サービス アカウントを使用しないようにする

各 GKE ノードには Identity and Access Management（IAM）サービス アカウントが関連付けられています。デフォルトでは、ノードに Compute Engine のデフォルトのサービス アカウントが付与されています。このアカウントは、Cloud Console の IAM セクションに移動すると見つかります。このアカウントにはデフォルトで広範なアクセス権があり、さまざまな用途に役立ちますが、Kubernetes Engine クラスタの実行には権限が過剰です。Compute Engine のデフォルト サービス アカウントを使用するのでなく、最小限の権限のみを持つサービス アカウントを作成して、GKE クラスタを実行するときに使用するようにしてください。

Workload Identity のリリースに伴い、ノードサービス アカウントのユースケースを制限することをおすすめしています。Google では、ロギングやモニタリング、その他の似たようなタスクを担当するシステム デーモンがノード サービスアカウントを使用するようになると考えています。ポッドのワークロードには、代わりに Workload Identity を使用して Google ID をプロビジョニングするようにしてください。

GKE では、最低でもサービス アカウントにmonitoring.viewer、monitoring.metricWriter、logging.logWriter および stackdriver.resourceMetadata.writer のロールが必要です。詳細については、モニタリングのロールとロギングのロールをご覧ください。

以下のコマンドは、GKE を操作するために必要な最低限の権限を持つ IAM サービス アカウントを作成します。

gcloud

gcloud iam service-accounts create sa-name \
  --display-name=sa-name

gcloud projects add-iam-policy-binding project-id \
  --member "serviceAccount:sa-name@project-id.iam.gserviceaccount.com" \
  --role roles/logging.logWriter

gcloud projects add-iam-policy-binding project-id \
  --member "serviceAccount:sa-name@project-id.iam.gserviceaccount.com" \
  --role roles/monitoring.metricWriter

gcloud projects add-iam-policy-binding project-id \
  --member "serviceAccount:sa-name@project-id.iam.gserviceaccount.com" \
  --role roles/monitoring.viewer

gcloud projects add-iam-policy-binding project-id \
  --member "serviceAccount:sa-name@project-id.iam.gserviceaccount.com" \
  --role roles/stackdriver.resourceMetadata.writer

Config Connector

注: この手順には Config Connector が必要です。Config Connector をクラスタにインストールするには、インストール手順に従ってください。

  1. サービス アカウントを作成するには、次のリソースを service-account.yaml としてダウンロードします。[SA_NAME] を、このサービス アカウントに使用する名前に置き換えます。

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMServiceAccount
metadata:
  name: [SA_NAME]
spec:
  displayName: [SA_NAME]
    次のコマンドを実行します。 
    kubectl apply -f service-account.yaml

  2. サービス アカウントに logging.logWriter 役割を割り当てます。次のリソースを policy-logging.yaml としてダウンロードします。[SA_NAME] と [PROJECT_ID] はお客様自身の情報に置き換えてください。

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-logging
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/logging.logWriter
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
    kubectl apply -f policy-logging.yaml

  3. monitoring.metricWriter ロールを割り当てます。次のリソースを policy-metrics-writer.yaml としてダウンロードします。[SA_NAME] と [PROJECT_ID] はお客様自身の情報に置き換えてください。

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-metrics-writer
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/monitoring.metricWriter
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
    kubectl apply -f policy-metrics-writer.yaml

  4. monitoring.viewer ロールを割り当てます。次のリソースを policy-monitoring.yaml としてダウンロードします。[SA_NAME] と [PROJECT_ID] はお客様自身の情報に置き換えてください。

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-monitoring
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/monitoring.viewer
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
    kubectl apply -f policy-monitoring.yaml

Google Container Registry の非公開イメージを使用する場合は、それらのイメージに対するアクセス権も付与する必要があります。

gsutil

gsutil iam ch \
  serviceAccount:sa-name@project-id.iam.gserviceaccount.com:objectViewer \
  gs://bucket-name

イメージを保存するバケットは、以下のフォームの名前 bucket-name を持っています。

  • artifacts.project-id.appspot.com。gcr.io ホスト内のレジストリに push されたイメージの場合。
  • storage-region.artifacts.project-id.appspot.com

以下を置き換えます。

  • project-id は、Google Cloud Console プロジェクト ID です。
  • storage-region は、ストレージ バケットの場所です。
    • us。us.gcr.io ホストのレジストリの場合
    • eu。eu.gcr.io ホストのレジストリの場合
    • asia。asia.gcr.io ホストのレジストリの場合

コマンドの詳細については、gsutil iam のドキュメントをご覧ください。

Config Connector

注: この手順には Config Connector が必要です。Config Connector をクラスタにインストールするには、インストール手順に従ってください。

storage.objectViewer ロールをサービス アカウントに適用します。次のリソースを policy-object-viewer.yaml としてダウンロードします。[SA_NAME] と [PROJECT_ID] はお客様自身の情報に置き換えてください。

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-object-viewer
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/storage.objectViewer
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
kubectl apply -f policy-object-viewer.yaml

他のユーザーがこのサービス アカウントで新しいクラスタまたはノードプールを作成できるようにするには、そのサービス アカウントのユーザーにサービス アカウント ユーザーロールを付与します。

gcloud

gcloud iam service-accounts add-iam-policy-binding \
sa-name@project-id.iam.gserviceaccount.com \
--member=user:user \
--role=roles/iam.serviceAccountUser

Config Connector

注: この手順には Config Connector が必要です。Config Connector をクラスタにインストールするには、インストール手順に従ってください。

iam,serviceAccountUser ロールをサービス アカウントに適用します。次のリソースを policy-service-account-user.yaml としてダウンロードします。[SA_NAME] と [PROJECT_ID] はお客様自身の情報に置き換えてください。

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-service-account-user
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/iam.serviceAccountUser
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
kubectl apply -f policy-service-account-user.yaml

クラスタがすでに存在する場合は、この新しいサービス アカウントを使用して新しいノードプールを作成できます。

gcloud container node-pools create node-pool \
  --service-account=sa-name@project-id.iam.gserviceaccount.com \
  --cluster=cluster-name

GKE クラスタが他の Google Cloud サービスにアクセスする必要がある場合は、追加のサービス アカウントを作成し、Workload Identity を使用してワークロードからサービス アカウントへのアクセスを許可します。

クラスタ API 検出へのアクセスを制限する

Kubernetes はデフォルトで、CustomResourceDefinitions の API など、クラスタの API に関する情報に幅広くアクセスできる、制約の緩いディスカバリ ClusterRoleBindings のセットでクラスタをブート ストラップします。

system:discovery と system:basic-user の ClusterRoleBindings のサブジェクトにある system:authenticated グループには、認証済みユーザーなら誰でも含めることができ（Google アカウントを持つユーザーもこれに含まれます）、そのためこのグループは GKE のクラスタのセキュリティにとってむしろ無意味なレベルに相当することに留意する必要があります。

クラスタのディスカバリ API を強化する場合は、次のうち 1 つ以上を実施することを検討してください。

これらのオプションが GKE のユースケースに適していない場合、すべての API 検出情報（CustomResources のスキーマ、APIService の定義、拡張 API サーバーでホストされている検出情報）を一般公開として扱います。

Namespace と RBAC を使用してクラスタ リソースへのアクセスを制限する

CIS GKE ベンチマークの推奨事項: 5.6.1. 名前空間を使用してリソース間の管理境界を作成する

各チームと環境に個別の名前空間またはクラスタを作成して、チームに付与する Kubernetes へのアクセス権限を最低限に抑えます。アカウンタビリティとチャージバックに基づいて各名前空間にコストセンターと適切なラベルを割り当てます。開発者に付与する名前空間へのアクセス権は（特に本番環境において）、アプリケーションのデプロイと管理に必要なレベルのみに制限します。ユーザーがクラスタに対して行う必要があるタスクをマッピングし、各タスクの実行に必要な権限を定義します。

名前空間の作成について詳しくは、Kubernetes のドキュメントをご覧ください。

IAM とロールベースのアクセス制御（RBAC） は相互に連携するため、クラスタ内のリソースを操作するには、エンティティに双方のレベルで十分な権限を与える必要があります。

GKE に適した IAM ロールをグループやユーザーに割り当て、プロジェクト レベルで権限を提供します。RBAC を使ってクラスタと Namespace レベルで権限を付与します。詳細については、アクセス制御をご覧ください。

詳細については、Kubernetes Engine 本番環境の準備を参照してください。

ポッド間のトラフィックをネットワーク ポリシーで制限する

CIS GKE ベンチマークの推奨事項: 6.6.7. ネットワーク ポリシーが有効であることを確認し、必要に応じて設定する

デフォルトでは、クラスタ内のすべてのポッドが相互通信できます。ポッド間通信は、ワークロードのニーズに応じて制御してください。

サービスへのネットワーク アクセスを制限することで、攻撃者によるクラスタ内移動の難易度を大幅に上げることができ、偶発的または意図的な DoS 攻撃に対してサービスをある程度は保護できます。トラフィックを制御する 2 つの推奨方法は次のとおりです。

  1. Istio を使用します。GKE に Istio をインストールするを参照してください。負荷分散、サービス認証、スロットリング、割り当て、指標などに関心がある場合は選択します。
  2. Kubernetes ネットワーク ポリシーを使用します。クラスタ ネットワーク ポリシーの設定を参照してくください。Kubernetes で公開されている基本的なアクセス制御機能をお探しの場合は、これを選択します。ネットワーク ポリシーを使用してトラフィックを制限する一般的なアプローチを実装するには、Anthos セキュリティ ブループリントの実装ガイドに従ってください。Kubernetes のドキュメントには簡単な nginx デプロイに関する優れたチュートリアルがあります。ネットワーク ポリシー ロギング（ベータ版）を使用して、ネットワーク ポリシーが期待どおりに動作していることを確認します。

Istio とネットワーク ポリシーは、必要に応じて併用できます。

Secret 管理

CIS GKE ベンチマークの推奨事項: 6.3.1. Cloud KMS で管理されている鍵を使用して Kubernetes Secrets を暗号化する

シークレットを etcd に保存するなど、機密データを保護するために追加の層を設けることをおすすめします。これを行うには、GKE クラスタと統合されたシークレット マネージャーを構成する必要があります。複数の環境でワークロードを実行する場合、一部のソリューションは GKE と VMware の Anthos クラスタの両方で動作するため、おすすめします。HashiCorp Vault などの外部シークレット マネージャーを使用する場合は、クラスタを作成する前に設定する必要があります。

シークレットを管理する方法はいくつかあります。

  • Kukenetes シークレットは、GKE でネイティブに使用できます。アプリケーション レイヤで Application-layer secrets encryption を使用して、自分が管理している鍵で Kukenetes シークレットを暗号化することもできます。
  • HashiCorp Vault などのシークレット マネージャーを使用できます。強化 HA モードで実行すると、本番環境に適応した一貫性のあるシークレット管理が可能になります。HashiCorp Vault への認証には、Kubernetes サービス アカウントまたは Google Cloud サービス アカウントを使用できます。Vault と GKE を使用する詳しい方法については、Kubernetes での HashiCorp Vault の実行と接続を参照してください。

GKE の VM は、etcd を含むストレージ レイヤではデフォルトで暗号化されます。

アドミッション コントローラを使用してポリシーを適用する

CIS GKE ベンチマークの推奨事項: 6.10.3. ポッド セキュリティ ポリシーが有効で、適切に設定されていることを確認する

アドミッション コントローラは、クラスタの使用方法を管理および適用するプラグインです。Kubernetes の高度なセキュリティ機能の一部を使用するには、アドミッション コントローラを有効にする必要があります。また、クラスタを強化するための多層防御アプローチの重要な部分でもあります。

デフォルトでは、Kubernetes のポッドは、必要とする以上の機能で動作します。ポッドの機能は、そのワークロードに必要な機能だけに制限するようにしてください。

Kubernetes では、明示的に付与された機能のみを使用してポッドが実行されるように、多数の制御がサポートされています。最も一般的な制御は ゲートキーパーとポッド セキュリティ ポリシーの 2 つです。

Gatekeeper は、宣言型ポリシーを使用して GKE クラスタにセキュリティを適用し、強化する強力な手段を提供します。ゲートキーパーを使用して GKE クラスタで宣言型の制御を行う方法については、ゲートキーパーを使用してポッド セキュリティ ポリシーを適用するをご覧ください。

ポッド セキュリティ ポリシーを使用すると、ポッドにスマートなデフォルトを設定して、ポッド全体で必要な制御を実施できます。定義するポリシーは、アプリケーション固有のニーズに対応したものでなければなりません。restricted-psp.yaml サンプル ポリシーをはじめに利用することをおすすめします。

ポッド セキュリティ ポリシーについて詳しくは、PodSecurityPolicy の使用をご覧ください。

NetworkPolicy を使用していて、PodSecurityPolicy の対象となるポッドがある場合は、PodSecurityPolicy を使用する権限を持つ RBAC 役割または ClusterRole を作成します。その後、役割または ClusterRole をポッドのサービス アカウントにバインドします。この場合、ユーザー アカウントに権限を付与するだけでは不十分です。詳細については、ポリシーの承認をご覧ください。

クラスタ構成を監視する

クラスタ構成と定義した設定に矛盾がないか監査してください。

セキュリティの健全性分析を使用すると、この強化ガイドで説明した推奨事項の多くを自動的に確認できるだけでなく、構成の誤りも検出できます。

安全なデフォルト

以降のセクションでは、新しいクラスタにおいて、デフォルトで安全に構成されるオプションについて説明します。既存のクラスタが安全に構成されていることを確認する必要があります。

ノードのメタデータを保護する（デフォルトは 1.12 以降）

CIS GKE ベンチマークの推奨事項: 6.4.1. 従来の Compute Engine インスタンスのメタデータ API が無効であることを確認する、6.4.2. GKE メタデータ サーバーが有効になっていることを確認する

Compute Engine のインスタンス メタデータ サーバーが公開している以前のエンドポイント（/0.1/ と /v1beta1/）は、メタデータ クエリのヘッダーを必要としません。これらの API は、1.12 以降の新しいクラスタではデフォルトで無効になっています。古いバージョンからクラスタをアップグレードした場合は、これらの以前の API を手動で無効にする必要があります。

Kubernetes に対する攻撃の中には、VM のメタデータ サーバーへのアクセスを使用して認証情報を抽出するものがあります。Workload Identity またはメタデータ隠蔽を使用すれば、これらの攻撃はブロックされます。

Compute Engine v1beta1 と v0.1 メタデータ サーバーのエンドポイントはサポート終了となり、停止が予定されています。v1 エンドポイントを使用するすべてのリクエストを必ず更新してください。

詳細は、クラスタ メタデータの保護をご覧ください。

以前のクライアント認証方式を無効にする（デフォルト: 1.12 以降）

CIS GKE ベンチマークの推奨事項: 6.8.1. 静的パスワードを使用する基本認証が無効になっていることを確認する、6.8.2. クライアント証明書を使用する認証が無効になっていることを確認する

Kubernetes API サーバーに対する認証方法は、複数存在します。GKE でサポートされる方法は、サービス アカウントの署名なしトークン、OAuth トークン、x509 クライアント証明書です。GKE では OAuth トークンベースで gcloud での認証を管理し、Kubernetes 構成の設定、アクセス トークンの取得、トークンの更新を行います。

GKE を OAuth と統合する前は、1 回限りの x509 証明書または静的パスワードが唯一の認証方法でしたが、現在は推奨されておらず、無効にする必要があります。これらの方法は、クラスタの侵害に対する攻撃の範囲が広く、GKE バージョン 1.12 以降、デフォルトで無効になっています。以前の認証方法を使用している場合は、無効にすることをおすすめします。GKE バージョン 1.19 以降では、静的パスワードによる認証は非推奨となり、削除されています。

既存のクラスタは OAuth に移動する必要があります。クラスタの外部システムが長期間の認証情報を必要とする場合は、必要な権限を持つ Google サービス アカウントまたは Kubernetes サービス アカウントを作成し、そのキーをエクスポートすることをおすすめします。

既存のクラスタを更新して静的パスワードを削除するには、次のコマンドを実行します。

gcloud container clusters update cluster-name \
  --no-enable-basic-auth

現在、既存のクラスタから発行済みの有効なクライアント証明書を削除する方法はありませんが、RBAC が有効で ABAC が無効ならば証明書に権限はありません。

Cloud Logging を有効のままにする（デフォルト）

CIS GKE ベンチマークの推奨事項: 6.7.1。Stackdriver Kubernetes のロギングとモニタリングが有効になっていることを確認する

運用上のオーバーヘッドを削減し、ログの統合ビューを維持するには、クラスタがデプロイされているすべての場所に一貫性のあるロギング方法を実装します。Anthos クラスタはデフォルトで Cloud Logging と統合されているため、その構成を変えないようにしてください。

すべての GKE クラスタではデフォルトで Kubernetes 監査ロギングが有効になっています。これにより、Kubernetes API サーバーに対する呼び出しの記録が時系列で保持されます。Kubernetes 監査ログのエントリは、不審な API リクエストの調査、統計情報の収集、不要な API 呼び出しに対するモニタリング アラートの作成に役立ちます。

GKE クラスタは Kubernetes Audit Logging を Cloud Audit Logs と Cloud Logging に統合します。必要に応じて、ログは Cloud Logging から独自のログシステムにエクスポートできます。

Kubernetes ウェブ UI（ダッシュボード）を無効のままにする（1.10 以降デフォルト）

CIS GKE ベンチマークの推奨事項: 6.10.1. Kubernetes ウェブ UI が無効になっていることを確認する

GKE での実行時に Kubernetes ウェブ UI（ダッシュボード）を有効にしないでください。

Kubernetes ウェブ UI（ダッシュボード）は、高い特権を持つ Kubernetes サービス アカウントと関連付けられています。Cloud Console にほぼ同じ機能があるため、こうした権限は必要ありません。

Kubernetes ウェブ UI を無効にするには、次のコマンドを実行します。

gcloud container clusters update cluster-name \
    --update-addons=KubernetesDashboard=DISABLED

ABAC を無効のままにする（デフォルトは 1.8 以降）

CIS GKE ベンチマークの推奨事項: 6.8.4. 以前の承認（ABAC）が無効になっていることを確認する

GKE で、属性ベースのアクセス制御（ABAC）を無効にし、代わりに役割ベースのアクセス制御（RBAC）を使用してください。

Kubernetes では、RBAC を使用してリソースに対する権限をクラスタレベルと名前空間レベルで付与します。RBAC では、一連の権限を含むルールを使用して役割を定義できます。RBAC には重要なセキュリティ上の利点があり、現在 Kubernetes で安定しているため、ABAC を無効にしてください。

現状で ABAC に依存している場合は、まず RBAC を使用する場合の前提条件を確認してください。クラスタを古いバージョンからアップグレードして ABAC を使用している場合は、次のようにアクセス制御の構成を更新する必要があります。

gcloud container clusters update cluster-name \
    --no-enable-legacy-authorization

上記の推奨に従って新しいクラスタを作成するには、次のコマンドを実行します。

gcloud container clusters create cluster-name \
    --no-enable-legacy-authorization

次のステップ