Policy di autorizzazione e sicurezza della rete ambientale

Questa pagina mostra come creare policy di autorizzazione su Ambient Networking.

Prerequisiti

Prima di poter completare i passaggi descritti in questo documento, devi soddisfare le seguenti condizioni:

  • Un cluster GKE in esecuzione con il networking ambient di Cloud Service Mesh abilitato.
  • Un namespace registrato in Ambient Networking (ad esempio ambient-test) con workload client e server di esempio di cui è stato eseguito il deployment.
  • mutual TLS (mTLS) abilitata tra i workload client e server utilizzando un GCPServerTLSPolicy (con mtlsMode: Strict) e un GCPClientTLSPolicy. Le regole basate sull'identità GCPAuthzPolicy che corrispondono a CLIENT_CERT_URI_SAN richiedono mTLS attivo per estrarre l'identità SPIFFE del client.

Per una configurazione dettagliata dell'ambiente, vedi Preparare GKE Ambient Networking.

Policy di negazione predefinita

Per impostazione predefinita, l'API GKE Ambient Authorization Policy consente tutto il traffico, a meno che non sia limitato dalla policy, in linea con il comportamento standard di Kubernetes NetworkPolicy.

L'azione DENY_BY_DEFAULT ti consente di modificare questo comportamento predefinito. Se applicata a uno spazio dei nomi, questa policy blocca tutto il traffico verso i workload in quello spazio dei nomi, a meno che non sia esplicitamente consentito da una policy ALLOW.

Questa pagina mostra come configurare e utilizzare DENY_BY_DEFAULT in Cloud Service Mesh per stabilire una postura sicura per impostazione predefinita per i tuoi workload.

Limitazioni

Prima di applicare una policy DENY_BY_DEFAULT, tieni presente le seguenti limitazioni:

  • Puoi creare una sola policy DENY_BY_DEFAULT per spazio dei nomi.
  • Una policy con l'azione DENY_BY_DEFAULT non può avere regole definite.
  • Utilizza questa azione per impostare una base di riferimento matchLabels: {} a livello di spazio dei nomi per scegliere come target tutti i pod. Non puoi utilizzare DENY_BY_DEFAULT per le limitazioni per pod.

Configura una policy di autorizzazione con negazione predefinita

Per stabilire una baseline di negazione predefinita in uno spazio dei nomi e consentire selettivamente l'accesso a workload specifici:

  1. Crea e applica un GCPAuthzPolicy con l'azione impostata su DENY_BY_DEFAULT al tuo spazio dei nomi.

    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

    L'output è simile al seguente:

     gcpauthzpolicy.networking.gke.io/deny-by-default-authz created

    Per impostazione predefinita, questo criterio blocca tutto il traffico in entrata (est-ovest e in entrata) verso i carichi di lavoro nello spazio dei nomi ambient-test. Non limita il traffico in uscita proveniente dai carichi di lavoro nello spazio dei nomi.

  2. Per consentire selettivamente il traffico, crea e applica una policy ALLOW:

    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

    Sostituisci PROJECT_ID con l'ID progetto.

    La propagazione delle policy può richiedere fino a tre minuti dopo l'accettazione da parte del controller. Attendi tre minuti prima di procedere.

  3. Testa la connettività dal client al server. L'operazione dovrebbe riuscire perché corrisponde alla policy ALLOW.

    kubectl exec -it deploy/client -n ambient-test -- /bin/curl -fsLS server.ambient-test.svc.cluster.local

  4. Testa la connettività dal server a se stesso (o a qualsiasi altro workload senza una policy di autorizzazione esplicita). L'operazione non dovrebbe riuscire a causa della policy DENY_BY_DEFAULT.

    kubectl exec -it deploy/server -n ambient-test -- /bin/curl -fsLS server.ambient-test.svc.cluster.local

    L'output è simile al seguente:

    curl: (52) Empty reply from server.

Logging

Quando una richiesta viene negata da una policy di autorizzazione, il proxy del nodo scrive una voce di log di accesso in Cloud Logging con il nome del log gke-ambient-node-proxy-accesslog. La voce contiene il seguente campo nel payload JSON:

  • jsonPayload.error_details: - rbac_access_denied_matched_policy[none]

Puoi utilizzare Esplora log nella console Google Cloud per visualizzare le voci di log degli accessi per le connessioni negate:

resource.type="k8s_container"
logName="projects/PROJECT_ID/logs/gke-ambient-node-proxy-accesslog"
jsonPayload.error_details=~"rbac_access_denied"

Per saperne di più, consulta Verifica che il traffico sia autenticato e autorizzato.

Policy di sicurezza in uscita

Per ispezionare e controllare il traffico in uscita dai workload di Ambient Networking verso endpoint esterni o internet, puoi instradare il traffico in uscita tramite Secure Web Proxy (SWP).

Per istruzioni sulla configurazione delle risorse GCPBackend e GCPEgressPolicy, vedi Instradare il traffico in uscita ambientale tramite Secure Web Proxy.