Crea criteri di rete tra progetti

Questa pagina fornisce istruzioni per configurare i criteri di rete per il traffico tra progetti in Google Distributed Cloud (GDC) con air gap.

Il traffico tra progetti si riferisce alla comunicazione tra servizi e carichi di lavoro di spazi dei nomi di progetti diversi, ma all'interno della stessa organizzazione.

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

Per impostazione predefinita, queste norme si applicano a livello globale in tutte le zone. Per saperne di più sulle risorse globali in un universo GDC, consulta la panoramica multizona.

Se è necessaria l'applicazione del traffico tra progetti all'interno di una singola zona, consulta Creare una policy tra progetti a livello di workload per una singola zona.

Prima di iniziare

Per configurare i criteri di rete per il traffico tra progetti, devi disporre di:

  • I ruoli di identità e accesso necessari. Per gestire le policy per un progetto specifico, devi disporre del ruolo project-networkpolicy-admin. Per gli ambienti multizona in cui devi gestire criteri che si estendono a tutte le zone, devi disporre del ruolo global-project-networkpolicy-admin. Per saperne di più, consulta Preparare ruoli e accesso predefiniti.
  • Un progetto esistente. Per saperne di più, consulta Creare un progetto.

Crea una policy tra progetti

Puoi definire criteri di traffico tra progetti in entrata o in uscita per gestire la comunicazione tra i progetti.

Crea un criterio in entrata tra progetti

Affinché i servizi o i carichi di lavoro del progetto consentano le connessioni da altri carichi di lavoro in un altro progetto all'interno della tua organizzazione, devi configurare una regola firewall in entrata per consentire il traffico in entrata di altri carichi di lavoro del progetto.

Questo criterio si applica a tutte le zone della tua organizzazione.

Segui questi passaggi per creare una nuova regola firewall e consentire il traffico in entrata dai carichi di lavoro in un altro progetto:

Console

  1. Nella console GDC del progetto che stai configurando, vai a Networking > Firewall nel menu di navigazione per aprire la pagina Firewall.
  2. Fai clic su Crea nella barra delle azioni per iniziare a creare una nuova regola firewall.

  3. Nella pagina Dettagli regola firewall, compila le seguenti informazioni:

    1. Nel campo Nome, inserisci un nome valido per la regola firewall.
    2. Nella sezione Direzione del traffico, seleziona In entrata per consentire il traffico in entrata dai carichi di lavoro di altri progetti.
    3. Nella sezione Target, seleziona una delle seguenti opzioni:
      • Tutti i workload utente: consentono le connessioni ai workload del progetto che stai configurando.
      • Servizio:indica che questa regola firewall ha come target un servizio specifico all'interno del progetto che stai configurando.
    4. Se la destinazione è un servizio di progetto, seleziona il nome del servizio dall'elenco dei servizi disponibili nel menu a discesa Servizio.
    5. Nella sezione Da, seleziona una delle seguenti due opzioni:
      • Tutti i progetti:consente le connessioni dai carichi di lavoro in tutti i progetti della stessa organizzazione.
      • Un altro progetto e Tutti i workload utente:consentono le connessioni dai workload in un altro progetto della stessa organizzazione.
    6. Se vuoi trasferire i carichi di lavoro solo da un altro progetto, seleziona un progetto a cui puoi accedere dall'elenco dei progetti nel menu a discesa ID progetto.
    7. Se la destinazione sono tutti i carichi di lavoro utente, seleziona una delle seguenti opzioni nella sezione Protocolli e porte:
      • Consenti tutto:consente le connessioni utilizzando qualsiasi protocollo o porta.
      • Protocolli e porte specificati:consentono le connessioni utilizzando solo i protocolli e le porte specificati nei campi corrispondenti per la regola firewall in entrata.

  4. Nella pagina Dettagli regola firewall, fai clic su Crea.

Ora hai consentito le connessioni da altri workload del progetto all'interno della stessa organizzazione. Dopo aver creato la regola firewall, questa è visibile in una tabella nella pagina Firewall.

API

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. Applica la norma:

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

