チュートリアル: GKE Enterprise を保護する


GKE Enterprise は、安全なサービスの構築と配信のために一貫性のあるプラットフォームを提供します。セキュリティの問題に対する多層防御を提供するため、このプラットフォームには個別および相互に機能するセキュリティ機能があらゆるレベルで組み込まれています。このチュートリアルでは、Google Cloud で Anthos のサンプル デプロイを使用して、GKE Enterprise の強力なセキュリティ機能の一部を紹介します。この Anthos のサンプル デプロイは、GKE クラスタ、サービス メッシュ、複数のマイクロサービスからなる Bank of GKE Enterprise アプリケーションを実際の GKE Enterprise ハンズオン環境にデプロイします。

目標

このチュートリアルでは、次のタスクを通じて GKE Enterprise のセキュリティ機能の一部を紹介します。

  • エンドツーエンドの安全な通信を確保するため、Config Sync を使用してサービス メッシュ内に相互 TLS(mTLS)を適用します。

  • Policy Controller を使用して、特権コンテナを持つ Pod が誤ってデプロイされないようにするセキュリティ ガードレールを設定します。

費用

サブスクリプションを購入している場合を除き、Bank of Anthos アプリケーションをデプロイすると、料金ページに記載されている Google Cloud の GKE Enterprise の従量課金制が適用されます。

また、Compute Engine VM やロードバランサの費用など、Bank of Anthos アプリケーションの実行中に発生した他の Google Cloud の費用もお客様の負担となります。

追加費用の発生を避けるため、チュートリアルを終了した後、またはデプロイメントを試した後に、クリーンアップすることをおすすめします。

始める前に

このチュートリアルは、Explore Anthos チュートリアルのフォローアップです。このチュートリアルを始める前に、このページの指示に従ってプロジェクトを設定し、Anthos のサンプル デプロイをインストールします。

Cloud Shell 環境の設定

このチュートリアルでは、Cloud Shell コマンドラインとエディタを使用してクラスタの構成を変更します。

チュートリアルのシェル環境を初期化するため、Anthos のサンプル デプロイには、次の処理を行うスクリプトが用意されています。

  • デプロイへの変更をインタラクティブに操作し、検証するため、不足しているコマンドライン ツールをインストールします。

  • anthos-sample-cluster1 の Kubernetes コンテキストを設定する

  • 構成の変更をクラスタに同期するために Config Sync が使用するリポジトリのクローンを作成します。commit してアップストリームのリポジトリに push した変更は、Config Sync によってインフラストラクチャに同期されます。これは、インフラストラクチャに変更を適用する場合に推奨されるベスト プラクティスです。

環境を設定するには:

  1. アクティブな Cloud Shell セッションがあることを確認してください。チュートリアル プロジェクトの Google Cloud コンソールで「Cloud Shell をアクティブにする」アイコン Shell をアクティブにするボタン をクリックすると、Cloud Shell を起動できます。

  2. 作業に使用するディレクトリを作成します。

    mkdir tutorial
    cd tutorial
    
  3. 初期化スクリプトをダウンロードします。

    curl -sLO https://github.com/GoogleCloudPlatform/anthos-sample-deployment/releases/latest/download/init-anthos-sample-deployment.env
    
  4. 初期化スクリプトを Cloud Shell 環境に取り込みます。

    source init-anthos-sample-deployment.env
    

    出力:

    /google/google-cloud-sdk/bin/gcloud
    /google/google-cloud-sdk/bin/kubectl
    Your active configuration is: [cloudshell-13605]
    export PROJECT as anthos-launch-demo-1
    export KUBECONFIG as ~/.kube/anthos-launch-demo-1.anthos-trial-gcp.config
    Fetching cluster endpoint and auth data.
    kubeconfig entry generated for anthos-sample-cluster1.
    Copying gs://config-management-release/released/latest/linux_amd64/nomos...
    \ [1 files][ 40.9 MiB/ 40.9 MiB]
    Operation completed over 1 objects/40.9 MiB.
    Installed nomos into ~/bin.
    Cloned ACM config repo: ./anthos-sample-deployment-config-repo
    
  5. ディレクトリを構成リポジトリに変更し、このチュートリアルの以降の部分の作業ディレクトリとして使用します。

    cd anthos-sample-deployment-config-repo
    

