Panoramica

Questa pagina fornisce una panoramica delle policy di rete dei progetti in Google Distributed Cloud (GDC) con air gap.

Le policy di rete del progetto definiscono regole in entrata o in uscita. A differenza delle policy di rete di Kubernetes, puoi specificare un solo tipo di policy per una policy. Ogni regola di una policy può essere configurata con un'azione Consenti (impostazione predefinita) o Nega.

Per il traffico all'interno di un progetto, GDC applica a ogni progetto una policy di rete del progetto predefinita, la policy intra-progetto predefinita.

Per impostazione predefinita, i servizi e i workload di un progetto sono isolati dai servizi e dai workload esterni. Tuttavia, i servizi e i workload di spazi dei nomi di progetti diversi e all'interno della stessa organizzazione possono comunicare tra loro applicando policy di rete per il traffico tra progetti.

Analogamente, la connessione di servizi e workload a una destinazione esterna al progetto in un'organizzazione diversa richiede un'approvazione esplicita. Devi disattivare la protezione dall'esfiltrazione di dati per consentire il traffico esterno all'organizzazione.

Le regole firewall in entrata e in uscita sono i componenti principali delle policy di rete del progetto e determinano quali tipi di traffico sono consentiti o negati in entrata e in uscita dalla rete. Per impostare le regole firewall per lo spazio dei nomi del progetto in GDC, utilizza la console GDC.

Sicurezza e connettività

Per impostazione predefinita, i servizi e i workload di un progetto sono isolati all'interno di quel progetto. Non possono comunicare con servizi e workload esterni senza configurare una policy di rete.

Per impostare una policy di rete per lo spazio dei nomi del progetto in GDC, utilizza la risorsa ProjectNetworkPolicy. Questa risorsa consente di definire policy che consentono la comunicazione all'interno dei progetti, tra i progetti, verso indirizzi IP esterni e da indirizzi IP esterni. Inoltre, puoi trasferire i workload da un progetto solo se disattivi la protezione dall'esfiltrazione di dati per il progetto.

Le policy di rete dei progetti GDC sono cumulative. L'applicazione risultante per un workload è una corrispondenza any per il flusso di traffico rispetto all'unione di tutte le policy applicate a quel workload. Se sono presenti più policy, le regole di ciascuna policy vengono combinate in modo additivo, consentendo il traffico se corrisponde ad almeno una delle regole.

Le regole Deny esplicite hanno la precedenza assoluta sulle regole Allow. Se un flusso di traffico corrisponde a una regola Deny, viene ignorato, anche se è consentito da un'altra regola o dalle policy predefinite della piattaforma.

Inoltre, dopo aver applicato una singola policy che seleziona un workload, tutto il traffico non specificato viene negato (modalità default-deny). Pertanto, quando applichi una o più policy che selezionano un workload come oggetto, è consentito solo il traffico esplicitamente consentito (e non esplicitamente negato).

Quando utilizzi un indirizzo IP noto allocato per il progetto, viene eseguita una Network Address Translation (NAT) di origine sul traffico in uscita dall'organizzazione.

Policy predefinita all'interno del progetto

Quando crei un progetto, GDC crea automaticamente una policy di rete del progetto globale denominata base-policy-allow-intra-project-traffic nello spazio dei nomi del progetto. Questa policy predefinita esegue le seguenti operazioni:

  • Seleziona come oggetto tutti i workload utente nel progetto.
  • Consente il traffico in entrata verso questi workload da tutti i workload nello stesso progetto, su tutte le porte.
  • Non consente il traffico in entrata da altri progetti o dall'esterno dell'organizzazione.

GDC crea la policy predefinita una sola volta, quando crea il progetto. Se modifichi o elimini la policy, GDC non la ripristina. GDC propaga la policy a ogni cluster del progetto come policy di rete denominata g-base-policy-allow-intra-project-traffic. Il campo status.zones[].replicaStatus.propagatedName della policy mostra questo nome.

