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


GKE Enterprise は、安全なサービスの構築と配信のために一貫性のあるプラットフォームを提供します。このプラットフォームはセキュリティの問題に対する多層防御を提供するために、個別および相互に機能するあらゆるレベルで組み込まれたセキュリティ機能を備えています。このチュートリアルでは、Google Cloud で GKE Enterprise のサンプル デプロイを使用して Anthos の強力なセキュリティ機能の一部を紹介します。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 の費用もお客様の負担となります。

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

準備

このチュートリアルは、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 のサンプル デプロイをデプロイしたプロジェクトの Anthos Service Mesh ページに移動します。

    Anthos Service Mesh のページに移動

  2. サービスリストの [transactionhistory] をクリックします。GKE Enterprise の使い方に見たとおり、サービスの詳細ページには、このサービスで利用可能なすべてのテレメトリーが表示されます。

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

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

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

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

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

  2. Config Sync を使用して、リポジトリからポリシー変更を自動的に取得し、Anthos 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 によって、これらの変更が管理するように構成したクラスタに適用されます。

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

Anthos 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 の [Anthos Service Mesh] ページにも反映されていることが確認できます。

    [Anthos Service Mesh] ページに移動

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

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

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

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

ガードレールの適用

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

Policy Controller を使用する

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

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

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

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

  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. Google Cloud コンソールで、[リソースの管理] ページに移動します。

    [リソースの管理] に移動

  2. プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
  3. ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

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

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

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

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

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

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

次のステップ

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

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

GKE Enterprise の詳細