サービス メッシュでの mTLS の適用

グローバルな事業展開を想定している組織の CIO には、すべてのユーザーデータを転送中に暗号化して機密データを保護し、リージョン データのプライバシーと暗号化に関する法律を遵守することが求められています。

現在のトラフィックの状況を確認してみましょう。

  1. Anthos のサンプル デプロイをデプロイしたプロジェクトの Cloud Service Mesh ページに移動します。

    [Cloud Service Mesh] ページに移動

  2. サービスリストの [transactionhistory] をクリックします。GKE Enterprise を試すで説明したように、サービスの詳細ページには、このサービスで利用可能なすべてのテレメトリーが表示されます。

  3. [transactionhistory] ページの [ナビゲーション] メニューで、[連携サービス] を選択します。サービスに対するインバウンド接続とアウトバウンド接続の両方を確認できます。開錠された鍵アイコンは、このポートで相互 TLS(mTLS)を使用していないトラフィックが確認されたことを意味します。

mTLS は、2 つのサービス間の双方向でトラフィックの安全性を確保するためのセキュリティ プロトコルです。各サービスは、認証済みサービスから暗号化されたトラフィックのみを受け入れます。ご覧のとおり、Cloud Service Mesh はメッシュ内で暗号化されていないトラフィックがあることを明確に示しています。Cloud Service Mesh では、暗号化されていないトラフィックで平文と mTLS が混在しているか、平文のみであるかが色分けされます。前者の場合はオレンジ、後者の場合は赤色で表示されます。

GKE Enterprise を使用すれば、わずか数ステップでコンプライアンスに対応できます。この状況に対処するには、ソースコード レベルで変更を行い、アプリケーションをビルドし直して再デプロイするのではなく、Config Sync を使用して構成から新しい暗号化ポリシーを宣言的に適用し、一元管理されている Git リポジトリから新しい構成を自動的にデプロイできます。

このセクションでは、次のことを行います。

  1. サービスが mTLS を介して暗号化された通信を使用するように、Git リポジトリのポリシー構成を調整します。

  2. Config Sync を使用して、リポジトリからポリシー変更を自動的に取得し、Cloud Service Mesh ポリシーを調整します。

  3. リポジトリと同期するように構成されているクラスタでポリシーの変更が行われていることを確認します。

Config Sync の設定を確認する

  1. nomos コマンドは、Config Management Operator を操作して、ローカルマシンまたは Cloud Shell から他の有用な Config Sync タスクを実行できるコマンドライン ツールです。Config Sync がクラスタに適切にインストールされ、構成されていることを確認するには、nomos status を実行します。

    nomos status
    

    出力:

    Connecting to clusters...
    Current   Context                  Sync Status  Last Synced Token   Sync Branch   Resource Status
    -------   -------                  -----------  -----------------   -----------   ---------------
    *         anthos-sample-cluster1   SYNCED       abef0b01            master        Healthy
    

    この出力により、クラスタが構成リポジトリのマスター ブランチと同期するように Config Sync が構成されていることを確認できます。最初の列のアスタリスクは、現在のコンテキストが anthos-sample-cluster1 に設定されていることを示します。これが表示されない場合は、現在のコンテキストを anthos-sample-cluster1 に切り替えます。

    kubectl config use-context anthos-sample-cluster1
    

    出力:

    Switched to context "anthos-sample-cluster1".
    
  2. master ブランチにいることを確認します。

    git checkout master
    

    出力:

    Already on 'master'
    Your branch is up to date with 'origin/master'.
    
  3. アップストリームの構成リポジトリを確認します。

    git remote -v
    

    出力:

    origin  https://source.developers.google.com/.../anthos-sample-deployment-config-repo (fetch)
    origin  https://source.developers.google.com/.../anthos-sample-deployment-config-repo (push)
    
  4. anthos-sample-deployment-config-repo ディレクトリにいることを確認し、次のコマンドを実行して Git の設定を確認します。このヘルパー関数は、初期化スクリプトによって環境に組み込まれ、git config コマンドを実行して git config の既存の user.emailuser.name の値をチェックします。これらの値が構成されていない場合、この関数は現在アクティブな Google Cloud アカウントに基づいてリポジトリ レベルでデフォルト値を設定します。

    init_git
    

    出力(例):

    Configured local git user.email to user@example.com
    Configured local git user.name to user
    

