Policy di rete

Questo documento spiega come impostare le policy di rete per un'istanza di macchina virtuale (VM) in Google Distributed Cloud (GDC) con air gap.

Per impostare una policy di rete per i workload delle VM a livello di spazio dei nomi del progetto, utilizza la risorsa ProjectNetworkPolicy, una policy di rete multi-cluster per Distributed Cloud. Puoi quindi definire policy per abilitare la comunicazione all'interno dei progetti, tra i progetti e verso indirizzi IP esterni.

Per il traffico all'interno di un progetto, GDC applica per impostazione predefinita una policy di rete del progetto predefinita, la policy intra-progetto, a ogni progetto, che può essere sostituita o estesa. Per abilitare e controllare il traffico tra progetti all'interno della stessa organizzazione, definisci le policy di rete tra progetti. Quando sono presenti più policy, GDC combina in modo additivo le regole per ogni progetto. GDC consente anche il traffico se almeno una delle regole corrisponde.

Questo documento è rivolto agli sviluppatori dei gruppi di amministratori della piattaforma o di operatori delle applicazioni che creano e gestiscono le policy di rete per le VM in un ambiente Distributed Cloud. Per saperne di più, consulta la documentazione sui segmenti di pubblico per GDC con air gap.

Richiedi ruoli IAM

Contatta l'amministratore del progetto IAM per richiedere i seguenti ruoli nel tuo progetto:

  • Project NetworkPolicy Admin (project-networkpolicy-admin): crea, elenca, aggiorna ed elimina le policy di rete del progetto per le istanze VM nello spazio dei nomi del progetto.

Questo ruolo deve essere associato allo spazio dei nomi del progetto in cui si trova la VM. Segui i passaggi per verificare il tuo accesso.

Traffico interno al progetto

Per impostazione predefinita, i workload delle VM in uno spazio dei nomi del progetto possono comunicare tra loro senza esporre i servizi al mondo esterno, anche se le VM fanno parte di cluster diversi all'interno dello stesso progetto.

Policy di rete per il traffico in entrata all'interno del progetto

Quando crei un progetto, crei un ProjectNetworkPolicy di base predefinito sul server dell'API di gestione per consentire la comunicazione all'interno del progetto. Questa policy consente il traffico in entrata da altri workload nello stesso progetto. Puoi rimuoverla, ma fai attenzione, perché in questo modo neghi la comunicazione sia tra i progetti sia tra i workload dei container.

Policy di rete per il traffico in uscita tra progetti

Per impostazione predefinita, non è necessario intraprendere alcuna azione per il traffico in uscita. Questo perché, in assenza di una policy in uscita, tutto il traffico è consentito. Tuttavia, quando imposti una singola policy, è consentito solo il traffico specificato dalla policy.

Quando disattivi la prevenzione dell'esfiltrazione di dati e applichi un ProjectNetworkPolicy in uscita al progetto, ad esempio per impedire l'accesso a una risorsa esterna, utilizza una policy obbligatoria per consentire il traffico in uscita all'interno del progetto:

kubectl --kubeconfig MANAGEMENT_API_SERVER \
  apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-intra-project-egress-traffic
spec:
  policyType: Egress
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_1
EOF

Traffico tra progetti (all'interno dell'organizzazione)

I workload delle VM di spazi dei nomi di progetti diversi, ma all'interno della stessa organizzazione, possono comunicare tra loro applicando una policy di rete tra progetti.

Policy di rete per il traffico in entrata tra progetti

Affinché i workload del progetto consentano le connessioni da altri workload in un altro progetto, devi configurare una policy in entrata per consentire il trasferimento di dati in uscita degli altri workload del progetto.

La seguente policy consente ai workload nel progetto PROJECT_1 di consentire le connessioni dai workload nel progetto PROJECT_2, nonché il traffico di ritorno per gli stessi flussi. Puoi utilizzare questa policy anche se vuoi accedere alla tua VM in PROJECT_1 da un'origine all'interno di PROJECT_2. Esegui questo comando per applicare la policy:

kubectl --kubeconfig MANAGEMENT_API_SERVER \
  apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-ingress-traffic-from-PROJECT_2
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projects:
        matchNames:
        - PROJECT_2
EOF

Il comando precedente consente a PROJECT_2 di andare a PROJECT_1, ma non consente le connessioni avviate da PROJECT_1 a PROJECT_2. Per quest'ultimo, è necessaria una policy reciproca nel progetto PROJECT_2. Esegui questo comando per applicare la policy reciproca:

kubectl --kubeconfig MANAGEMENT_API_SERVER \
  apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_2
  name: allow-ingress-traffic-from-PROJECT_1
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projects:
        matchNames:
        - PROJECT_1
EOF

Ora hai consentito le connessioni avviate da e verso PROJECT_1 e PROJECT_2.

Utilizza le seguenti definizioni per le variabili.

VariabileDefinizione
MANAGEMENT_API_SERVERIl percorso kubeconfig del server dell'API di gestione.
PROJECT_1Il nome di un progetto GDC corrispondente a PROJECT_1 nell'esempio.
PROJECT_2Il nome di un progetto GDC corrispondente a PROJECT_2 nell'esempio.

Policy di rete per il traffico in uscita tra progetti

Quando concedi una policy per il traffico in entrata tra progetti per abilitare i workload in un progetto, PROJECT_1, per consentire le connessioni dai workload in un altro progetto, PROJECT_2, concedi anche il traffico di ritorno per gli stessi flussi. Pertanto, non è necessaria una policy di rete per il traffico in uscita tra progetti.