Per visualizzare la policy predefinita, esegui questo comando:

kubectl --kubeconfig GLOBAL_API_SERVER get projectnetworkpolicy \
    base-policy-allow-intra-project-traffic -n PROJECT -o yaml

Sostituisci quanto segue:

  • GLOBAL_API_SERVER: il percorso kubeconfig del server API globale. Per saperne di più, consulta Server API globali e di zona.
  • PROJECT: il nome del progetto.

Se il comando restituisce un errore NotFound, la policy predefinita è stata eliminata. Per aggiungerla di nuovo, consulta Crea una policy in entrata tra progetti.

La policy predefinita si combina con le policy che crei come segue:

  • In entrata: i workload sono isolati dagli altri progetti e dall'esterno dell'organizzazione per impostazione predefinita, indipendentemente dall'esistenza della policy predefinita. Le policy in entrata che crei aggiungono origini consentite, come altri progetti o blocchi CIDR esterni. Se esiste la policy predefinita, non è necessario ripetere la regola intra-progetto nelle policy in entrata.
  • Traffico in entrata intra-progetto a livello di workload: se esiste la policy predefinita, tutti i workload del progetto possono comunicare tra loro su tutte le porte. Una policy di ingresso intra-progetto a livello di workload che utilizza l'azione Allow non limita questo traffico finché non elimini o modifichi la policy predefinita. Per evitare interruzioni, applica le policy a livello di workload e verifica che siano pronte prima di eliminare la policy predefinita. Per bloccare un traffico intra-progetto specifico mantenendo la policy predefinita, puoi utilizzare una regola di negazione esplicita, che è una funzionalità in anteprima. Per saperne di più, consulta Crea una policy in entrata a livello di workload all'interno del progetto.
  • In uscita: per impostazione predefinita, un progetto non ha policy in uscita. Il traffico in uscita non è limitato all'interno dell'organizzazione, ma la protezione dall'esfiltrazione dei dati (abilitata per impostazione predefinita) blocca il traffico che esce dall'organizzazione. Le policy in uscita diventano effettive solo dopo aver disattivato la protezione dall'esfiltrazione di dati per il progetto. Quando la protezione dall'esfiltrazione di dati è abilitata, i server API di zona rifiutano le policy in uscita e le policy in uscita globali non diventano pronte.

Policy di rete del progetto globali

Puoi creare policy di rete del progetto globali. L'ambito delle policy di rete del progetto globali si estende a un universo GDC. Ogni universo GDC può essere composto da più zone GDC organizzate in regioni interconnesse che condividono un control plane. Ad esempio, un universo composto da due regioni con tre zone ciascuna potrebbe essere: us-virginia1-a, us-virginia1-b, us-virginia1-c e eu-ams1-a, eu-ams1-b, eu-ams1-c.

L'ambito delle policy di rete del progetto a livello di zona è limitato alle zone specificate al momento della creazione. Ogni zona è un dominio di disaster recovery indipendente. Una zona gestisce l'infrastruttura, i servizi, le API e gli strumenti che utilizzano un control plane locale.

Per ulteriori informazioni sulle risorse globali in un universo GDC, consulta la panoramica multizona.

Puoi creare policy di rete del progetto globali utilizzando l'API Networking Kubernetes Resource Model (KRM). Utilizza la versione API networking.global.gdc.goog per creare risorse globali.

Puoi creare policy di rete del progetto a livello di zona utilizzando l'API KRM o la console GDC. Utilizza la versione API networking.gdc.goog per creare risorse di zona.

Policy di rete che consentono tutto

Puoi creare policy di rete che consentono tutto per stabilire regole di accesso predefinite ampie per un progetto.

Puoi configurare i seguenti tipi di policy di rete che consentono tutto:

  • Policy di rete Consenti tutto: consente il traffico da e verso qualsiasi origine, inclusi altri progetti e IP esterni.
  • Policy di rete Allow-all-external: consente il traffico da e verso indirizzi IP esterni all'organizzazione.
  • Policy di rete Consenti tutti i progetti: consente il traffico da e verso tutti i progetti all'interno dell'organizzazione.

