Usa flujos de trabajo de emergencia

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

Descripción general

La autorización binaria proporciona seguridad de la cadena de suministro de software mediante la administración de si GKE puede implementar una imagen de contenedor. En ocasiones, debes forzar la implementación de una imagen de contenedor que, por lo general, el ejecutor de la autorización binaria bloquería. En estos casos, la autorización binaria proporciona una característica conocida como flujo de trabajo de emergencia. Para omitir las restricciones de la política y permitir las implementaciones de imágenes, debes anotar la definición del pod con una marca de política break-glass.

Los flujos de trabajo de emergencia proporcionan una vía de escape de emergencia que te permite anular la aplicación de la política de la autorización binaria y permite que se implemente una imagen de contenedor, incluidas aquellas que la política no permitiría.

Por último, los procedimientos de emergencia registran de forma automática el evento de emergencia en Cloud Logging. En Cloud Logging, puedes auditar de forma manual o activar de manera automática una alerta o algún otro evento posterior.

Demuestra un evento de emergencia

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

Si bien los flujos de trabajo de emergencia son específicos de la autorización binaria, requiere que se actualice la anotación en una especificación de pod.

Si deseas actualizar la política a fin de rechazar todas las solicitudes de implementación de una imagen de contenedor, sigue estos pasos:

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

    Ir a la página Autorización binaria

  2. Haz clic en Editar política.

  3. Configura la regla predeterminada del proyecto como Deny All:

En la página Editar política, en Regla predeterminada del proyecto, haz clic en Inhabilitar todas las imágenes.

  1. Haz clic en Guardar política.

Intenta implementar una imagen de contenedor

  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: pod-name
    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
    

    Ten en cuenta el siguiente error: Error from server (Forbidden): error when creating "/tmp/create_pod.yaml": pods "pod-name" is forbidden: image policy webhook backend denied one or more images: Denied by default admission rule. Overridden by evaluation mode.

Habilita los flujos de trabajo de emergencia y vuelve a implementar

  1. Crea un archivo de configuración en formato YAML. Ahora, en este archivo se incluye la anotación de emergencia, así como otra información necesaria para crear el pod:

    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 los flujos de trabajo de emergencia en Cloud Logging

  1. Ve a la página Visor de Cloud Logging:

    Ir a la página Visor de registros

  2. Selecciona Clúster de Kubernetes en la lista Recursos.

  3. Selecciona el intervalo de tiempo en el selector de intervalo de tiempo.

  4. Copia lo siguiente y pégalo en el cuadro de búsqueda:

    imagepolicywebhook.image-policy.k8s.io/break-glass
    

    Los registros que se muestran se pueden expandir para revelar información sobre el evento de implementación de flujos de trabajo de emergencia.

Borra el pod para realizar una limpieza:

kubectl delete -f /tmp/create_pod.yaml

y verifica que hayas recibido resultados como el que se muestra a continuación: pod "pod-name" deleted