これで、ポリシーの変更をリポジトリに commit する準備が整いました。これらの commit をアップストリーム リポジトリ(送信元)に push すると、Config Sync がこれらの変更を管理対象のクラスタに適用します。

すべてのサービス トラフィックを暗号化するポリシーを更新する

Cloud Service Mesh の構成は、YAML ファイルを使用して宣言的に指定されます。すべてのサービス トラフィックを暗号化するには、サービスが受け入れるトラフィックのタイプを指定する YAML と、サービスが特定の宛先に送信するトラフィックのタイプを指定する YAML の両方を変更する必要があります。

  1. 確認する必要がある最初の YAML ファイルは namespaces/istio-system/peer-authentication.yaml です。これは、メッシュ内のすべてのサービスがデフォルトで受け入れるトラフィックのタイプを指定する、メッシュレベルの認証ポリシーです。

    cat namespaces/istio-system/peer-authentication.yaml
    

    出力:

    apiVersion: "security.istio.io/v1beta1"
    kind: "PeerAuthentication"
    metadata:
      name: "default"
      namespace: "istio-system"
    spec:
      mtls:
        mode: PERMISSIVE
    

    ご覧のように、PeerAuthentication mTLS モードは PERMISSIVE です。これは、サービスが平文の HTTP と mTLS トラフィックの両方を受け入れることを意味します。

  2. mTLS モードを STRICT に設定して、サービス間で暗号化された通信のみを許可するように namespaces/istio-system/peer-authentication.yaml を変更します。

    cat <<EOF> namespaces/istio-system/peer-authentication.yaml
    apiVersion: "security.istio.io/v1beta1"
    kind: "PeerAuthentication"
    metadata:
      name: "default"
      namespace: "istio-system"
    spec:
      mtls:
        mode: STRICT
    EOF
    
  3. 次に、namespaces/istio-system/destination-rule.yaml宛先ルールを確認します。これは、トラフィックが暗号化されているかどうかなど、指定された宛先にトラフィックを送信するルールを指定します。TLSmodeDISABLE です。つまり、トラフィックは一致するすべてのホストに平文で送信されます。

    cat namespaces/istio-system/destination-rule.yaml
    

    出力:

    apiVersion: networking.istio.io/v1alpha3
    kind: DestinationRule
    metadata:
      annotations:
        meshsecurityinsights.googleapis.com/generated: "1561996419000000000"
      name: default
      namespace: istio-system
    spec:
      host: '*.local'
      trafficPolicy:
        tls:
          mode: DISABLE
    
  4. namespaces/istio-system/destination-rule.yaml を変更して、Istio で TLS モード ISTIO_MUTUAL を使用して、クラスタ内で一致するすべてのホストに TLS を有効にするトラフィック ポリシーを設定します。

    cat <<EOF> namespaces/istio-system/destination-rule.yaml
    apiVersion: networking.istio.io/v1alpha3
    kind: DestinationRule
    metadata:
      annotations:
        meshsecurityinsights.googleapis.com/generated: "1561996419000000000"
      name: default
      namespace: istio-system
    spec:
      host: '*.local'
      trafficPolicy:
        tls:
          mode: ISTIO_MUTUAL
    EOF
    

リポジトリに変更を push する

