En esta página, se explica cómo implementar una imagen de contenedor en un clúster de GKE (en Google Cloud o Google Distributed Cloud) en el que está habilitada Autorización Binaria.
Los comandos de kubectl
que usas para implementar la imagen son los mismos que usas para implementar imágenes en clústeres que no usan Autorización Binaria.
Antes de comenzar
Asegúrate de tener la API de Autorización Binaria habilitada en tu proyecto y un clúster de GKE con Autorización Binaria habilitada. Consulta Configura en Google Kubernetes Engine o Configura en Distributed Cloud.
Instala kubectl
para interactuar con GKE.
Configurar kubectl
Debes actualizar el archivo local kubeconfig
de tu instalación de kubectl
.
Esto proporciona las credenciales y la información del extremo necesarias para acceder al clúster en GKE o Distributed Cloud.
Para configurar kubectl
, ejecuta el siguiente comando de gcloud
:
GKE
gcloud container clusters get-credentials \ --zone ZONE \ CLUSTER_NAME
Reemplaza lo siguiente:
- ZONE: el nombre de la zona de GKE en la que se ejecuta el clúster, por ejemplo,
us-central1-a
- CLUSTER_NAME: es el nombre del clúster
Distributed Cloud
gcloud container fleet memberships get-credentials \ --location LOCATION \ MEMBERSHIP_NAME
Reemplaza lo siguiente:
- LOCATION: la ubicación de la membresía de la flota del clúster de GKE, por ejemplo,
global
- MEMBERSHIP_NAME: el nombre de la membresía de la flota del clúster de GKE
Implementa la imagen de contenedor
Implementa tu imagen de contenedor de la siguiente manera:
Configure las variables de entorno:
POD_NAME=POD_NAME IMAGE_PATH=IMAGE_PATH IMAGE_DIGEST=IMAGE_DIGEST
Reemplaza lo siguiente:
- POD_NAME: es el nombre que deseas usar para la carga de trabajo de GKE
- IMAGE_PATH: es la ruta de acceso de la imagen en Artifact Registry, Container Registry o algún otro registro.
IMAGE_DIGEST: Es el resumen del manifiesto de la imagen. Estos son algunos ejemplos:
- Artifact Registry:
- Ruta de acceso:
us-docker.pkg.dev/google-samples/containers/gke/hello-app
- Resumen:
sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567
- Ruta de acceso:
- Container Registry:
- Ruta de acceso:
gcr.io/google-samples/hello-app
- Resumen:
sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4
- Ruta de acceso:
Si deseas aprender a obtener el resumen de una imagen en Artifact Registry, consulta Administra imágenes; para una imagen de Container Registry, consulta Enumera las versiones de una imagen.
- Artifact Registry:
Implementa la imagen con el comando
kubectl run
.Debes implementar la imagen con el resumen en lugar de una etiqueta como
1.0
olatest
, ya que la autorización binaria usa el resumen para buscar las certificaciones.Para implementar la imagen, ejecuta el siguiente comando de
kubectl
:kubectl run ${POD_NAME} \ --image ${IMAGE_PATH}@${IMAGE_DIGEST}
Ahora, verifica que la autorización binaria haya bloqueado la implementación:
kubectl get pods
Verás el Pod en la lista.
Fail open
Si GKE no puede alcanzar al servidor de Autorización Binaria por algún motivo o si el servidor devuelve un error, GKE no puede determinar si la autorización binaria permitiría o rechazaría la imagen. En este caso, GKE falla abierta: permite la implementación predeterminada de la imagen, pero crea una entrada de registro en los registros de auditoría de Cloud para dejar asentado por qué se permitió la imagen.
La aplicación de GKE falla cuando se abre debido a una compensación entre la confiabilidad y la seguridad. GKE envía una solicitud a la autorización binaria cada vez que se crea o se actualiza un Pod. Esto incluye situaciones en las que los controladores de cargas de trabajo de Kubernetes de nivel superior crean o actualizan los pods automáticamente, como ReplicaSets y StatefulSets. Si GKE falló en lugar de abrirse, cualquier interrupción de la autorización binaria evitaría la ejecución de estos Pods. Además, cuando se rechazan los Pods, la conmutación por error puede generar fallas en cascada, ya que el tráfico redireccionado sobrecarga a los Pods que aún se están ejecutando. Cualquier interrupción de la autorización binaria podría activar una interrupción completa para el clúster, incluso sin implementar imágenes nuevas.
Implementa imágenes que infrinjan la política
Autorización Binaria admite una función conocida como anulación de emergencia que permite que se implemente una imagen, incluso si infringe la política.
Para obtener más información, consulta Usa flujos de trabajo de emergencia
Realiza una limpieza
Para limpiar, ejecuta el siguiente comando para borrar el Pod:
kubectl delete pod ${POD_NAME}
¿Qué sigue?
- Obtén información sobre el modo de ejecución de prueba.
- Obtén información sobre cómo usar la CV.
- Obtén más información para usar la validación continua heredada (obsoleta).
- Aprende a usar resúmenes de imágenes en manifiestos de Kubernetes.