Per saperne di più, consulta Crea policy di rete per consentire tutto il traffico.

Policy di rete di negazione esplicita

Puoi configurare regole di negazione esplicite nelle policy di rete del progetto per limitare la connettività tra progetti o blocchi CIDR specificati.

Funzionalità e vincoli principali delle regole di negazione:

  • Precedenza: le regole di negazione hanno la precedenza assoluta sulle regole di autorizzazione (incluse le policy della piattaforma di base).
  • Regole di sicurezza in uscita: per evitare di bloccare accidentalmente il traffico dell'infrastruttura critica, le regole deny in uscita escludono automaticamente gli spazi dei nomi di sistema e non di progetto.
  • Limitazione dei peer: per garantire una configurazione sicura, le regole di negazione in entrata devono specificare esplicitamente un peer di origine nel campo from, mentre le regole di negazione in uscita devono specificare esplicitamente un peer di destinazione nel campo to. Non puoi selezionare tutte le origini o le destinazioni lasciando vuoto il campo del peer. Non è consentito lasciare vuoto il campo peer e la policy verrà rifiutata.
  • Nessun rifiuto del traffico in uscita con DEP: non puoi configurare regole di rifiuto del traffico in uscita quando la protezione dall'esfiltrazione di dati (DEP) è abilitata per il progetto.

Per saperne di più, consulta Crea policy di rete con rifiuto esplicito.

Policy di rete a livello di workload

Puoi creare policy di rete a livello di workload per definire controllo dell'accesso granulare dell'accesso per singole VM e pod all'interno di un progetto. Queste policy agiscono come firewall per i tuoi workload, controllando il flusso di traffico in base alle etichette per migliorare la sicurezza e isolare le applicazioni. Questa granularità consente un controllo più rigoroso su quali workload possono comunicare tra loro all'interno dei progetti e tra progetti diversi.

Le policy di rete a livello di workload offrono anche la possibilità di applicare il PNP in una singola zona.

Per saperne di più, consulta Crea una policy intra-progetto a livello di workload e Crea una policy tra progetti a livello di workload.

Struttura e convalida delle policy

In una risorsa ProjectNetworkPolicy, i selettori di etichette dei workload sono nidificati su più livelli. La seguente policy in entrata mostra la posizione corretta di ogni selettore:

apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-frontend-to-backend
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        workloads:
          matchLabels:
            app: backend
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PEER_PROJECT
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                app: frontend
    ports:
    - protocol: TCP
      port: 8080

Sostituisci quanto segue:

  • PROJECT: il nome del progetto.
  • PEER_PROJECT: il nome del progetto che contiene i workload client.

Questa policy consente ai workload con etichetta app: frontend in PEER_PROJECT di connettersi ai workload con etichetta app: backend nel tuo progetto sulla porta TCP 8080.

Quando scrivi una policy, segui queste regole:

  • Imposta sempre spec.policyType in modo esplicito su Ingress o Egress. Una policy Ingress può contenere solo regole ingress con peer from e una policy Egress può contenere solo regole egress con peer to. Se ometti policyType, la policy viene impostata su Ingress per impostazione predefinita e il server API rifiuta una policy che contiene solo regole egress.
  • Per selezionare i workload oggetto in base all'etichetta, utilizza spec.subject.userWorkloadSelector.labelSelector.workloads. Se ometti userWorkloadSelector, la policy si applica a tutti i workload utente nel progetto.
  • Non inserire i selettori di etichette direttamente in spec.subject. Per impostazione predefinita, kubectl rifiuta campi come spec.subject.matchLabels con un messaggio strict decoding error: unknown field.
  • Per selezionare i workload peer in base all'etichetta, utilizza projectSelector.workloadSelector.labelSelector.workloads in una voce from o to.
  • Se i workload soggetto o peer sono VM, aggiungi il prefisso user-label.gpc.gke.io/ alle relative chiavi di etichetta. Ad esempio, utilizza user-label.gpc.gke.io/app: backend.
  • La policy predefinita all'interno del progetto creata automaticamente e alcune policy esistenti utilizzano il campo spec.subject.workloadSelector deprecato, che accetta direttamente un selettore di etichette. Utilizza userWorkloadSelector nelle nuove policy.

