Sicherheits- und Autorisierungsrichtlinien für Ambient Networking

Auf dieser Seite wird beschrieben, wie Sie Autorisierungsrichtlinien für Ambient Networking erstellen.

Vorbereitung

Bevor Sie die Schritte in diesem Dokument ausführen können, müssen die folgenden Bedingungen erfüllt sein:

• Ein laufender GKE-Cluster mit aktiviertem Ambient Networking für Cloud Service Mesh.
• Ein Namespace, der für Ambient Networking registriert ist (z. B. ambient-test), mit bereitgestellten Beispiel-Client- und Serverarbeitslasten.
• Gegenseitiges TLS (mTLS) zwischen den Client- und Serverarbeitslasten mithilfe einer GCPServerTLSPolicy (mit mtlsMode: Strict) und einer GCPClientTLSPolicy aktiviert. Für identitätsbasierte GCPAuthzPolicy-Regeln, die mit CLIENT_CERT_URI_SAN übereinstimmen, ist aktives mTLS erforderlich, um die SPIFFE-Identität des Clients zu extrahieren.

Eine detaillierte Anleitung zur Einrichtung der Umgebung finden Sie unter GKE Ambient Networking vorbereiten.

Standardmäßige Ablehnungsrichtlinie

Standardmäßig lässt die GKE Ambient Authorization Policy API den gesamten Traffic zu, sofern er nicht durch eine Richtlinie eingeschränkt ist. Das entspricht dem Standardverhalten von Kubernetes-NetworkPolicy.

Mit der Aktion DENY_BY_DEFAULT können Sie dieses Standardverhalten ändern. Wenn diese Richtlinie auf einen Namespace angewendet wird, blockiert sie den gesamten Traffic zu Arbeitslasten in diesem Namespace, sofern er nicht explizit durch eine ALLOW-Richtlinie zugelassen wird.

Auf dieser Seite erfahren Sie, wie Sie DENY_BY_DEFAULT in Cloud Service Mesh konfigurieren und verwenden, um eine standardmäßig sichere Umgebung für Ihre Arbeitslasten zu schaffen.

Beschränkungen

Beachten Sie die folgenden Einschränkungen, bevor Sie eine DENY_BY_DEFAULT-Richtlinie anwenden:

• Sie können nur eine DENY_BY_DEFAULT-Richtlinie pro Namespace erstellen.
• Für eine Richtlinie mit der Aktion DENY_BY_DEFAULT können keine Regeln definiert werden.
• Verwenden Sie diese Aktion, um eine Namespace-weite Baseline-matchLabels: {} für alle Pods festzulegen. Sie können DENY_BY_DEFAULT nicht für Pod-spezifische Einschränkungen verwenden.

Standardmäßig ablehnende Autorisierungsrichtlinie einrichten

So legen Sie eine standardmäßige Ablehnungsbaseline für einen Namespace fest und gewähren selektiv Zugriff auf bestimmte Arbeitslasten:

1. Erstellen Sie eine GCPAuthzPolicy mit der Aktion DENY_BY_DEFAULT und wenden Sie sie auf Ihren Namespace an.

   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
   

   Die Ausgabe sieht etwa so aus:

    gcpauthzpolicy.networking.gke.io/deny-by-default-authz created
   

   Diese Richtlinie blockiert standardmäßig den gesamten eingehenden Traffic (Ost-West- und eingehenden Traffic) zu Arbeitslasten im Namespace ambient-test. Ausgehender Traffic, der von Arbeitslasten im Namespace stammt, wird nicht eingeschränkt.

2. Wenn Sie Traffic selektiv zulassen möchten, erstellen Sie eine ALLOW-Richtlinie und wenden Sie sie an:

   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
   

   Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.

   Die Richtlinienweitergabe kann nach der Annahme durch den Controller bis zu drei Minuten dauern. Warten Sie drei Minuten, bevor Sie fortfahren.

3. Testen Sie die Verbindung vom Client zum Server. Er sollte erfolgreich sein, da er der Richtlinie ALLOW entspricht.

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

4. Testen Sie die Verbindung vom Server zu sich selbst (oder zu einer anderen Arbeitslast ohne explizite Zulassungsrichtlinie). Der Vorgang sollte aufgrund der Richtlinie DENY_BY_DEFAULT fehlschlagen.

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

   Die Ausgabe sieht etwa so aus:

   curl: (52) Empty reply from server.
   

Logging

Wenn eine Anfrage von einer Autorisierungsrichtlinie abgelehnt wird, schreibt der Knotenproxy einen Logeintrag in Cloud Logging unter dem Lognamen gke-ambient-node-proxy-accesslog. Der Eintrag enthält das folgende Feld in der JSON-Nutzlast:

• jsonPayload.error_details: - rbac_access_denied_matched_policy[none]

Sie können den Log-Explorer in der Cloud de Confiance Console verwenden, um die Zugriffslogeinträge für abgelehnte Verbindungen aufzurufen:

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

Weitere Informationen finden Sie unter Prüfen, ob Traffic authentifiziert und autorisiert ist.

Sicherheitsrichtlinien für ausgehenden Traffic

Wenn Sie ausgehenden Traffic von Ambient Networking-Arbeitslasten zu externen Endpunkten oder zum Internet prüfen und steuern möchten, können Sie ausgehenden Traffic über Secure Web Proxy (SWP) weiterleiten.

Eine Anleitung zum Konfigurieren von GCPBackend- und GCPEgressPolicy-Ressourcen finden Sie unter Ambient-Egress-Traffic über Secure Web Proxy weiterleiten.