Autorisierungsrichtlinien für Sidecars in GKE einrichten

Vorschau – 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 GKE.

Hinweis

Sie sollten sich mit der Gateway API und Autorisierungserweiterungen auskennen.

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

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.

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

Namespace-weite AuthzPolicy

Wenn Sie ein erwartetes Traffic-Muster 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:
  - kind: Pod
    selector: {}
  rules:
  - to:
      operations:
      - paths:
        - type: Prefix
          value: "/bad_token"
  action: DENY
EOF
kubectl apply -f ns-authz-policy-deny.yaml

Beachten Sie, dass mit dem leeren selector: {} alle Pods im Namespace angesprochen werden.

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:
  - kind: Pod
    selector: {}
  rules:
  - to:
      operations:
      - paths:
        - type: Prefix
          value: "/headers"
        methods: ["GET"]
  action: ALLOW
EOF
kubectl apply -f ns-authz-policy-allow.yaml

Beachten Sie, dass mit dem leeren selector: {} alle Pods im Namespace angesprochen werden.

Eingehende Anfragen an eine Arbeitslast ablehnen

Wenn Sie eine Arbeitslast haben, die nur ausgehende Aufrufe ausführen soll, z. B. ein Cron-Job, 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:
 - kind: Pod
   selector:
matchLabels:
      app: EXAMPLE_APP
  rules:
  - to:
      operations:
      - paths:
        - type: Prefix
          value: "/deny_path"
  action: DENY
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“ in der übereinstimmenden App für die Pods EXAMPLE_APP 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 Anfragen ablehnt.

Im folgenden Beispiel wird eine Autorisierungsrichtlinie für die Beispiel-App-Bereitstellung 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:
 - kind: Pod
   selector:
matchLabels:
      app: EXAMPLE_APP
  rules:
  - from:
      sources:
      - principals:
        - principal:
          exact: "spiffe://cluster.local/NAMESPACE/pod1"
  action: ALLOW
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 werden und die genaue SPIFFE-Identität spiffe://cluster.local/NAMESPACE/pod1 präsentieren, erhalten eine 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 GCPAuthzExtension-CRD, falls noch nicht geschehen:

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

2. Stellen Sie eine Callout-basierte Autorisierungserweiterungs-Arbeitslast in Kubernetes bereit, die das ext_proc gRPC-Protokoll 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: ns1
   spec:
     backendRef:
       kind: Service
       name: authz-service
     loadBalancingScheme: INTERNAL_SELF_MANAGED
     forwardHeaders:
     - Authorization
     failOpen: false
     timeout: "0.1s"
     wireFormat: EXT_PROC_GRPC
   EOF
   kubectl apply -f authz-extension.yaml
   

   Mit diesem Befehl wird eine auf Callouts basierende 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 den 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:
     - kind: Pod
       selector:
         matchLabels:
           app: EXAMPLE_APP
     rules:
     - from:
         sources:
         - principals:
           - principal:
               exact: "spiffe://cluster.local/NAMESPACE/pod1"
       to:
         operations:
         - paths:
           - type: Exact
             value: "/api/payments-schedule"
     action: CUSTOM
     customProvider:
       authzExtension:
         targetRefs:
         - 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, bis Ihr benutzerdefinierter Dienst eine Antwort vom Typ OK oder DENY zurückgibt, bevor er die Anfrage an die Anwendung weiterleitet oder einen HTTP-Fehler 403 an den Aufrufer zurückgibt.