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

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

前提条件

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

  • Cloud Service Mesh アンビエント ネットワーキングが有効になっている実行中の GKE クラスタ。
  • サンプル クライアントとサーバーのワークロードがデプロイされたアンビエント ネットワーキングに登録された名前空間（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 全体でデフォルトで拒否のベースラインを確立し、特定のワークロードへのアクセスを選択的に許可する手順は次のとおりです。

  1. アクションが 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 内のワークロードから発信されるアウトバウンド トラフィックは制限されません。

  2. トラフィックを選択的に許可するには、ALLOW ポリシーを作成して適用します。

    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.s3ns.svc.id.goog/ns/ambient-test/sa/client
EOF

    PROJECT_ID は、実際のプロジェクト ID に置き換えます。

    ポリシーの伝播には、コントローラの承認後、最大 3 分かかることがあります。3 分待ってから次の手順に進みます。

  3. クライアントからサーバーへの接続をテストします。ALLOW ポリシーと一致するため、成功します。

    kubectl exec -it deploy/client -n ambient-test -- /bin/curl -fsLS server.ambient-test.svc.cluster.local

  4. サーバーからサーバー自体（または明示的な許可ポリシーのない他のワークロード）への接続をテストします。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 Proxy アクセスログの JSON ペイロードに次のフィールドが含まれます。

  • jsonPayload.error_details: - rbac_access_denied_matched_policy[none] に設定します。

Cloud de Confiance コンソールのログ エクスプローラを使用して、拒否された接続のアクセスログエントリを表示できます。トラフィックが認証され、承認されていることを確認するをご覧ください。

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

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

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