Sostituisci GLOBAL_API_SERVER con il percorso kubeconfig del server API globale. Per saperne di più, vedi Server API globali e di zona. Se non hai ancora generato un file kubeconfig per il server API, consulta la sezione Accedi per i dettagli.

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. Applica la norma di reciprocità:

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

Ora le connessioni sono consentite da e verso PROJECT_1 e PROJECT_2.

Crea un criterio in uscita tra progetti

Quando concedi un criterio di traffico in entrata tra progetti per consentire ai carichi di lavoro di un progetto di accettare connessioni da carichi di lavoro di un altro progetto, questa azione concede anche il traffico di ritorno per gli stessi flussi. Pertanto, non hai bisogno di una policy di rete per il traffico in uscita tra progetti nel progetto originale.

Ad esempio, se crei un criterio che consente il traffico da PROJECT_1 a PROJECT_2 e la protezione dall'esfiltrazione di dati è disattivata, devi creare un criterio di ingresso in PROJECT_2 e un criterio di uscita in PROJECT_1. Tuttavia, i pacchetti di risposte sono esclusi dall'applicazione delle norme, pertanto non sono necessarie norme aggiuntive.

Segui questi passaggi per creare una nuova regola firewall e consentire il traffico in uscita dai carichi di lavoro in un progetto:

  1. Nella console GDC del progetto che stai configurando, vai a Networking > Firewall nel menu di navigazione per aprire la pagina Firewall.
  2. Fai clic su Crea nella barra delle azioni per iniziare a creare una nuova regola firewall.

  3. Nella pagina Dettagli regola firewall, compila le seguenti informazioni:

    1. Nel campo Nome, inserisci un nome valido per la regola firewall.
    2. Nella sezione Direzione del traffico, seleziona In uscita per indicare che questa regola del firewall controlla il traffico in uscita.
    3. Nella sezione Target, seleziona una delle seguenti opzioni:
      • Tutti i carichi di lavoro utente:consente le connessioni dai carichi di lavoro del progetto che stai configurando.
      • Servizio:indica che questa regola firewall ha come target un servizio specifico all'interno del progetto che stai configurando.
    4. Se la destinazione è un servizio di progetto, seleziona il nome del servizio dall'elenco dei servizi disponibili nel menu a discesa Servizio.
    5. Nella sezione A, seleziona una delle seguenti due opzioni:
      • Tutti i progetti:consente le connessioni ai carichi di lavoro in tutti i progetti della stessa organizzazione.
      • Un altro progetto e Tutti i workload utente:consentono le connessioni ai workload in un altro progetto della stessa organizzazione.
    6. Se vuoi trasferire i carichi di lavoro solo a un altro progetto, seleziona un progetto a cui puoi accedere dall'elenco dei progetti nel menu a discesa ID progetto.
    7. Se la destinazione sono tutti i carichi di lavoro utente, seleziona una delle seguenti opzioni nella sezione Protocolli e porte:
      • Consenti tutto:consente le connessioni utilizzando qualsiasi protocollo o porta.
      • Protocolli e porte specificati:consentono le connessioni utilizzando solo i protocolli e le porte specificati nei campi corrispondenti per la regola firewall in uscita.

  4. Nella pagina Dettagli regola firewall, fai clic su Crea.

Ora hai consentito le connessioni ad altri workload del progetto all'interno della stessa organizzazione. Dopo aver creato la regola firewall, questa è visibile in una tabella nella pagina Firewall.

Crea un criterio tra progetti a livello di carico di lavoro

Le policy di rete a livello di workload offrono un controllo granulare sulla comunicazione tra i singoli workload nei vari progetti. Questa granularità consente un controllo più rigoroso dell'accesso alla rete, migliorando la sicurezza e l'utilizzo delle risorse.

Crea un criterio cross-project a livello di carico di lavoro in entrata

  • Per creare una policy tra progetti a livello di workload in entrata, crea e applica la seguente risorsa personalizzata:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
 namespace: PROJECT_1
 name: allow-cross-project-inbound-traffic-from-target-to-subject