構成変更を push する準備はほぼ整っていましたが、最後に更新を commit する前に、いくつか確認することをおすすめします。

  1. nomos vet を実行して、構成が有効であることを確認します。

    nomos vet
    

    出力がない場合、検証エラーがなかったことを示します。

  2. 変更を push するとすぐに、Config Sync がその変更を選択してシステムに適用します。予期しない結果を回避するため、変更を行った後に、構成の現在のライブ状態が変更されていないかどうかを確認することをおすすめします。kubectl を使用して、クラスタで mTLS が無効になっていることが destinationrule に反映されていることを確認します。

    kubectl get destinationrule default -n istio-system -o yaml
    

    出力:

    apiVersion: networking.istio.io/v1alpha3
    kind: DestinationRule
    ...
    spec:
      host: '*.local'
      trafficPolicy:
        tls:
          mode: DISABLE
    
  3. 変更をアップストリーム リポジトリに commit して push します。次のコマンドは、init スクリプトによって環境に取り込まれた watchmtls というヘルパー関数を使用します。このヘルパー関数は、nomos status と、すでに試した kubectl コマンドを組み合わせて使用します。ユーザーが Ctrl+C を押して終了させるまで、変更がないかクラスタを監視します。変更がクラスタに適用されて同期されるまで画面を監視してください。

    git commit -am "enable mtls"
    git push origin master && watchmtls
    

    この変更は、GKE Enterprise の [Cloud Service Mesh] ページにも反映されます。

    [Cloud Service Mesh] ページに移動

    開錠された赤い鍵のアイコンが変更されているはずです。1 時間前に確認した際は、デフォルトで mTLS と平文の組み合わせであったため、鍵アイコンは緑色(完全に暗号化されたトラフィック)ではなく、オレンジ色(混合トラフィック)で表示されていました。1 時間後に再度確認すると、すべてのサービス トラフィックが正常に暗号化されたことを示す緑色の鍵アイコンが表示されます。

Policy Controller を使用してガードレールを設定する

セキュリティ チームは、特権コンテナ(root アクセス権を持つコンテナ)を持つ Pod の実行時に発生する可能性のあるルート攻撃を懸念しています。現在の構成では特権コンテナはデプロイされませんが、パフォーマンスの低下や、顧客データを侵害する恐れのある様々な脅威に対して備える必要があります。

チームの努力にかかわらず、継続的デリバリー プロセスの今後の構成更新により、意図せずにルート攻撃を受けるリスクが高まるおそれがあります。この危険から保護するためのセキュリティ ガードレールを設定します。

ガードレールを適用する

ガードレールは、環境を保護するポリシーを自動的に適用するための管理機能です。Policy Controller は、ネイティブの Kubernetes オブジェクトでは対応できないカスタムルールの定義と適用のサポートをしています。Policy Controller は、組織固有のセキュリティ、法令遵守、ガバナンス要件に対応するためにユーザーが適用したガードレールを確認、監査、施行します。

Policy Controller を使用する

Policy Controller は、Gatekeeper というオープンソース ポリシー エンジン上に構築されています。これは、クラスタ内のリソースの作成、更新、削除が行われるたびに、ポリシーを適用するために使用されます。これらのポリシーは、Policy Controller テンプレート ライブラリや Gatekeeper 制約テンプレートなどの制約を使用して定義されます。

Google Cloud 上の Anthos のサンプル デプロイには、すでに Policy Controller がインストールされており、Policy Controller テンプレート ライブラリも有効になっています。これは、ライブラリの特権コンテナに対する既存の制約を使用して、ガードレールを実装するときに利用できます。

特権コンテナにポリシーの制約を適用する

セキュリティ チームの懸念に対処するため、K8sPSPPrivilegedContainer 制約を適用します。この制約により、特権付きコンテナによる Pod の実行は拒否されます。

  1. Cloud Shell ターミナルで、次のようにライブラリ制約のテキストを使用して新しい constraint.yaml ファイルを作成します。

    cat <<EOF> ~/tutorial/anthos-sample-deployment-config-repo/cluster/constraint.yaml
    apiVersion: constraints.gatekeeper.sh/v1beta1
    kind: K8sPSPPrivilegedContainer
    metadata:
      name: psp-privileged-container
    spec:
      match:
        kinds:
          - apiGroups: [""]
            kinds: ["Pod"]
        excludedNamespaces: ["kube-system"]
    EOF
    
  2. nomos vet を使用して、更新された構成が適用前に有効になっていることを確認します。

    nomos vet
    

    エラーがなければ、このコマンドは何も返しません。

  3. 変更を commit して push し、ポリシーを適用します。nomos status コマンドを watch コマンドとともに使用すると、変更がクラスタに適用されたことを確認できます。完了したら、Ctrl+C キーを押して watch コマンドを終了します。

    git add .
    git commit -m "add policy constraint for privileged containers"
    git push && watch nomos status
    

    出力:

    Connecting to clusters...
    Current   Context                  Sync Status  Last Synced Token   Sync Branch   Resource Status
    -------   -------                  -----------  -----------------   -----------   ---------------
    *         anthos-sample-cluster1   SYNCED       f2898e92            master        Healthy
    

