Configura l'accesso limitato per i cluster GKE privati

La configurazione del routing DNS a un IP virtuale (VIP) con limitazioni consente ai cluster privati di Google Kubernetes Engine di accedere ai repository Artifact Registry all'interno di un perimetro di servizio dei Controlli di servizio VPC.

Poiché i nodi del cluster privato sono isolati da internet e i domini del registry vengono risolti in indirizzi IP pubblici per impostazione predefinita, devi instradare le richieste per i domini pkg.dev e gcr.io tramite il VIP limitato.

Panoramica

I tuoi cluster privati devono sempre accedere ad Artifact Registry o Container Registry con il VIP limitato per impedire l'esfiltrazione di dati da un servizio supportato a uno non supportato.

Configura l'accesso limitato per i cluster privati GKE quando si verificano tutte le seguenti condizioni:

  • Stai utilizzando cluster GKE privati.
  • Non hai ancora configurato il routing dei domini del registry pkg.dev o gcr.io verso restricted.googleapis.com.

Prima di iniziare

Prima di creare un perimetro di servizio, configura un nuovo cluster privato o identifica i cluster privati esistenti che vuoi proteggere.

Inoltre, devi consentire il traffico in uscita verso 199.36.153.4/30 sulla porta 443. In genere, una rete VPC ha una regola implicita che consente tutto il traffico in uscita verso qualsiasi destinazione. Tuttavia, se hai una regola che nega questo traffico, devi creare una regola firewall in uscita per consentire il traffico TCP sulla porta 443 verso 199.36.153.4/30.

Configurazione del DNS

Configura il server DNS in modo che le richieste agli indirizzi del registry vengano risolte in restricted.googleapis.com, il VIP limitato. Puoi farlo utilizzando le zone DNS private di Cloud DNS.

  1. Crea una zona privata gestita.

    gcloud dns managed-zones create ZONE_NAME \
        --visibility=private \
        --networks=https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/NETWORK \
        --description=DESCRIPTION \
        --dns-name=REGISTRY_DOMAIN \
        --project=PROJECT_ID
    

    Dove:

    • ZONE_NAME è il nome della zona che stai creando. Ad esempio, registry. Questo nome verrà utilizzato in ognuno dei passaggi che seguono.
    • PROJECT_ID è l'ID del progetto che ospita il cluster privato GKE.
    • NETWORK è un elenco facoltativo di nomi della rete del cluster da cui vuoi reindirizzare le richieste.
    • DESCRIPTION è una descrizione leggibile della zona gestita.
    • REGISTRY_DOMAIN è il dominio del tuo registry:
      • pkg.dev per Artifact Registry
      • gcr.io per Container Registry o repository gcr.io ospitati in Artifact Registry
  2. Avvia una transazione.

    gcloud dns record-sets transaction start \
      --zone=ZONE_NAME \
      --project=PROJECT_ID
    

    Dove:

    • ZONE_NAME è il nome della zona che hai creato nel primo passaggio.

    • PROJECT_ID è l'ID del progetto che ospita il tuo cluster privato GKE.

  3. Aggiungi un record CNAME per il tuo registry.

    gcloud dns record-sets transaction add \
      --name=*.REGISTRY_DOMAIN. \
      --type=CNAME REGISTRY_DOMAIN. \
      --zone=ZONE_NAME \
      --ttl=300 \
      --project=PROJECT_ID
    

    Dove:

    • ZONE_NAME è il nome della zona che hai creato nel primo passaggio.
    • PROJECT_ID è l'ID del progetto che ospita il cluster privato GKE.
    • REGISTRY_DOMAIN è il dominio del tuo registry:
      • pkg.dev per Artifact Registry
      • gcr.io per Container Registry o repository gcr.io ospitati in Artifact Registry
  4. Aggiungi un record A per il VIP con limitazioni.

    gcloud dns record-sets transaction add \
      --name=REGISTRY_DOMAIN. \
      --type=A 199.36.153.4 199.36.153.5 199.36.153.6 199.36.153.7 \
      --zone=ZONE_NAME \
      --ttl=300 \
      --project=PROJECT_ID
    

    Dove:

    • ZONE_NAME è il nome della zona che hai creato nel primo passaggio.
    • PROJECT_ID è l'ID del progetto che ospita il cluster privato GKE.
    • REGISTRY_DOMAIN è il dominio del tuo registry:
      • pkg.dev per Artifact Registry
      • gcr.io per Container Registry o repository gcr.io ospitati in Artifact Registry
  5. Esegui la transazione.

    gcloud dns record-sets transaction execute \
      --zone=ZONE_NAME \
      --project=PROJECT_ID
    

    Dove:

    • ZONE_NAME è il nome della zona che hai creato nel primo passaggio.

    • PROJECT_ID è l'ID del progetto che ospita il tuo cluster privato GKE.

Dopo aver configurato il routing DNS, assicurati che GKE, il registry e gli altri servizi richiesti si trovino all'interno del perimetro di servizio dei Controlli di servizio VPC. Per configurare il perimetro di servizio, consulta la sezione seguente.

Configurazione del perimetro di servizio

Dopo aver configurato i record DNS, segui questi passaggi:

  1. Crea un nuovo perimetro di servizio o aggiorna un perimetro esistente.
  2. Aggiungi il servizio Container Registry o Artifact Registry all'elenco dei servizi che vuoi proteggere utilizzando il perimetro di servizio.
  3. Aggiungi altri servizi supportati che utilizzi con il registry al perimetro di servizio, ad esempio Cloud Build, Artifact Analysis e Autorizzazione binaria.
  4. Se devi accedere a Container Registry, devi anche aggiungere Cloud Storage al perimetro di servizio.

Verifica il funzionamento del perimetro

Dopo aver configurato il perimetro di servizio, i nodi nei cluster privati GKE possono accedere alle immagini container in Artifact Registry e Container Registry se le immagini sono archiviate in progetti che si trovano nel perimetro di servizio.

Le immagini container nei progetti esterni al perimetro rimangono inaccessibili, ad eccezione di alcuni repository pubblici di sola lettura specifici.

Ad esempio, se il progetto google-samples non si trova nel perimetro di servizio, l'esecuzione del comando per creare un deployment dal container hello-app non riuscirà:

Dominio pkg.dev

kubectl create deployment hello-server --image=us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

Dominio gcr.io

kubectl create deployment hello-server --image=gcr.io/google-samples/hello-app:1.0

Controlla lo stato del pod con il comando:

kubectl get pods

Il comando restituisce una tabella simile al seguente esempio. Lo stato del pod ErrImagePull indica che il pull non è riuscito.

NAME                            READY   STATUS         RESTARTS   AGE
hello-server-dbd86c8c4-h5wsf    1/1     ErrImagePull   0          45s

Puoi utilizzare il comando kubectl describe pod per visualizzare ulteriori dettagli sul deployment. Per il pod nell'esempio precedente, il comando è:

kubectl describe pod hello-server-dbd86c8c4-h5wsf