Configura l'accesso limitato per i cluster GKE privati

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

I domini del registro vengono normalmente risolti 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 domini del registro non andranno a buon fine se non hai configurato il routing DNS al VIP con limitazioni.

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

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

  • Stai utilizzando cluster privati GKE.
  • Non hai ancora configurato il routing dei pkg.dev o gcr.io domini del registro a 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 registro 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 ognuno dei passaggi seguenti.
    • 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 registro:
      • pkg.dev per Artifact Registry
      • gcr.io per Container Registry o gcr.io repository 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 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 che hai creato nel primo passaggio.
    • PROJECT_ID è l'ID del progetto che ospita il cluster privato GKE.
    • REGISTRY_DOMAIN è il dominio del registro:
      • pkg.dev per Artifact Registry
      • gcr.io per Container Registry o gcr.io repository 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 registro:
      • pkg.dev per Artifact Registry
      • gcr.io per Container Registry o gcr.io repository 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 cluster privato GKE.

Dopo aver configurato il routing DNS, assicurati che GKE, il registro 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:

  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 al perimetro di servizio altri servizi supportati che utilizzi con il registro, come Cloud Build, Artifact Analysis e Autorizzazione binaria.
  4. Se devi accedere a Container Registry, devi aggiungere anche 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 perimetro di servizio.

Le immagini container nei progetti al di fuori del 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 andrà a buon fine:

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 l'estrazione non è riuscita.

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