ポリシーをテストする

ポリシーを適用したら、特権コンテナを持つ Pod を実行してみることでポリシーをテストできます。

  1. Cloud Shell ターミナルで次のコマンドを使用して、チュートリアル ディレクトリに、このサンプルの仕様を含む新しいファイル nginx-privileged.yaml を作成します。

    cat <<EOF> ~/tutorial/nginx-privileged.yaml
    apiVersion: v1
    kind: Pod
    metadata:
      name: nginx-privileged-disallowed
      labels:
        app: nginx-privileged
    spec:
      containers:
      - name: nginx
        image: nginx
        securityContext:
          privileged: true
    EOF
    
  2. kubectl apply で Pod の起動を試みます。

    kubectl apply -f ~/tutorial/nginx-privileged.yaml
    

    出力:

    Error from server ([denied by psp-privileged-container] Privileged container is not allowed: nginx, securityContext: {"privileged": true}): error when creating "~/nginx-privileged.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by psp-privileged-container] Privileged container is not allowed: nginx, security
    Context: {"privileged": true}
    

    このエラーは、Kubernetes 環境をモニタリングする Gatekeeper アドミッション コントローラが新しいポリシーを適用したことを示しています。Pod の仕様に特権コンテナが存在するため、Pod は実行されませんでした。

Policy Controller を使用してガードレールの設定に適用できる、バージョン管理ポリシーのコンセプトは強力なものです。これは、クラスタのガバナンスを標準化、統合、一元化し、デプロイ後の環境のアクティブなモニタリングを介してポリシーを適用します。

Gatekeeper リポジトリでは、このほかにも環境のガードレールとして使用できるポリシーを確認できます。

デプロイをさらに試す

このチュートリアルでは一部の GKE Enterprise セキュリティ機能について説明してきましたが、GKE Enterprise のデプロイでは、これ以外にも多くの機能を利用できます。次のセクションでクリーンアップ手順を行う前に、別のチュートリアルを試すか、Google Cloud で Anthos のサンプル デプロイを引き続き試すこともできます。

クリーンアップ

Bank of Anthos アプリケーションの機能を詳しく確認できたら、Google Cloud で作成したリソースをクリーンアップして、今後料金が発生しないようにします。

  • オプション 1。プロジェクトを削除できます。ただし、プロジェクトを保持する場合は、オプション 2 を使用してデプロイを削除できます。

  • オプション 2。現在のプロジェクトを保持する場合は、terraform destroy を使用してサンプル アプリケーションとクラスタを削除します。

プロジェクトを削除する(オプション 1)

課金が発生しないようにする最も簡単な方法は、このチュートリアル用に作成したプロジェクトを削除することです。

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

デプロイを削除する(オプション 2)

この方法では、Bank of Anthos アプリケーションとクラスタは削除されますが、プロジェクトは削除されません。Cloud Shell で次のコマンドを実行します。

  1. インストール スクリプトをホストするディレクトリに移動します。

    cd bank-of-anthos/iac/tf-anthos-gke
    
  2. サンプルとクラスタを削除します。

    terraform destroy
    
  3. プロンプトが表示されたら、プロジェクト ID を入力します。

再デプロイを計画している場合は、始める前にの説明に従って、すべての要件を満たしていることを確認します。

次のステップ

GKE Enterprise のドキュメントには、他にもさまざまな機能が説明されています。

その他のチュートリアルを試す

GKE Enterprise の詳細