Per convalidare una policy rispetto al server API globale senza applicarla, esegui un dry run lato server:

kubectl --kubeconfig GLOBAL_API_SERVER apply --dry-run=server \
    --validate=strict -f POLICY_FILE

Il dry run segnala gli stessi errori di schema e convalida di un comando kubectl apply reale, ad esempio un campo sconosciuto o una regola egress in una policy Ingress, ma non crea né modifica la policy. Il dry run richiede le stesse autorizzazioni dell'applicazione della policy. Un dry run riuscito non conferma che la policy venga applicata. Dopo aver applicato la policy, verifica che sia pronta.

Per elencare i campi accettati dal server API globale, esegui questo comando:

kubectl --kubeconfig GLOBAL_API_SERVER explain projectnetworkpolicy.spec \
    --api-version=networking.global.gdc.goog/v1 --recursive

Sostituisci quanto segue:

  • GLOBAL_API_SERVER: il percorso kubeconfig del server API globale.
  • POLICY_FILE: il percorso del manifest ProjectNetworkPolicy.

Prepara i ruoli e l'accesso predefiniti

Per configurare le policy di rete del progetto, devi disporre dei ruoli di identità e accesso necessari:

  • Project Network Policy Admin: dispone delle autorizzazioni di scrittura su tutte le risorse PNP multizona nello spazio dei nomi del progetto globale. Chiedi all'amministratore dell'organizzazione IAM di concederti il ruolo global-project-networkpolicy-admin. Per saperne di più, consulta Descrizioni dei ruoli predefiniti.

Nodi del cluster di destinazione che utilizzano blocchi IP

Puoi utilizzare il campo ipBlocks in una risorsa ProjectNetworkPolicy per specificare singoli indirizzi IP dei nodi o intervalli CIDR dei nodi e controllare il traffico tra i pod e nodi del cluster specifici (ad esempio, consentendo l'ingresso dai nodi del control plane a un pod webhook personalizzato o limitando l'uscita dai pod ai nodi del control plane). Per le istruzioni, consulta Crea una policy interna al progetto per i cluster Standard.

Considerazioni sulla scalabilità

Quando configuri le policy di rete del progetto per scegliere come target nodi specifici o utilizzi intervalli CIDR ampi, le scelte di configurazione delle policy potrebbero influire sulla scalabilità e sulle prestazioni:

  • Comportamento di 0.0.0.0/0: l'utilizzo di un intervallo CIDR ampio come 0.0.0.0/0 in una regola ipBlocks corrisponde a tutti i nodi del cluster, oltre agli indirizzi IP esterni.
  • Scalabilità: a ogni nodo del cluster viene assegnata un'identità CIDR univoca. Ogni endpoint del workload (VM o pod) ha una tabella delle policy interne che memorizza le regole di rete. Nei cluster di grandi dimensioni, regole ipBlocks ampie come 0.0.0.0/0 aumentano l'utilizzo della tabella delle policy in proporzione al numero di nodi, perché il sistema deve creare voci per ogni identità CIDR univoca del nodo.
  • Avviso: evita di utilizzare intervalli CIDR troppo ampi nelle regole ipBlocks se hai un numero elevato di nodi o molte policy complesse, perché rischi di raggiungere il limite della tabella delle policy per un endpoint. Se un endpoint raggiunge questo limite, l'applicazione di nuove policy di rete non riesce, il che può interrompere la connettività di rete o impedire l'applicazione delle policy per quel workload.

Passaggi successivi