Configura le policy di autorizzazione sui sidecar su GKE

Questa pagina fornisce istruzioni per la configurazione di diversi tipi di policy di autorizzazione sui sidecar di Cloud Service Mesh su GKE.

Prima di iniziare

Dovresti avere familiarità con l'API Gateway e le estensioni dell'autorizzazione.

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

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

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

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

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

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

    Go to project selector

  6. Verify that billing is enabled for your Google Cloud project.

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

    8.

AuthzPolicy a livello di spazio dei nomi

Se vuoi rifiutare un pattern di traffico previsto per l'intero spazio dei nomi, configura una policy di autorizzazione per rifiutare tutte le richieste 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:
  - 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

Il valore vuoto selector: {} 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:
  - 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

Il valore vuoto selector: {} ha come target tutti i pod nello spazio dei nomi.

Nega le richieste in entrata a un workload

Se hai un workload che deve effettuare solo chiamate in uscita, ad esempio un cron job, configura una policy di autorizzazione per rifiutare tutte le richieste HTTP in entrata al workload:

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

L'output è simile al seguente:

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

Dopo l'applicazione di questa policy, qualsiasi richiesta HTTP in entrata al percorso /deny_path sui pod corrispondenti all'app: 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 consenta solo le richieste che corrispondono a criteri specifici, rifiutando le altre.

L'esempio seguente configura una policy di autorizzazione nel deployment example-app per consentire solo le 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:
  - 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

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 un codice HTTP 200 OK. Qualsiasi altra richiesta verrà rifiutata dal proxy con un errore HTTP 403 Forbidden.

Delega a un motore di autorizzazione esterno

Puoi utilizzare il tuo motore di autorizzazione e configurare Cloud Service Mesh in modo che deleghi tutte le decisioni di autorizzazione per un workload al motore configurato.

  1. Installa la CRD GCPAuthzExtension se non è già installata:

    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 basato su callout in Kubernetes che supporta il protocollo gRPC ext_proc 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: 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

    Sostituisci quanto segue:

    • NAMESPACE: lo spazio dei nomi del servizio authz-service e dei workload.
    • PORT: la porta del servizio authz-service che gestisce l'API gRPC ext_proc.

    Questo comando crea un'estensione dell'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 la policy di autorizzazione per delegare le decisioni di autorizzazione per il workload all'estensione dell'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:
  - 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

    L'output è simile al seguente:

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

    Il proxy attende la risposta dell'estensione dell'autorizzazione prima di inoltrare la richiesta all'applicazione. Se l'estensione rifiuta la richiesta terminando la chiamata con un errore o se la chiamata non va a buon fine o scade mentre failOpen è false, il chiamante riceve una risposta HTTP 500. Se l'estensione invia una risposta immediata, il chiamante riceve il codice di stato di quella risposta.