Autorisierungsrichtlinien für Sidecars in GKE einrichten

Vorabversion – Autorisierungsrichtlinien für Sidecars

Diese Funktion unterliegt den „Bedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA‑Funktionen stehen in der vorliegenden Form zur Verfügung und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie unter den Beschreibungen der Startphase.

Auf dieser Seite finden Sie eine Anleitung zum Einrichten verschiedener Arten von Autorisierungsrichtlinien für Cloud Service Mesh-Sidecars in der GKE.

Hinweis

Sie sollten mit der Gateway API und Autorisierungserweiterungen vertraut sein.

Bevor Sie eine Autorisierungsrichtlinie erstellen, müssen Sie die folgenden Schritte ausführen:

Melden Sie sich in Ihrem Google Cloud -Konto an. Wenn Sie mit Google Cloudnoch nicht vertraut sind, erstellen Sie einfach ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Network Security, Network Services APIs, if any are not already enabled.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the APIs

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Network Security, Network Services APIs, if any are not already enabled.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the APIs

Hinweis: Nachdem Sie eine Autorisierungsrichtlinie erstellt oder geändert haben, kann es bis zu 15 Minuten dauern, bis die Sidecars mit der Durchsetzung beginnen.

Namespace-weite AuthzPolicy

Wenn Sie ein erwartetes Trafficmuster für den gesamten Namespace ablehnen möchten, konfigurieren Sie eine Autorisierungsrichtlinie, um alle eingehenden HTTP-Anfragen an alle Arbeitslasten in einem Namespace abzulehnen:

cat >ns-authz-policy-deny.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: ns-authz
  namespace: NAMESPACE
spec:
  targetRefs:
  - group: ""
    kind: Pod
    selector: {}
  rules:
  - to:
      operations:
      - paths:
        - type: Prefix
          value: "/bad_token"
  action: DENY
  enforcementLevel: L7
EOF
kubectl apply -f ns-authz-policy-deny.yaml

Der leere selector: {}-Wert zielt auf alle Pods im Namespace ab.

Wenn Sie ein erwartetes Trafficmuster für den gesamten Namespace zulassen möchten, konfigurieren Sie eine Autorisierungsrichtlinie, um alle eingehenden HTTP-Anfragen an alle Arbeitslasten in einem Namespace zuzulassen:

cat >ns-authz-policy-allow.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: ns-authz
  namespace: NAMESPACE
spec:
  targetRefs:
  - group: ""
    kind: Pod
    selector: {}
  rules:
  - to:
      operations:
      - paths:
        - type: Prefix
          value: "/headers"
        methods: ["GET"]
  action: ALLOW
  enforcementLevel: L7
EOF
kubectl apply -f ns-authz-policy-allow.yaml

Mit dem leeren selector: {} werden alle Pods im Namespace ausgewählt.

Eingehende Anfragen an eine Arbeitslast ablehnen

Wenn Sie eine Arbeitslast haben, die nur ausgehende Aufrufe ausführen soll, z. B. einen Cronjob, konfigurieren Sie eine Autorisierungsrichtlinie, um alle eingehenden HTTP-Anfragen an die Arbeitslast abzulehnen:

cat >deny-path-authz-policy.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: my-workload-authz
  namespace: NAMESPACE
spec:
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: EXAMPLE_APP
  rules:
  - to:
      operations:
      - paths:
        - type: Prefix
          value: "/deny_path"
  action: DENY
  enforcementLevel: L7
EOF
kubectl apply -f deny-path-authz-policy.yaml

Die Ausgabe sieht etwa so aus:

gcpauthzpolicy.networking.gke.io/my-workload-authz created

Nachdem diese Richtlinie angewendet wurde, wird jede eingehende HTTP-Anfrage an den Pfad /deny_path auf den Pods, die mit app: EXAMPLE_APP übereinstimmen, abgelehnt und der Aufrufer erhält den HTTP-Antwortcode „403 Forbidden“.

Bestimmte eingehende Anfragen an eine Arbeitslast zulassen

Sie können auch eine ALLOW-Richtlinie konfigurieren, die nur Anfragen zulässt, die bestimmten Kriterien entsprechen, und alle anderen ablehnt.

Im folgenden Beispiel wird eine Autorisierungsrichtlinie für das Deployment „example-app“ konfiguriert, um nur mTLS-Anfragen von Pods mit der Identität spiffe://cluster.local/NAMESPACE/pod1 zuzulassen.

