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.devogcr.iodomini del registro arestricted.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.
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_IDDove:
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.devper Artifact Registrygcr.ioper Container Registry ogcr.iorepository ospitati in Artifact Registry
Avvia una transazione.
gcloud dns record-sets transaction start \ --zone=ZONE_NAME \ --project=PROJECT_IDDove:
ZONE_NAME è il nome della zona che hai creato nel primo passaggio.
PROJECT_ID è l'ID del progetto che ospita il cluster privato GKE.
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_IDDove:
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.devper Artifact Registrygcr.ioper Container Registry ogcr.iorepository 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_IDDove:
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.devper Artifact Registrygcr.ioper Container Registry ogcr.iorepository ospitati in Artifact Registry
Esegui la transazione.
gcloud dns record-sets transaction execute \ --zone=ZONE_NAME \ --project=PROJECT_IDDove:
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:
- Crea un nuovo perimetro di servizio o aggiorna un perimetro esistente.
- Aggiungi il servizio Container Registry o Artifact Registry all'elenco dei servizi che vuoi proteggere utilizzando il perimetro di servizio.
- Aggiungi al perimetro di servizio altri servizi supportati che utilizzi con il registro, come Cloud Build, Artifact Analysis e Autorizzazione binaria.
- 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