Configura le norme di autorizzazione sui sidecar su GKE

Anteprima — Authorization Policies on Sidecars

Questa funzionalità è soggetta ai "Termini dell'offerta pre-GA" nella sezione dei Termini di servizio generali dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per ulteriori informazioni, consulta le descrizioni della fase di lancio.

Questa pagina fornisce istruzioni per configurare diversi tipi di criteri di autorizzazione sui sidecar Cloud Service Mesh su GKE.

Prima di iniziare

Devi avere familiarità con l'API Gateway e le estensioni di autorizzazione.

Prima di creare una policy di autorizzazione, devi eseguire i seguenti passaggi:

Accedi al tuo account Google Cloud . Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti senza costi per l'esecuzione, il test e il deployment dei carichi di lavoro.

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

AuthzPolicy a livello di spazio dei nomi

Se vuoi negare un pattern di traffico previsto per l'intero spazio dei nomi, configura una policy di autorizzazione per negare qualsiasi richiesta HTTP in entrata a tutti i workload in uno spazio dei nomi:

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

Tieni presente che il selettore selector: {} vuoto ha come target tutti i pod nello spazio dei nomi.

Se vuoi consentire un pattern di traffico previsto per l'intero spazio dei nomi, configura una policy di autorizzazione per consentire tutte le richieste HTTP in entrata a tutti i workload in uno spazio dei nomi:

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

Tieni presente che il selettore selector: {} vuoto ha come target tutti i pod nello spazio dei nomi.

Negare le richieste in entrata a un workload

Se hai un carico di lavoro che deve effettuare solo chiamate in uscita, come un job cron, configura una policy di autorizzazione per negare qualsiasi richiesta HTTP in entrata al carico di lavoro:

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

L'output è simile al seguente:

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

Dopo l'applicazione di questo criterio, qualsiasi richiesta HTTP in entrata al percorso /deny_path sui pod dell'app di corrispondenza EXAMPLE_APP verrà rifiutata e il chiamante riceverà un codice di risposta HTTP 403 Forbidden.

Consenti richieste in entrata specifiche a un workload

Puoi anche configurare una policy ALLOW che consente solo le richieste che corrispondono a un criterio specifico, rifiutando le altre.

Il seguente esempio configura una policy di autorizzazione sul deployment example-app per consentire solo richieste mTLS dai pod con identità spiffe://cluster.local/namespace/pod1.

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

L'output è simile al seguente:

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

Solo le richieste in entrata autenticate utilizzando mTLS che presentano l'identità SPIFFE esatta spiffe://cluster.local/NAMESPACE/pod1 riceveranno una risposta HTTP 200 OK. Qualsiasi altra richiesta verrà rifiutata dal proxy con un errore HTTP 403 Forbidden.

Delega a un motore di autorizzazione esterno

Puoi portare il tuo motore di autorizzazione e configurare Cloud Service Mesh per delegare tutte le decisioni di autorizzazione per un carico di lavoro al motore configurato.

1. Installa il GCPAuthzExtension CRD se non è già installato:

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

2. Esegui il deployment di un workload di estensione dell'autorizzazione basata su callout in Kubernetes che supporta il protocollo ext_proc gRPC e configura una risorsa di estensione dell'autorizzazione:

   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
   

   Questo comando crea un'estensione di autorizzazione basata su callout che viene eseguita come servizio Kubernetes authz-service.

   L'output è simile al seguente:

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

3. Configura i criteri di autorizzazione per delegare le decisioni di autorizzazione per il carico di lavoro all'estensione di autorizzazione configurata in precedenza:

   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
   

   L'output è simile al seguente:

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

   Il proxy attenderà che il tuo servizio personalizzato restituisca una risposta OK o DENY prima di inoltrare la richiesta all'applicazione o restituire un errore HTTP 403 al chiamante.