Usa la anulación de emergencia (GKE, clústeres de GKE)

Nota: En este documento o sección, se incluyen referencias a uno o más términos que Google considera ofensivos o irrespetuosos. Los términos se usan porque son palabras clave en el software que se describe en el documento.

Los términos: whitelist

En esta página, se proporcionan instrucciones sobre el uso de flujos de trabajo de emergencia con la autorización binaria.

Antes de comenzar

En esta guía se supone que configuraste la autorización binaria.

Descripción general

Usa los anulación de emergencia para implementar una imagen de contenedor que la autorización binaria bloquea.

La anulación de emergencia proporciona una vía de escape de emergencia que te permite anular la aplicación de la política de la autorización binaria para permitir que se implementen imágenes, incluso aquellas que la política no permitiría.

Esta función se implementa de manera coherente con las recomendaciones de la especificación del controlador de admisión de Kubernetes.

Cuando usas flujos de trabajo de emergencia para implementar una imagen, un evento de emergencia se registra de forma automática en los registros de auditoría de Cloud, sin importar si la implementación satisface o infringe la política. En los registros de auditoría de Cloud, puedes auditar de forma manual o activar de manera automática una alerta o algún otro evento posterior.

Para habilitar las anulaciones de emergencia, agrega un campo label a la especificación del pod con una marca de política break-glass.

Demuestra un evento de emergencia

En esta sección, se muestra cómo usar la anulación de emergencia para implementar imágenes, incluidas las que infringen la política de autorización binaria.

Actualiza la política de la autorización binaria para rechazar todas las solicitudes de implementación

Nota: Recomendamos que los siguientes pasos solo se realicen en un proyecto de prueba de Google Kubernetes Engine. Para demostrar un incumplimiento de política que genere que una imagen se bloquee de la implementación, las siguientes instrucciones actualizan la política de autorización binaria predeterminada y, además, inhabilitan todas las imágenes que se implementarán. Este procedimiento reemplaza tu política existente. Te recomendamos que guardes tu política existente antes de continuar.

Para actualizar la política a fin de inhabilitar la implementación de todas las imágenes, sigue estos pasos:

Consola de Google Cloud

1. Ve a la página Autorización binaria en la consola de Google Cloud.

   Ve a Autorización binaria

2. Haz clic en Editar política.

3. En la página Editar política, en Regla predeterminada del proyecto, observa el modo de evaluación original y, luego, haz clic en Inhabilitar todas las imágenes.

4. Haz clic en Guardar política.

gcloud

1. Para guardar la política existente en el proyecto actual, ejecuta el siguiente comando:

   gcloud container binauthz policy export > SAVE_POLICY_YAML
   

   Reemplaza SAVE_POLICY_YAML por la ruta del archivo de exportación, por ejemplo, /tmp/save_policy.yaml.

2. Crea un archivo de política:

   cat > TEST_POLICY_YAML << EOM
   admissionWhitelistPatterns:
   defaultAdmissionRule:
     enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
     evaluationMode: ALWAYS_DENY
   globalPolicyEvaluationMode: DISABLE
   EOM
   

   Reemplaza TEST_POLICY_YAML con una ruta de acceso de archivo, por ejemplo, /tmp/policy.yaml.

3. Importa la política:

   gcloud container binauthz policy import TEST_POLICY_YAML
   

   Reemplaza TEST_POLICY_YAML con una ruta de acceso de archivo, por ejemplo, /tmp/policy.yaml.

De forma predeterminada, no se puede implementar ninguna imagen ahora.

Intenta implementar una imagen

En esta sección, intentarás implementar una imagen. La regla predeterminada de la política se configura para impedir que se implementen todas las imágenes, por lo que la solicitud de implementación falla.

1. Crea un archivo de configuración en formato YAML. Este archivo contiene la información básica necesaria para crear el pod:

   cat > /tmp/create_pod.yaml << EOM
   apiVersion: v1
   kind: Pod
   metadata:
     name: breakglass-pod
   spec:
     containers:
     - name: container-name
       image: gcr.io/google-samples/hello-app@sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4
   EOM
   

2. Crea el Pod mediante kubectl:

   kubectl create -f /tmp/create_pod.yaml
   

   Verás un error que indica que tu política bloqueó la imagen. El error es similar al siguiente:

   Error from server (Forbidden): error when creating "/tmp/create_pod.yaml": pods "breakglass-pod" is forbidden: image policy webhook backend denied one or more images: Image gcr.io/google-samples/hello-app denied by Binary Authorization default
   admission rule. Denied by always_deny admission rule`.

Habilita los flujos de trabajo de emergencia y vuelve a implementar

En esta sección, habilitarás la anulación de emergencia. Aunque la anulación de emergencia es específicas de la autorización binaria, debes actualizar el campo label en la especificación del pod para habilitarla.

Para habilitar la anulación de emergencia, ejecuta los siguientes comandos:

1. Crea un archivo de configuración en formato YAML.

   El siguiente comando crea el archivo que contiene la etiqueta break-glass y otra información necesaria para crear el pod:

   cat > /tmp/create_pod.yaml << EOM
   apiVersion: v1
   kind: Pod
   metadata:
     name: pod-name
     labels:
       image-policy.k8s.io/break-glass: "true"
   spec:
     containers:
     - name: container-name
       image: gcr.io/google-samples/hello-app@sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4
   EOM
   

   Nota: Habilitar la anulación de emergencia en el nodo “etiquetas” de la especificación del pod funciona con las siguientes versiones de la instancia principal de Kubernetes:

   • 1.18.15 y posteriores
   • 1.19.7 y posteriores
   • 1.20.2 y posteriores

   Para todas las versiones principales de Kubernetes anteriores, puedes habilitar la anulación de emergencia si agregas alpha.image-policy.k8s.io/break-glass al nodo annotations, de la siguiente manera:

   cat > /tmp/create_pod.yaml << EOM
   apiVersion: v1
   kind: Pod
   metadata:
     name: pod-name
     annotations:
        alpha.image-policy.k8s.io/break-glass: "true"
   spec:
     containers:
     - name: container-name
       image: gcr.io/google-samples/hello-app@sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4
   EOM
   

2. Crea el Pod mediante kubectl:

   kubectl create -f /tmp/create_pod.yaml
   

   Toma nota del resultado: pod/pod-name created

Busca la entrada de registro de la anulación de emergencia en los registros de auditoría de Cloud

Visualiza los eventos de anulación de emergencia en los registros de auditoría de Cloud.

Limpia

Para borrar el Pod e inhabilitar la anulación de emergencia, haz lo siguiente:

1. Borra el Pod:

     kubectl delete -f /tmp/create_pod.yaml
     

   Verifica que hayas recibido un resultado como pod <var>pod-name</var> deleted.

2. Quita el bloquea label o annotations en la especificación del pod.

3. Restablece tu política:

   Consola de Google Cloud

   1. Ve a la página Autorización binaria en la consola de Google Cloud.

      Ve a Autorización binaria

   2. Haz clic en Editar política.

   3. En la página Editar política, en Regla predeterminada del proyecto, restablece el modo de evaluación a la configuración anterior.

   4. Haz clic en Guardar política.

   gcloud

   1. Vuelve a importar la política original.

        gcloud container binauthz policy import SAVE_POLICY_YAML
      

      Reemplaza SAVE_POLICY_YAML por la ruta de acceso al archivo que creaste antes en esta guía.

   Se restablecerá tu política.

¿Qué sigue?

• Visualiza los eventos de anulación de emergencia en los registros de auditoría de Cloud.