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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • マスター認証済みネットワークのホワイトリストに登録された CIDR。
  • クラスタの VPC 内のノード。
  • Google がお客様のマスターを管理するために本番環境で実行する内部ジョブ。

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

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

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

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

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

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

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

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

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

シールドされた 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 を有効にする（ベータ版）

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

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

権限

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

各 GKE ノードには、Cloud Identity and Access Management（Cloud 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 の役割が必要です。詳細については、モニタリングの役割とロギングの役割をご覧ください。

次のコマンドは、GKE を操作するために必要な最小限の権限を持つ Cloud 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

Config Connector

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

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

    apiVersion: iam.cnrm.cloud.google.com/v1alpha1
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/v1alpha1
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/v1alpha1
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-logging.yaml

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

    apiVersion: iam.cnrm.cloud.google.com/v1alpha1
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 の非公開イメージを使用する場合は、それらのイメージに対するアクセス権も付与する必要があります。

gcloud

gcloud projects add-iam-policy-binding [PROJECT_ID] \
--member "serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com" \
--role roles/storage.objectViewer

Config Connector

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

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

apiVersion: iam.cnrm.cloud.google.com/v1alpha1
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/v1alpha1
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 を使用してワークロードからサービス アカウントへのアクセスを許可します。

クラスタ ディスカバリの RBAC 権限を制限する

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

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

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

  • 設定済みの IP 範囲へのアクセスを制限するように承認済みネットワークを構成する
  • VPC へのアクセスを制限する限定公開クラスタを設定する
  • デフォルトの system:discovery と system:basic-user の ClusterRoleBindings サブジェクトを選びます。たとえば、Kubernetes のデフォルトでは system:(un)authenticated へのアクセスが許可されてしまうため、system:serviceaccounts グループとその他の既知のユーザーとグループへのアクセスのみを許可することように配慮します。

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

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

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

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

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

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

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

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

  1. Istio を使用します。GKE に Istio をインストールするを参照してください。負荷分散、サービス認証、スロットリング、割り当て、指標などに関心がある場合は選択します。
  2. Kubernetes ネットワーク ポリシーを使用します。クラスタ ネットワーク ポリシーの設定を参照してくください。Kubernetes で公開されている基本的なアクセス制御機能をお探しの場合は、これを選択します。Kubernetes のドキュメントには簡単な nginx デプロイに関するすぐれたチュートリアルがあります。

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

シークレット管理

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

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

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

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

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

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

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

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

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

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

クラスタ構成を監視する

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

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

安全なデフォルト

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

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

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

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

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

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

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

Kubernetes API サーバーに対する認証方法は、複数存在します。

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

GKE と Google OAuth の統合以前は、事前にプロビジョニングされた x509 証明書または静的パスワードのみを認証に利用できましたが、これらの方法は現在は推奨されておらず、1.12 以降の新しいクラスタではデフォルトで無効になっています。

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

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

gcloud container clusters update [CLUSTER_NAME] \
  --no-enable-basic-auth

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

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

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

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

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

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

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

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

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

gcloud container clusters update [CLUSTER_NAME] \
    --update-addons=KubernetesDashboard=DISABLED

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

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

次のステップ