spec:
 policyType: Ingress
 subject:
   subjectType: UserWorkload
   workloadSelector:
     matchLabels:
       SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
 ingress:
 - from:
   - projectSelector:
       projects:
         matchNames:
         - PROJECT_2
       workloads:
         matchLabels:
           TARGET_LABEL_KEY: TARGET_LABEL_VALUE
EOF

    Sostituisci quanto segue:

    • GLOBAL_API_SERVER: il percorso kubeconfig del server API globale. Per saperne di più, vedi Server API globali e di zona. Se non hai ancora generato un file kubeconfig per il server API, consulta la sezione Accedi per maggiori dettagli.
    • PROJECT_1: il nome del progetto che riceve il traffico.
    • PROJECT_2: il nome del progetto da cui proviene il traffico.
    • SUBJECT_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare i carichi di lavoro di origine. Ad esempio, app, tier o role.
    • SUBJECT_LABEL_VALUE: il valore associato a SUBJECT_LABEL_KEY. Specifica quali carichi di lavoro sono l'origine del traffico consentito. Ad esempio, se SUBJECT_LABEL_KEY è app e SUBJECT_LABEL_VALUE è backend, i carichi di lavoro con l'etichetta app: backend sono la sorgente di traffico.
    • TARGET_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare i carichi di lavoro di destinazione.
    • TARGET_LABEL_VALUE: il valore associato a TARGET_LABEL_KEY. Specifica quali carichi di lavoro sono la destinazione del traffico consentito.

Crea un criterio tra progetti a livello di carico di lavoro in uscita

  • Per creare un criterio tra progetti a livello di workload in uscita, crea e applica la seguente risorsa personalizzata:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-cross-project-outbound-traffic-to-subject-from-target
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
    workloadSelector:
      matchLabels:
        SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_2
        workloads:
          matchLabels:
            TARGET_LABEL_KEY: TARGET_LABEL_VALUE
EOF

    Sostituisci quanto segue:

    • GLOBAL_API_SERVER: il percorso kubeconfig del server API globale. Per saperne di più, vedi Server API globali e di zona. Se non hai ancora generato un file kubeconfig per il server API, consulta la sezione Accedi per maggiori dettagli.
    • PROJECT_1: il nome del progetto che invia il traffico.
    • PROJECT_2: il nome del progetto che riceve il traffico.
    • SUBJECT_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare i carichi di lavoro di origine. Ad esempio, app, tier o role.
    • SUBJECT_LABEL_VALUE: il valore associato a SUBJECT_LABEL_KEY. Specifica quali carichi di lavoro sono l'origine del traffico consentito. Ad esempio, se SUBJECT_LABEL_KEY è app e SUBJECT_LABEL_VALUE è backend, i carichi di lavoro con l'etichetta app: backend sono la sorgente di traffico.
    • TARGET_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare i carichi di lavoro di destinazione.
    • TARGET_LABEL_VALUE: il valore associato a TARGET_LABEL_KEY. Specifica quali carichi di lavoro sono la destinazione del traffico consentito.

Crea un criterio tra progetti a livello di workload per una singola zona

I criteri di rete a livello di workload possono applicare PNP lungo una singola zona. È possibile aggiungere etichette specifiche ai carichi di lavoro all'interno di una singola zona, consentendoti di controllare la comunicazione tra singoli carichi di lavoro all'interno di un progetto o in progetti diversi per quella zona.

Crea un criterio tra progetti a livello di carico di lavoro in entrata per una singola zona

  1. Per creare un criterio cross-project a livello di workload Ingress per una singola zona, crea e applica la seguente risorsa personalizzata:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-single-zone-cross-project-inbound-traffic-from-target-to-subject
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    workloadSelector:
      matchLabels:
        SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
        ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_2
        workloads:
          matchLabels:
            TARGET_LABEL_KEY: TARGET_LABEL_VALUE
            ZONE_TARGET_LABEL_KEY: ZONE_TARGET_LABEL_VALUE
