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) air-gapped.

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 di 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, questi criteri si applicano a livello globale in tutte le zone. Per saperne di più sulle risorse globali in un universo GDC, consulta Panoramica multizona.

Per applicare il 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 le policy di rete per il traffico tra progetti, devi disporre di quanto segue:

  • 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 policy che si estendono a tutte le zone, devi disporre del ruolo global-project-networkpolicy-admin. Per saperne di più, consulta Prepara ruoli e accesso predefiniti.
  • Un progetto esistente. Per saperne di più, consulta Creare un progetto.
  • Per i criteri di rete in uscita, devi anche disattivare la protezione dall'esfiltrazione di dati per il progetto.

Crea una policy tra progetti

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

Crea una policy in entrata tra progetti

Per consentire le connessioni ai servizi o ai carichi di lavoro del tuo progetto da carichi di lavoro in un altro progetto all'interno della tua organizzazione, devi configurare una regola firewall in entrata.

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

Per creare un criterio di ingresso reciproco nell'altra direzione, visita la console GDC dell'altro progetto e ripeti la procedura.

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 policy:

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 una policy di traffico in entrata tra progetti per consentire ai carichi di lavoro in un progetto di accettare connessioni da carichi di lavoro in 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.

Segui questi passaggi per creare una nuova regola firewall e consentire il traffico in uscita dai carichi di lavoro in un 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. Nella barra delle azioni, fai clic su Crea per 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.

Per creare una policy di uscita reciproca nell'altra direzione, visita la console GDC dell'altro progetto e ripeti la procedura.

API

La seguente policy consente ai workload nel progetto PROJECT_1 di consentire le connessioni ai workload nel progetto PROJECT_2. Applica la policy:

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

Il comando precedente consente le connessioni in uscita da PROJECT_1 a PROJECT_2, ma non consente le connessioni da PROJECT_2 a PROJECT_1. Per quest'ultimo, è necessaria una norma 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-outbound-traffic-to-PROJECT_1
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_1
EOF

Crea un criterio tra progetti a livello di workload

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 in entrata tra progetti a livello di workload

  • 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 una policy interprogetto 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 workload all'interno di una singola zona, consentendoti di controllare la comunicazione tra singoli workload all'interno di un progetto o in progetti diversi per quella zona.

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

  1. Per creare una policy 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.