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 Voraussetzungen erfüllt sein:

• Ein aktiver GKE-Cluster mit aktiviertem Cloud Service Mesh Ambient Networking.
• Ein Namespace, der für Ambient Networking registriert ist (z. B. ambient-test), mit bereitgestellten Beispielarbeitslasten für Client und Server.
• Gegenseitiges TLS (mTLS) zwischen den Client- und Server-Workloads mithilfe eines GCPServerTLSPolicy (mit mtlsMode: Strict) und eines GCPClientTLSPolicy aktiviert. Für identitätsbasierte GCPAuthzPolicy-Regeln, die CLIENT_CERT_URI_SAN entsprechen, ist eine aktive mTLS-Authentifizierung erforderlich, um die SPIFFE-Identität des Clients zu extrahieren.

Eine detaillierte Einrichtung der Umgebung finden Sie unter GKE-Umgebungsnetzwerk vorbereiten.

Standardmäßig ablehnende Richtlinie

Standardmäßig lässt die GKE Ambient Authorization Policy API den gesamten Traffic zu, sofern er nicht durch eine Richtlinie eingeschränkt wird. Dies 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, wird der gesamte Traffic zu Arbeitslasten in diesem Namespace blockiert, sofern er nicht explizit durch eine ALLOW-Richtlinie zugelassen wird.

Auf dieser Seite wird beschrieben, wie Sie DENY_BY_DEFAULT in Cloud Service Mesh konfigurieren und verwenden, um einen standardmäßig sicheren Sicherheitsstatus für Ihre Arbeitslasten zu schaffen.

Beschränkungen

Beachten Sie vor dem Anwenden einer DENY_BY_DEFAULT-Richtlinie die folgenden Einschränkungen:

• Sie können nur eine DENY_BY_DEFAULT-Richtlinie pro Namespace erstellen.
• Für eine Richtlinie mit der Aktion DENY_BY_DEFAULT dürfen keine Regeln definiert sein.
• Mit dieser Aktion legen Sie einen Namespace-weiten matchLabels: {} fest, der auf alle Pods ausgerichtet ist. DENY_BY_DEFAULT kann nicht für Einschränkungen pro Pod verwendet werden.

Standardmäßig ablehnende Autorisierungsrichtlinie einrichten

So legen Sie eine Standard-Ablehnungsrichtlinie für einen Namespace fest und erlauben selektiv den Zugriff auf bestimmte Arbeitslasten:

1. Erstellen Sie ein GCPAuthzPolicy mit der auf DENY_BY_DEFAULT festgelegten Aktion und wenden Sie es 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 eingehend) zu Arbeitslasten im Namespace ambient-test. Der ausgehende Traffic von Arbeitslasten im Namespace 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.

   Es kann bis zu drei Minuten dauern, bis die Richtlinie nach der Bestätigung durch den Controller weitergegeben wird. Warten Sie drei Minuten, bevor Sie fortfahren.

3. Verbindung vom Client zum Server testen Der Vorgang sollte erfolgreich sein, da er der ALLOW-Richtlinie 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 der Autorisierungsrichtlinie abgelehnt wird, enthalten die GKE Ambient Proxy-Zugriffsprotokolle die folgenden Felder in der JSON-Nutzlast:

• jsonPayload.error_details: Auf - rbac_access_denied_matched_policy[none] festlegen

Sie können den Log-Explorer in der Cloud de Confiance Console verwenden, um die Zugriffslogeinträge für abgelehnte Verbindungen aufzurufen. Weitere Informationen finden Sie unter Authentifizierung und Autorisierung von Traffic überprüfen.

Sicherheitsrichtlinien für ausgehenden Traffic

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

Eine Anleitung zum Konfigurieren von GCPBackend- und GCPEgressRouting-Ressourcen finden Sie unter Ausgehenden Ambient-Traffic über den sicheren Webproxy weiterleiten.