Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

アンビエントネットワーキングのセキュリティポリシーと認可ポリシー

Autopilot Standard

このページでは、アンビエントネットワーキングで認可ポリシーを作成する方法について説明します。

前提条件

このドキュメントの手順を完了するには、次の条件を満たしている必要があります。

Cloud Service Mesh アンビエントネットワーキングが有効になっている、実行中の GKE クラスタ。
サンプルクライアントとサーバーワークロードがデプロイされたアンビエントネットワーキングに登録された Namespace（ambient-test など）。
GCPServerTLSPolicy（mtlsMode: Strict を含む）と GCPClientTLSPolicy を使用して、クライアントとサーバーのワークロード間で相互 TLS（mTLS）を有効にします。CLIENT_CERT_URI_SAN と一致する ID ベースの GCPAuthzPolicy ルールでは、クライアントの SPIFFE ID を抽出するためにアクティブな mTLS が必要です。

環境設定の詳細については、GKE アンビエントネットワーキングを準備するをご覧ください。

デフォルトで拒否のポリシー

デフォルトでは、GKE Ambient Authorization Policy API は、ポリシーで制限されていない限り、すべてのトラフィックを許可します。これは、標準の Kubernetes NetworkPolicy の動作と一致します。

DENY_BY_DEFAULT アクションを使用すると、このデフォルトの動作を変更できます。Namespace に適用すると、このポリシーは、ALLOW ポリシーで明示的に許可されていない限り、その Namespace 内のワークロードへのすべてのトラフィックをブロックします。

このページでは、Cloud Service Mesh で DENY_BY_DEFAULT を構成して使用し、ワークロードのデフォルトで安全な状態を確立する方法について説明します。

制限事項

DENY_BY_DEFAULT ポリシーを適用する前に、次の制限事項に注意してください。

Namespace ごとに作成できる DENY_BY_DEFAULT ポリシーは 1 つのみです。
DENY_BY_DEFAULT アクションを含むポリシーには、ルールを定義できません。
このアクションを使用して、すべての Pod をターゲットとする Namespace 全体のベースライン matchLabels: {} を設定します。Pod ごとの制限に DENY_BY_DEFAULT を使用することはできません。

デフォルトで拒否の認可ポリシーを設定する

Namespace 全体でデフォルトで拒否のベースラインを確立し、特定のワークロードへのアクセスを選択的に許可する手順は次のとおりです。

アクションが DENY_BY_DEFAULT に設定された GCPAuthzPolicy を作成して、Namespace に適用します。
```
cat <<EOF > deny-by-default-policy.yaml && kubectl apply -f deny-by-default-policy.yaml
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: deny-by-default-authz
  namespace: ambient-test
spec:
  action: DENY_BY_DEFAULT
  enforcementLevel: L4
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels: {}
EOF
```
出力は次のようになります。
```
 gcpauthzpolicy.networking.gke.io/deny-by-default-authz created
```
このポリシーは、デフォルトで ambient-test Namespace 内のワークロードへのすべてのインバウンド（East-West と上り（内向き））トラフィックをブロックします。Namespace 内のワークロードから発信されるアウトバウンドトラフィックは制限されません。
トラフィックを選択的に許可するには、ALLOW ポリシーを作成して適用します。

重要: CLIENT_CERT_URI_SAN に厳密に一致する GCPAuthzPolicy ルールでは、mTLS（Strict モードの GCPServerTLSPolicy と GCPClientTLSPolicy）を事前に構成する必要があります。mTLS がアクティブでない場合、プロキシはクライアントの SPIFFE ID を抽出できないため、SPIFFE ベースの ALLOW ルールが一致せず、すべてのトラフィックが DENY_BY_DEFAULT によってドロップされます。
```
cat <<EOF > allow-policy.yaml && kubectl apply -f allow-policy.yaml
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: allow-client-to-server
  namespace: ambient-test
spec:
  action: ALLOW
  enforcementLevel: L4
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: server
  rules:
  - from:
      sources:
      - principals:
        - principalSelector: CLIENT_CERT_URI_SAN
          principal:
            type: Exact
            value: spiffe://PROJECT_ID.svc.id.goog/ns/ambient-test/sa/client
EOF
```
PROJECT_ID は、実際のプロジェクト ID に置き換えます。

ポリシーの反映は、コントローラが承認してから最大 3 分かかることがあります。3 分待ってから次の手順に進みます。
クライアントからサーバーへの接続をテストします。ALLOW ポリシーと一致するため、成功するはずです。
```
kubectl exec -it deploy/client -n ambient-test -- /bin/curl -fsLS server.ambient-test.svc.cluster.local
```
サーバーからサーバー自体（または明示的な許可ポリシーのない他のワークロード）への接続をテストします。DENY_BY_DEFAULT ポリシーが原因で失敗するはずです。
```
kubectl exec -it deploy/server -n ambient-test -- /bin/curl -fsLS server.ambient-test.svc.cluster.local
```
出力は次のようになります。
```
curl: (52) Empty reply from server.
```

ロギング

認可ポリシーによってリクエストが拒否されると、ノードプロキシは gke-ambient-node-proxy-accesslog ログ名で Cloud Logging にアクセスログエントリを書き込みます。このエントリには、JSON ペイロードに次のフィールドが含まれています。

jsonPayload.error_details: - rbac_access_denied_matched_policy[none]

Google Cloud コンソールのログエクスプローラを使用して、拒否された接続のアクセスログエントリを表示できます。

resource.type="k8s_container"
logName="projects/PROJECT_ID/logs/gke-ambient-node-proxy-accesslog"
jsonPayload.error_details=~"rbac_access_denied"

詳細については、トラフィックが認証され、認可されていることを確認するをご覧ください。

下り（外向き）セキュリティポリシー

アンビエントネットワーキングワークロードから外部エンドポイントまたはインターネットへのアウトバウンドトラフィックを検査して制御するには、アウトバウンドトラフィックを Secure Web Proxy（SWP）経由でルーティングします。

GCPBackend リソースと GCPEgressPolicy リソースの構成手順については、Secure Web Proxy を介してアンビエント下り（外向き）トラフィックを転送するをご覧ください。