Criterio di rete

Per impostare una policy di rete per i carichi di lavoro delle macchine virtuali (VM) a livello di spazio dei nomi del progetto, utilizza la risorsa ProjectNetworkPolicy, una policy di rete multicluster per Google Distributed Cloud air-gapped (GDC). Consente di definire policy che consentono la comunicazione all'interno dei progetti, tra i progetti e con indirizzi IP esterni.

Per il traffico all'interno di un progetto, GDC applica un criterio di rete del progetto predefinito, il criterio intra-progetto, a ogni progetto per impostazione predefinita. Per attivare e controllare il traffico tra i progetti all'interno della stessa organizzazione, definisci policy tra progetti. Quando sono presenti più criteri, GDC combina in modo additivo le regole per ogni progetto. GDC consente anche il traffico se almeno una delle regole corrisponde.

Richiedere autorizzazione e accesso

Per eseguire le attività elencate in questa pagina, devi disporre del ruolo Amministratore NetworkPolicy progetto. Chiedi all'amministratore IAM del progetto di concederti il ruolo Amministratore NetworkPolicy del progetto (project-networkpolicy-admin) nello spazio dei nomi del progetto in cui si trova la VM.

Traffico intraprogetto

Per impostazione predefinita, i workload 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 intraprogetto

Quando crei un progetto, crei un ProjectNetworkPolicy di base predefinito sul server dell'API Management per consentire la comunicazione all'interno del progetto. Questa policy consente il traffico in entrata da altri carichi di lavoro nello stesso progetto. Puoi rimuoverlo, ma fai attenzione, perché ciò comporta il rifiuto della comunicazione tra progetti e tra carichi di lavoro dei container.

Policy di rete per il traffico in uscita intraprogetto

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

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

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

  ingress:
  - from:
    - projects:
        matchNames:
        - PROJECT_1
EOF

Traffico tra progetti (all'interno dell'organizzazione)

I carichi di lavoro delle VM di spazi dei nomi di progetti diversi ma all'interno della stessa organizzazione possono comunicare tra loro applicando un criterio di rete tra progetti.

Policy di rete per il traffico in entrata tra progetti

Affinché i carichi di lavoro del progetto consentano le connessioni da altri carichi di lavoro in un altro progetto, devi configurare un criterio Ingress per consentire ai carichi di lavoro dell'altro progetto di trasferire i dati in uscita.

La seguente policy consente ai carichi di lavoro nel progetto PROJECT_1 di consentire le connessioni dai carichi di lavoro nel progetto PROJECT_2, nonché il traffico di ritorno per gli stessi flussi. Se vuoi accedere alla tua VM in PROJECT_1 da un'origine all'interno di PROJECT_2, puoi utilizzare anche questo criterio. 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 norma 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.

Policy di rete per il traffico in uscita tra progetti

Quando concedi un criterio di traffico cross-project in entrata per attivare i workload in un progetto, PROJECT_1, per consentire le connessioni dai workload in un altro progetto, PROJECT_2, vengono concessi anche i criteri di traffico di ritorno per gli stessi flussi. Pertanto, non hai bisogno di una policy di rete per il traffico in uscita tra progetti.

Traffico tra più organizzazioni

Per connettere un workload VM a una destinazione esterna al tuo progetto che si trova in un'organizzazione diversa è necessaria un'approvazione esplicita. Questa approvazione è dovuta alla prevenzione dell'esfiltrazione dei dati, che GDC attiva per impostazione predefinita e impedisce a un progetto di avere l'uscita verso carichi di lavoro al di fuori dell'organizzazione in cui risiede il progetto. Le istruzioni per aggiungere un criterio di uscita specifico 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 diverse organizzazioni, deve essere applicato un ProjectNetworkPolicy che consenta il traffico dai client esterni dell'organizzazione al tuo progetto, ad esempio la connessione alla VM tramite SSH.

Per il traffico di risposta non è necessaria una policy di uscita corrispondente. Il traffico di ritorno è consentito implicitamente.

Se vuoi accedere alla tua VM in PROJECT_1 da una sorgente esterna all'organizzazione in cui si trova la VM, devi applicare i seguenti criteri per farlo. Devi ottenere e utilizzare il CIDR che contiene l'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 ProjectNetworkPolicy Ingress seguendo l'esempio kubectl. Applica il criterio a tutti i carichi di lavoro utente in PROJECT_1. Consente il traffico in entrata a tutti gli host in CIDR, che si trovano al di fuori 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 attivare il trasferimento dei dati a servizi esterni all'organizzazione, personalizza il criterio di rete del progetto, ProjectNetworkPolicy. Poiché la prevenzione dell'esfiltrazione dei dati è attivata per impostazione predefinita, il tuo ProjectNetworkPolicy personalizzato in uscita mostra un errore di convalida nel campo dello stato e il dataplane lo ignora. Questa procedura avviene in modo intenzionale.

Come indicato in Sicurezza e connettività, i carichi di lavoro possono trasferire i 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 traduzione dell'indirizzo di rete di origine (NAT) che utilizza un indirizzo IP noto allocato per il progetto. Sicurezza e connettività fornisce anche dettagli sull'applicazione della norma di rete del progetto (ProjectNetworkPolicy).

Per il traffico di risposta non è necessario un criterio Ingress corrispondente. Il traffico di ritorno è consentito implicitamente.

Attiva la policy in uscita personalizzata:

1. Configura e applica il tuo Egress personalizzato ProjectNetworkPolicy, seguendo l'esempio kubectl. Applica il criterio a tutti i carichi di lavoro degli utenti in PROJECT_1. Consente il traffico in uscita a tutti gli host in CIDR, che si trovano al di fuori dell'organizzazione. Il primo tentativo causa un errore di stato necessario, che è intenzionale.

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 nello stato sia presente un errore di convalida.

4. Chiedi all'utente amministratore di disattivare la prevenzione dell'esfiltrazione di dati. In questo modo viene attivata la configurazione, impedendo tutte le altre uscite.

5. Controlla 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 è in vigore:

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

   Sostituisci le variabili utilizzando le seguenti definizioni.

   Variabile	Definizione
   MANAGEMENT_API_SERVER	Il percorso kubeconfig del server API Management.
   PROJECT_1	Il nome del progetto GDC.
   CIDR	Il blocco CIDR (Classless Inter-Domain Routing) della destinazione consentita.
   NAME	Un nome associato alla destinazione.

   Dopo aver applicato questo criterio e a condizione che tu non abbia definito altri criteri di uscita, tutto il traffico in uscita viene negato per PROJECT_1.