Policy di autorizzazione e sicurezza della rete ambientale

Questa pagina mostra come creare policy di autorizzazione sul networking pervasivo.

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.
• Uno spazio dei nomi 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 carichi di lavoro.

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 baseline matchLabels: {} a livello di spazio dei nomi per il targeting di 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.s3ns.svc.id.goog/ns/ambient-test/sa/client
   EOF
   

   Sostituisci PROJECT_ID con l'ID progetto.

   La propagazione delle norme può richiedere fino a tre minuti dopo l'accettazione 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 carico di lavoro senza una policy di autorizzazione esplicita). L'operazione dovrebbe non riuscire a causa della norma 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 dalla policy di autorizzazione, i log di accesso di GKE Ambient Proxy contengono i seguenti campi nel payload JSON:

• jsonPayload.error_details: impostato su - rbac_access_denied_matched_policy[none]

Puoi utilizzare Esplora log nella console Cloud de Confiance per visualizzare le voci del log degli accessi per le connessioni rifiutate. Consulta Verificare che il traffico sia autenticato e autorizzato.

Policy di sicurezza in uscita

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

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