チュートリアル: 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 によってインフラストラクチャに同期されます。これは、インフラストラクチャに変更を適用する場合に推奨されるベストプラクティスです。

環境を設定するには:

アクティブな Cloud Shell セッションがあることを確認してください。チュートリアルプロジェクトの Google Cloud コンソールで「Cloud Shell をアクティブにする」アイコンをクリックすると、Cloud Shell を起動できます。
作業に使用するディレクトリを作成します。
```
mkdir tutorial
cd tutorial
```

初期化スクリプトをダウンロードします。

curl -sLO https://github.com/GoogleCloudPlatform/anthos-sample-deployment/releases/latest/download/init-anthos-sample-deployment.env

初期化スクリプトを 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

ディレクトリを構成リポジトリに変更し、このチュートリアルの以降の部分の作業ディレクトリとして使用します。
```
cd anthos-sample-deployment-config-repo
```

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

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

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

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

[Cloud Service Mesh] ページに移動
サービスリストの [transactionhistory] をクリックします。GKE Enterprise を試すで説明したように、サービスの詳細ページには、このサービスで利用可能なすべてのテレメトリーが表示されます。
[transactionhistory] ページの [ナビゲーション] メニューで、[連携サービス] を選択します。サービスに対するインバウンド接続とアウトバウンド接続の両方を確認できます。開錠された鍵アイコンは、このポートで相互 TLS（mTLS）を使用していないトラフィックが確認されたことを意味します。

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

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

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

サービスが mTLS を介して暗号化された通信を使用するように、Git リポジトリのポリシー構成を調整します。
Config Sync を使用して、リポジトリからポリシー変更を自動的に取得し、Cloud Service Mesh ポリシーを調整します。
リポジトリと同期するように構成されているクラスタでポリシーの変更が行われていることを確認します。

Config Sync の設定を確認する

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".
```

master ブランチにいることを確認します。

git checkout master

出力:

Already on 'master'
Your branch is up to date with 'origin/master'.

アップストリームの構成リポジトリを確認します。

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)

anthos-sample-deployment-config-repo ディレクトリにいることを確認し、次のコマンドを実行して Git の設定を確認します。このヘルパー関数は、初期化スクリプトによって環境に組み込まれ、git config コマンドを実行して git config の既存の user.email と user.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 の両方を変更する必要があります。

確認する必要がある最初の 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 トラフィックの両方を受け入れることを意味します。

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

次に、namespaces/istio-system/destination-rule.yaml の宛先ルールを確認します。これは、トラフィックが暗号化されているかどうかなど、指定された宛先にトラフィックを送信するルールを指定します。TLSmode は DISABLE です。つまり、トラフィックは一致するすべてのホストに平文で送信されます。
```
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
```

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 する前に、いくつか確認することをおすすめします。

nomos vet を実行して、構成が有効であることを確認します。
```
nomos vet
```
出力がない場合、検証エラーがなかったことを示します。
変更を 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
```
変更をアップストリームリポジトリに 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 の実行は拒否されます。

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

nomos vet を使用して、更新された構成が適用前に有効になっていることを確認します。
```
nomos vet
```
エラーがなければ、このコマンドは何も返しません。

変更を 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 を実行してみることでポリシーをテストできます。

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

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）

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

注意: プロジェクトを削除すると、次のような影響があります。

プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
カスタムプロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタムプロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

複数のアーキテクチャ、チュートリアル、クイックスタートを実施する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て上限を超えないようにすることができます。

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

デプロイを削除する（オプション 2）

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

インストールスクリプトをホストするディレクトリに移動します。
```
cd bank-of-anthos/iac/tf-anthos-gke
```
サンプルとクラスタを削除します。
```
terraform destroy
```
プロンプトが表示されたら、プロジェクト ID を入力します。

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

次のステップ

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

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

GKE Enterprise でサービスを管理するで、Anthos サンプルデプロイによるサービスの管理について学習する。
Google Cloud に関するリファレンスアーキテクチャ、図、ベストプラクティスを確認する。Cloud アーキテクチャセンターをご覧ください。

GKE Enterprise の詳細

技術概要で GKE の詳細を確認する。
設定ガイドで、本番環境で GKE Enterprise を設定する方法を学習する。
Cloud Service Mesh のドキュメントで、Cloud Service Mesh をさらに活用する方法を確認する。
Policy Controller の詳細について、Policy Controller ガイドで確認する。
宣言型で一元管理された構成とポリシー管理の詳細について、Config Sync のドキュメントと Policy Controller のドキュメントで確認する。