cat >allow-authz-policy.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: my-workload-authz
  namespace: NAMESPACE
spec:
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: EXAMPLE_APP
  rules:
  - from:
      sources:
      - principals:
        - principal:
            type: Exact
            value: "spiffe://cluster.local/NAMESPACE/pod1"
  action: ALLOW
  enforcementLevel: L7
EOF
kubectl apply -f allow-authz-policy.yaml

Die Ausgabe sieht etwa so aus:

gcpauthzpolicy.networking.gke.io/my-workload-authz created

Nur eingehende Anfragen, die mit mTLS authentifiziert wurden und die genaue SPIFFE-Identität spiffe://cluster.local/NAMESPACE/pod1 aufweisen, erhalten die HTTP-Antwort „200 OK“. Alle anderen Anfragen werden vom Proxy mit dem HTTP-Fehler „403 Forbidden“ abgelehnt.

An eine externe Autorisierungs-Engine delegieren

Sie können Ihre eigene Autorisierungs-Engine verwenden und Cloud Service Mesh so konfigurieren, dass alle Autorisierungsentscheidungen für eine Arbeitslast an die konfigurierte Engine delegiert werden.

1. Installieren Sie die CRD GCPAuthzExtension, falls sie noch nicht installiert ist:

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-gateway-api/main/config/crd/networking.gke.io_gcpauthzextensions.yaml
   

2. Stellen Sie eine auf Callouts basierende Autorisierungserweiterungs-Arbeitslast in Kubernetes bereit, die das gRPC-Protokoll ext_proc unterstützt, und konfigurieren Sie eine Autorisierungserweiterungs-Ressource:

   cat >authz-extension.yaml <<EOF
   apiVersion: networking.gke.io/v1
   kind: GCPAuthzExtension
   metadata:
     name: my-authz-ext
     namespace: NAMESPACE
   spec:
     backendRef:
       group: ""
       kind: Service
       name: authz-service
       port: PORT
     authority: "authz-service.NAMESPACE.svc.cluster.local"
     forwardHeaders:
     - Authorization
     failOpen: false
     timeout: "100ms"
     wireFormat: ExtProcGRPC
   EOF
   kubectl apply -f authz-extension.yaml
   

   Ersetzen Sie Folgendes:

   • NAMESPACE: der Namespace des authz-service-Dienstes und der Arbeitslasten.
   • PORT: der Port des authz-service-Dienstes, der die ext_proc-gRPC API bereitstellt.

   Mit diesem Befehl wird eine Callout-basierte Autorisierungserweiterung erstellt, die als Kubernetes-Dienst authz-service ausgeführt wird.

   Die Ausgabe sieht etwa so aus:

   gcpauthzextension.networking.gke.io/my-authz-ext created
   

3. Richten Sie die Autorisierungsrichtlinie so ein, dass Autorisierungsentscheidungen für die Arbeitslast an die zuvor konfigurierte Autorisierungserweiterung delegiert werden:

   cat >authz-policy.yaml <<EOF
   apiVersion: networking.gke.io/v1
   kind: GCPAuthzPolicy
   metadata:
     name: my-workload-authz
     namespace: NAMESPACE
   spec:
     targetRefs:
     - group: ""
       kind: Pod
       selector:
         matchLabels:
           app: EXAMPLE_APP
     rules:
     - from:
         sources:
         - principals:
           - principal:
               type: Exact
               value: "spiffe://cluster.local/NAMESPACE/pod1"
       to:
         operations:
         - paths:
           - type: Exact
             value: "/api/payments-schedule"
     action: CUSTOM
     enforcementLevel: L7
     customProviders:
       extensionRefs:
       - group: networking.gke.io
         kind: GCPAuthzExtension
         name: my-authz-ext
   EOF
   kubectl apply -f authz-policy.yaml
   

   Die Ausgabe sieht etwa so aus:

   gcpauthzpolicy.networking.gke.io/my-workload-authz created
   

   Der Proxy wartet auf die Antwort der Autorisierungserweiterung, bevor er die Anfrage an die Anwendung weiterleitet. Wenn die Erweiterung die Anfrage ablehnt, indem sie den Aufruf mit einem Fehler beendet, oder wenn der Aufruf fehlschlägt oder eine Zeitüberschreitung auftritt, während failOpen den Wert false hat, erhält der Aufrufer eine HTTP-500-Antwort. Wenn die Erweiterung eine sofortige Antwort sendet, erhält der Aufrufer den Statuscode aus dieser Antwort.