Questa pagina è stata tradotta dall'API Cloud Translation.

Configurare 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 (VIP) limitato quando utilizzi i cluster privati Google Kubernetes Engine in un perimetro di servizio VPC Service Controls.

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

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 una non supportata.

Questi passaggi sono obbligatori solo se:

Stai utilizzando cluster privati GKE.
Non hai ancora configurato il routing dei domini dei registry pkg.dev o gcr.io 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 l'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 una regola che nega questo traffico, devi 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 inrestricted.googleapis.com, il VIP con limitazioni. Puoi farlo utilizzando le zone DNS private di Cloud DNS.

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 ciascuno dei passaggi seguenti.
- PROJECT_ID è l'ID del progetto che ospita il tuo cluster GKE privato.
- 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
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 nella prima passaggio.
- PROJECT_ID è l'ID del progetto che ospita il tuo Cluster privato GKE.
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 nella prima passaggio.
- PROJECT_ID è l'ID del progetto che ospita il tuo 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
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 nella prima passaggio.
- PROJECT_ID è l'ID del progetto che ospita il tuo 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
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 nella prima 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 VPC Service Controls. Per configurare il perimetro di servizio, consulta quanto segue .

Configurazione del perimetro di servizio

Dopo aver configurato i record DNS, crea un nuovo perimetro di servizio o aggiorna un perimetro esistente, quindi aggiungi il servizio Container Registry o Artifact Registry all'elenco di servizi che vuoi proteggere utilizzando il perimetro di servizio.

Inoltre:

Aggiungi al perimetro del servizio altri servizi supportati che utilizzi con il registry, ad esempio Cloud Build, Artifact Analysis e Autorizzazione binaria.
Per Container Registry, devi aggiungere anche Cloud Storage al perimetro del servizio.

Verificare il funzionamento del perimetro

Dopo aver configurato il perimetro di servizio, i nodi in I cluster privati GKE possono accedere alle immagini container in Artifact Registry e Container Registry se le immagini sono archiviate in progetti all'interno perimetro di servizio.

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

Ad esempio, se il progetto google-samples non è nel perimetro del servizio, l'esecuzione del comando per creare un deployment dal contenitore 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 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 e deployment continuo. Per il pod nell'esempio precedente, il comando è:

kubectl describe pod hello-server-dbd86c8c4-h5wsf