Sicherheits- und Autorisierungsrichtlinien für Ambient Networking

Auf dieser Seite erfahren Sie, 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 von Cloud Service Mesh.
  • 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 Serverarbeitslasten mithilfe einer GCPServerTLSPolicy (mit mtlsMode: Strict) und einer GCPClientTLSPolicy aktiviert. Identitätsbasierte GCPAuthzPolicy-Regeln, die mit CLIENT_CERT_URI_SAN übereinstimmen, erfordern aktives mTLS, um die SPIFFE-Identität des Clients zu extrahieren.

Eine detaillierte Einrichtung der Umgebung finden Sie unter GKE-Ambient-Netzwerk 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 ist. 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 eine standardmäßig sichere Umgebung 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. Es wird kein ausgehender Traffic von Arbeitslasten im Namespace 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.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 Google Cloud Console verwenden, um die Zugriffslog-Einträ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 der Traffic authentifiziert und autorisiert ist.

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) leiten.

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