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

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 InterconnectCloud VPN を使用してオンプレミス ネットワークから Google Cloud への接続を構成している場合に適しています。これらを用いれば、企業ネットワークとクラウド VPC を効率的に接続できます。
  • パブリック エンドポイント アクセスが有効、マスター承認済みネットワークが有効(推奨): このオプションにより、定義するソース 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

グループ認証(ベータ版)

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 サービス アカウントと Workload Identity を優先的に使用する

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

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

権限

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

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

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

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

GKE では、最低でもサービス アカウントに monitoring.viewermonitoring.metricWriterlogging.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/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-logging.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 の非公開イメージを使用する場合は、それらのイメージに対するアクセス権も付与する必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Secret 管理

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

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

Secret を管理する方法はいくつかあります。

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

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

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

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

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

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

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

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

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

クラスタ構成をモニタリングする

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

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

安全なデフォルト

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

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

既存のクラスタは 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 監査ログと 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.10 以降)

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

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

Kubernetes では、RBAC を使用してリソースに対する権限をクラスタレベルと Namespace レベルで付与します。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
    

次のステップ