Questa pagina è stata tradotta dall'API Cloud Translation.

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 l'appliance Google Distributed Cloud (GDC) isolata da internet. 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é in questo modo viene negata la comunicazione tra i carichi di lavoro intraprogetto e 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 l'ingresso degli altri carichi di lavoro del progetto.

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. 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.

Variabile	Definizione
`MANAGEMENT_API_SERVER`	Il percorso del server API Management `kubeconfig`.
`PROJECT_1`	Il nome di un progetto GDC corrispondente a PROJECT_1 nell'esempio.
`PROJECT_2`	Il nome di un progetto GDC corrispondente a PROJECT_2 nell'esempio.

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

Quando hai configurato un criterio di rete di uscita tra organizzazioni, non devi concedere l'accesso in entrata. Il traffico in uscita consentito dal carico di lavoro al di fuori della tua organizzazione passa attraverso un bilanciatore del carico e questo traffico in uscita è una conversione dell'indirizzo di rete di origine (NAT) che utilizza un indirizzo IP che hai allocato per il progetto.

Policy di rete per il traffico in uscita tra organizzazioni

Per abilitare l'uscita verso servizi esterni all'organizzazione, personalizza il criterio di rete del progetto, ProjectNetworkPolicy. Tuttavia, poiché la prevenzione dell'esfiltrazione dei dati è abilitata per impostazione predefinita, l'uscita ProjectNetworkPolicy personalizzata mostra un errore di convalida nel campo di stato e il dataplane lo ignora. Ciò avviene in modo intenzionale.

I workload possono uscire quando consenti l'esfiltrazione di dati per un determinato progetto. Il traffico che consenti in uscita è una traduzione dell'indirizzo di rete di origine (NAT) che utilizza un indirizzo IP noto allocato per il progetto.

Queste istruzioni mostrano come attivare il criterio di uscita personalizzato:

Configura e applica il tuo Egress personalizzato ProjectNetworkPolicy, seguendo l'esempio dell'interfaccia a riga di comando 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.

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

Al termine, verifica che nello stato sia presente un errore di convalida.

Importante: solo il traffico in uscita verso destinazioni esterne all'organizzazione del tuo progetto che consenti esplicitamente nella configurazione di ProjectNetworkPolicy viene concesso. Qualsiasi altro traffico in uscita viene negato. Pertanto, applica un Egress ProjectNetworkPolicy personalizzato solo quando i requisiti impongono una norma di questo tipo.
Chiedi all'utente amministratore di disattivare la prevenzione dell'esfiltrazione di dati. In questo modo viene attivata la configurazione, impedendo tutte le altre uscite.

Importante :la disattivazione della prevenzione dell'esfiltrazione di dati, senza definire uno o più ProjectNetworkPolicy validi, consente tutto il traffico in uscita verso destinazioni esterne all'organizzazione del progetto. Non disattivare mai questa opzione senza prima completare il passaggio 1 per configurare l'uscita personalizzata ProjectNetworkPolicy.

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 file `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.