Configura l'accesso limitato per i cluster privati GKE

Questo documento descrive come configurare le voci DNS per instradare le richieste ai domini pkg.dev e gcr.io utilizzando un IP virtuale limitato (VIP) quando utilizzi cluster privati Google Kubernetes Engine in un perimetro di servizio Controlli di servizio VPC.

Questi domini di registro di solito si risolvono in un indirizzo IP pubblico su internet. Nei cluster privati GKE, i nodi sono isolati da internet per impostazione predefinita. Ciò significa che le richieste ai registry non andranno a buon fine se non hai configurato il routing DNS per il VIP con restrizioni.

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

Questi passaggi sono necessari solo se:

  • Stai utilizzando cluster privati GKE.
  • Non hai già configurato il routing dei domini del Registro di sistema pkg.dev o gcr.io su 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, è necessario consentire il traffico in uscita verso 199.36.153.4/30 sulla porta 443. Normalmente, una rete VPC ha una regola implicita che consente tutto il traffico in uscita verso qualsiasi destinazione. Tuttavia, se è presente una regola che nega questo tipo di traffico, devi creare una regola firewall in uscita per consentire il traffico TCP dalla porta 443 alla porta 199.36.153.4/30.

Configurazione del DNS

Configura il server DNS in modo che le richieste agli indirizzi del Registro di sistema vengano risolte in restricted.googleapis.com, il VIP con limitazioni. 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 è un nome per la zona che stai creando. Ad esempio, registry. Questo nome verrà utilizzato in ciascuno dei passaggi seguenti.

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

    • NETWORK è un elenco facoltativo di nomi della rete di cluster da cui vuoi reindirizzare le richieste.

    • DESCRIPTION è una descrizione leggibile della zona gestita.

    • REGISTRY_DOMAIN è il dominio del registry:

      • pkg.dev per Artifact Registry
      • gcr.io per Container Registry o repository gcr.io ospitati in Artifact Registry
  2. Avviare una transazione.

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

    Dove:

    • ZONE_NAME è il nome della zona creata nel primo passaggio.

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

  3. Aggiungi un record CNAME per il registro.

    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 creata nel primo passaggio.

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

    • REGISTRY_DOMAIN è il dominio del registry:

      • pkg.dev per Artifact Registry
      • gcr.io per Container Registry o repository gcr.io ospitati in Artifact Registry
  4. Aggiungere 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 creata nel primo passaggio.

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

    • REGISTRY_DOMAIN è il dominio del 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 creata nel primo passaggio.

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

Dopo aver configurato il routing DNS, assicurati che GKE, il Registro di sistema 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, crea un nuovo perimetro di servizio o aggiornane uno esistente, quindi aggiungi il servizio Container Registry o Artifact Registry all'elenco dei servizi da proteggere utilizzando il perimetro di servizio.

Inoltre:

  • Aggiungi al perimetro di servizio altri servizi supportati da utilizzare con il registry, come Cloud Build, Artifact Analysis e Autorizzazione binaria.
  • Per Container Registry, devi anche aggiungere Cloud Storage al perimetro di servizio.

Verifica del 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 tuo perimetro di servizio.

Le immagini container in progetti all'esterno del perimetro rimangono inaccessibili, ad eccezione di alcuni repository pubblici di sola lettura.

Ad esempio, se il progetto google-samples non è nel tuo perimetro di servizio, l'esecuzione del comando per creare un deployment dal container hello-app avrà esito negativo:

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 all'esempio seguente. 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