Se usó la API de Cloud Translation para traducir esta página.

Configura el acceso restringido para los clústeres privados de GKE

En este documento, se describe cómo configurar entradas de DNS para enrutar solicitudes a los dominios pkg.dev y gcr.io con una IP virtual restringida (VIP) cuando usar clústeres privados de Google Kubernetes Engine en los Controles del servicio de VPC en ese perímetro de servicio.

Estos dominios de registro normalmente resuelven una dirección IP pública en la a Internet. En los clústeres privados de GKE, los nodos están aislados de Internet de forma predeterminada. Esto significa que las solicitudes a los registros fallarán si no configuraste el enrutamiento de DNS a la VIP restringida.

Tus clústeres privados siempre deben acceder a Artifact Registry o Container Registry con la VIP restringida para evitar el robo de datos desde un servicio admitido una no compatible.

Estos pasos solo son necesarios en los siguientes casos:

Estás usando clústeres privados de GKE.
Aún no configuraste el enrutamiento de los dominios de registro pkg.dev o gcr.io a restricted.googleapis.com.

Antes de comenzar

Antes de crear un perímetro de servicio, configura un clúster privado nuevo o identifica los clústeres privados existentes que deseas proteger.

Además, debes permitir la salida a 199.36.153.4/30 en el puerto 443. Por lo general, una red de VPC tiene una regla implícita que permite todo el tráfico de salida a cualquier destino. Sin embargo, si tienes una regla que rechaza dicho tráfico, debes crear una regla de firewall de salida para permitir el tráfico de TCP en el puerto 443 a 199.36.153.4/30.

Configura DNS

Configura tu servidor DNS para que las solicitudes a direcciones de registro se resuelvan en restricted.googleapis.com, la VIP restringida. Puedes hacerlo mediante Zonas de DNS privadas de Cloud DNS.

Crea una zona privada administrada.
```
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
```
En el ejemplo anterior, se ilustra lo siguiente:
- ZONE_NAME es un nombre para la zona que estás creando. Por ejemplo, registry. Este nombre se usará en cada uno de los siguientes pasos.
- PROJECT_ID es el ID del proyecto que aloja el clúster privado de GKE.
- NETWORK es una lista opcional de nombres de la red del clúster de la que deseas redireccionar las solicitudes.
- DESCRIPTION es una descripción legible de la zona administrada.
- REGISTRY_DOMAIN es el dominio de tu registro:
  - pkg.dev para Artifact Registry
  - gcr.io para Container Registry o Repositorios de gcr.io alojados en Artifact Registry
Inicia una transacción.
```
gcloud dns record-sets transaction start \
  --zone=ZONE_NAME \
  --project=PROJECT_ID
```
En el ejemplo anterior, se ilustra lo siguiente:
- ZONE_NAME es el nombre de la zona que creaste en el primer paso.
- PROJECT_ID es el ID del proyecto que aloja el clúster privado de GKE.
Agrega un registro CNAME en tu registro.
```
gcloud dns record-sets transaction add \
  --name=*.REGISTRY_DOMAIN. \
  --type=CNAME REGISTRY_DOMAIN. \
  --zone=ZONE_NAME \
  --ttl=300 \
  --project=PROJECT_ID
```
En el ejemplo anterior, se ilustra lo siguiente:
- ZONE_NAME es el nombre de la zona que creaste en el primer paso.
- PROJECT_ID es el ID del proyecto que aloja el clúster privado de GKE.
- REGISTRY_DOMAIN es el dominio de tu registro:
  - pkg.dev para Artifact Registry
  - gcr.io para Container Registry o repositorios de gcr.io alojados en Artifact Registry
Agrega un registro A para la VIP restringida.
```
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
```
En el ejemplo anterior, se ilustra lo siguiente:
- ZONE_NAME es el nombre de la zona que creaste en el primer paso.
- PROJECT_ID es el ID del proyecto que aloja el clúster privado de GKE.
- REGISTRY_DOMAIN es el dominio de tu registro:
  - pkg.dev para Artifact Registry
  - gcr.io para Container Registry o Repositorios de gcr.io alojados en Artifact Registry
Ejecuta la transacción.
```
gcloud dns record-sets transaction execute \
  --zone=ZONE_NAME \
  --project=PROJECT_ID
```
En el ejemplo anterior, se ilustra lo siguiente:
- ZONE_NAME es el nombre de la zona que creaste en el primer paso.
- PROJECT_ID es el ID del proyecto que aloja el clúster privado de GKE.

Después de configurar el enrutamiento de DNS, asegúrate de que GKE, el registro y otros servicios necesarios estén dentro del perímetro de servicio de los Controles del servicio de VPC. Para configurar tu perímetro de servicio, consulta los siguientes vínculos: sección.

Configura el perímetro de servicio

Después de configurar los registros DNS, haz lo siguiente: crear un nuevo perímetro de servicio o actualizar un perímetro existente y, luego, agregar el servicio de Container Registry o Artifact Registry a la lista de servicios que quieres proteger con el perímetro de servicio.

Además, tenga en cuenta lo siguiente:

Agrega otros servicios compatibles que uses con el registro al perímetro de servicio, como Cloud Build, Artifact Analysis y la Autorización Binaria.
Para Container Registry, también debes agregar Cloud Storage al servicio perímetro de servicio.

Verifica si el perímetro funciona

Después de configurar el perímetro de servicio, los nodos Los clústeres privados de GKE pueden acceder a las imágenes de contenedor en Artifact Registry y Container Registry si las imágenes se almacenan en proyectos que se encuentran en tu en ese perímetro de servicio.

Las imágenes de contenedor de proyectos fuera del perímetro permanecen inaccesibles, excepto para algunos repositorios públicos específicos de solo lectura.

Por ejemplo, si el proyecto google-samples no está en tu perímetro de servicio, ejecutando el comando para crear una implementación a partir del contenedor hello-app fallará:

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

Verifica el estado del Pod con el siguiente comando:

kubectl get pods

El comando muestra una tabla similar al siguiente ejemplo. El estado del Pod ErrImagePull indica que la extracción falló.

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

Puedes usar el comando kubectl describe pod para ver más detalles sobre la implementación. En el Pod del ejemplo anterior, el comando es el siguiente:

kubectl describe pod hello-server-dbd86c8c4-h5wsf