Traffico tra organizzazioni

Per connettere un workload di una VM a una destinazione esterna al progetto che si trova in un'altra organizzazione, è necessaria un'approvazione esplicita. Questa approvazione è dovuta alla prevenzione dell'esfiltrazione di dati, che GDC attiva per impostazione predefinita e impedisce a un progetto di avere traffico in uscita verso workload esterni all'organizzazione in cui risiede il progetto. Le istruzioni per aggiungere una policy in uscita specifica e attivare l'esfiltrazione di dati sono riportate di seguito in questa sezione.

Policy di rete per il traffico in entrata tra organizzazioni

Per consentire il traffico in entrata tra organizzazioni diverse, è necessario applicare un ProjectNetworkPolicy che consenta il traffico dai client esterni dell'organizzazione al tuo progetto, ad esempio la connessione alla VM tramite SSH.

Non è richiesta una policy in uscita corrispondente per il traffico di risposta. Il traffico di ritorno è implicitamente consentito.

Se vuoi accedere alla VM in PROJECT_1 da un'origine esterna all'organizzazione in cui si trova la VM, devi applicare la seguente policy. Devi ottenere e utilizzare il CIDR, che contiene il tuo indirizzo IP di origine. CIDR deve essere in notazione network/len. Ad esempio, 192.0.2.0/21 è un valore valido.

  1. Configura e applica la risorsa Ingress ProjectNetworkPolicy, seguendo l'esempio kubectl. Applica la policy a tutti i workload utente in PROJECT_1. Consente il traffico in entrata verso tutti gli host in CIDR, che si trovano all'esterno dell'organizzazione.

  2. Applica la configurazione ProjectNetworkPolicy:

    kubectl --kubeconfig MANAGEMENT_API_SERVER \
      apply -f - <<EOF
    apiVersion: networking.gdc.goog/v1
    kind: ProjectNetworkPolicy
    metadata:
      namespace: PROJECT_1
      name: allow-external-traffic
    spec:
      policyType: Ingress
      subject:
        subjectType: UserWorkload
      ingress:
      - from:
        - ipBlock:
            cidr: CIDR
    EOF
    

Policy di rete per il traffico in uscita tra organizzazioni

Per abilitare il trasferimento di dati in uscita verso servizi esterni all'organizzazione, personalizza la policy di rete del progetto ProjectNetworkPolicy. Poiché la prevenzione dell'esfiltrazione dei dati è abilitata per impostazione predefinita, l'Egress ProjectNetworkPolicy personalizzato mostra un errore di convalida nel campo dello stato e il piano dati lo ignora. Questo processo avviene per progettazione.

Come indicato in Sicurezza e connettività, i workload possono trasferire dati in uscita quando consenti l'esfiltrazione di dati per un determinato progetto. Il traffico che consenti per il trasferimento di dati in uscita è una Network Address Translation (NAT) di origine che utilizza un indirizzo IP noto allocato per il progetto. Sicurezza e connettività fornisce inoltre dettagli sull'applicazione della policy di rete del progetto (ProjectNetworkPolicy).

Non è richiesta una policy in entrata corrispondente per il traffico di risposta. Il traffico di ritorno è implicitamente consentito.

Abilita la policy in uscita personalizzata:

  1. Configura e applica il tuo traffico in uscita personalizzato ProjectNetworkPolicy, seguendo l'esempio kubectl. Applica la policy a tutti i workload degli utenti in PROJECT_1. Consente il traffico in uscita verso tutti gli host in CIDR, che si trovano all'esterno dell'organizzazione. Il primo tentativo causa un errore di stato necessario, che è previsto.

  2. Applica la configurazione ProjectNetworkPolicy:

    kubectl --kubeconfig MANAGEMENT_API_SERVER \
      apply -f - <<EOF
    apiVersion: networking.gdc.goog/v1
    kind: ProjectNetworkPolicy
    metadata:
      namespace: PROJECT_1
      name: allow-egress-traffic-to-NAME
    spec:
      policyType: Egress
      subject:
        subjectType: UserWorkload
      egress:
      - to:
        - ipBlock:
            cidr: CIDR
    EOF
    
  3. Al termine, verifica che lo stato mostri un errore di convalida.

  4. Chiedi all'utente amministratore di disattivare la prevenzione dell'esfiltrazione di dati. In questo modo, la tua configurazione viene attivata, mentre viene impedito tutto il traffico in uscita.

  5. Controlla la ProjectNetworkPolicy che hai appena creato e verifica che l'errore nel campo dello stato di convalida non sia più presente e che lo stato Ready sia True, a indicare che la policy è attiva:

    kubectl --kubeconfig MANAGEMENT_API_SERVER \
      get projectnetworkpolicy allow-egress-traffic-to-NAME \
      -n PROJECT_1 \
      -o yaml
    

    Sostituisci le variabili utilizzando le seguenti definizioni.

    VariabileDefinizione
    MANAGEMENT_API_SERVERIl percorso kubeconfig del server API di gestione.
    PROJECT_1Il nome del progetto GDC.
    CIDRIl blocco CIDR (Classless Inter-Domain Routing) della destinazione consentita.
    NAMEUn nome associato alla destinazione.

    Dopo aver applicato questa policy e a condizione che tu non abbia definito altre policy in uscita, tutto il resto del traffico in uscita viene negato per PROJECT_1.