EOF

    Sostituisci quanto segue:

    • GLOBAL_API_SERVER: il percorso kubeconfig del server API globale. Per saperne di più, vedi Server API globali e di zona. Se non hai ancora generato un file kubeconfig per il server API, consulta la sezione Accedi per maggiori dettagli.
    • PROJECT_1: il nome del progetto che riceve il traffico.
    • PROJECT_2: il nome del progetto da cui proviene il traffico.
    • SUBJECT_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare i carichi di lavoro di origine. Ad esempio, app, tier o role.
    • SUBJECT_LABEL_VALUE: il valore associato a SUBJECT_LABEL_KEY. Specifica quali carichi di lavoro sono l'origine del traffico consentito. Ad esempio, se SUBJECT_LABEL_KEY è app e SUBJECT_LABEL_VALUE è backend, i carichi di lavoro con l'etichetta app: backend sono la sorgente di traffico.
    • TARGET_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare i carichi di lavoro di destinazione.
    • TARGET_LABEL_VALUE: il valore associato a TARGET_LABEL_KEY. Specifica quali carichi di lavoro sono la destinazione del traffico consentito.
    • ZONE_SUBJECT_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare la zona di origine. Ad esempio, zone o region.
    • ZONE_SUBJECT_LABEL_VALUE: il valore associato a ZONE_SUBJECT_LABEL_KEY. Specifica la zona di origine del traffico consentito. Ad esempio, se ZONE_SUBJECT_LABEL_KEY è zone e ZONE_SUBJECT_LABEL_VALUE è us-central1-a, i carichi di lavoro con l'etichetta zone: us-central1-a sono la sorgente di traffico.
    • ZONE_TARGET_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare la zona di destinazione.
    • ZONE_TARGET_LABEL_VALUE: il valore associato a ZONE_TARGET_LABEL_KEY. Specifica la zona di destinazione del traffico consentito.

Crea un criterio tra progetti a livello di workload in uscita per una singola zona

  • Per creare una policy cross-project a livello di workload in uscita per una singola zona, crea e applica la seguente risorsa personalizzata:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-single-zone-cross-project-outbound-traffic-to-subject-from-target
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
    workloadSelector:
      matchLabels:
        SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
        ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_2
        workloads:
          matchLabels:
            TARGET_LABEL_KEY: TARGET_LABEL_VALUE
            ZONE_TARGET_LABEL_KEY: ZONE_TARGET_LABEL_VALUE
EOF

    Sostituisci quanto segue:

    • GLOBAL_API_SERVER: il percorso kubeconfig del server API globale. Per saperne di più, vedi Server API globali e di zona. Se non hai ancora generato un file kubeconfig per il server API, consulta la sezione Accedi per maggiori dettagli.
    • PROJECT_1: il nome del progetto che invia il traffico.
    • PROJECT_2: il nome del progetto che riceve il traffico.
    • SUBJECT_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare i carichi di lavoro di origine. Ad esempio, app, tier o role.
    • SUBJECT_LABEL_VALUE: il valore associato a SUBJECT_LABEL_KEY. Specifica quali carichi di lavoro sono l'origine del traffico consentito. Ad esempio, se SUBJECT_LABEL_KEY è app e SUBJECT_LABEL_VALUE è backend, i carichi di lavoro con l'etichetta app: backend sono la sorgente di traffico.
    • TARGET_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare i carichi di lavoro di destinazione.
    • TARGET_LABEL_VALUE: il valore associato a TARGET_LABEL_KEY. Specifica quali carichi di lavoro sono la destinazione del traffico consentito.
    • ZONE_SUBJECT_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare la zona di origine. Ad esempio, zone o region.
    • ZONE_SUBJECT_LABEL_VALUE: il valore associato a ZONE_SUBJECT_LABEL_KEY. Specifica la zona di origine del traffico consentito. Ad esempio, se ZONE_SUBJECT_LABEL_KEY è zone e ZONE_SUBJECT_LABEL_VALUE è us-central1-a, i carichi di lavoro con l'etichetta zone: us-central1-a sono la sorgente di traffico.
    • ZONE_TARGET_LABEL_KEY: la chiave dell'etichetta utilizzata per selezionare la zona di destinazione.
    • ZONE_TARGET_LABEL_VALUE: il valore associato a ZONE_TARGET_LABEL_KEY. Specifica la zona di destinazione del traffico consentito.