Puntos de control
Create a Kubernetes Cluster with Binary Authorization
/ 20
Update Binary Authorization Policy to add Disallow all images rule at project level and allow at cluster level
/ 10
Update cluster specific policy to Disallow all images
/ 10
Create a Nginx pod to verify cluster admission rule is applied for disallow all images (denies to create)
/ 10
Update BA policy to denying images except from whitelisted container registries (your project container registry)
/ 10
Update BA policy to modify cluster specific rule to allow only images that have been approved by attestors
/ 20
Tear Down (delete cluster)
/ 20
Seguridad de Google Kubernetes Engine: Autorización binaria
- GSP479
- Descripción general
- Arquitectura
- Configuración
- Tarea 1. Copia los recursos
- Tarea 2. Establece la versión predeterminada del clúster
- Tarea 3. Pasos para la implementación
- Tarea 4. Validación
- Tarea 5. Usa Autorización Binaria
- Tarea 6. Crea una imagen de GCR privada
- Tarea 7. Inhabilita todas las imágenes
- Tarea 8. Inhabilita las imágenes, excepto aquellas de los registros de contenedores que figuran en la lista de entidades permitidas
- Tarea 9. Aplica certificaciones
- Tarea 10. "Firma" una imagen de contenedor
- Tarea 11: Ejecuta una imagen con la función de aplicación de certificación habilitada
- Tarea 12: Maneja situaciones de emergencia
- Tarea 13: Eliminación
- Soluciona problemas en tu propio entorno
- Materiales relevantes
- ¡Felicitaciones!
GSP479
Descripción general
Una de las principales preocupaciones de seguridad al ejecutar clústeres de Kubernetes es saber qué imágenes de contenedor se ejecutan en cada Pod y poder dar cuenta de su origen. Establecer la "procedencia del contenedor" significa tener la capacidad de realizar un seguimiento de la fuente de un contenedor hasta un punto de origen confiable y garantizar que tu organización siga los procesos deseados durante la creación del artefacto (contenedor).
Las siguientes son algunas de las inquietudes principales:
- Origen seguro: ¿Cómo garantizas que todas las imágenes de contenedor que se ejecutan en el clúster provengan de una fuente aprobada?
- Coherencia y validación: ¿Cómo garantizas que se hayan completado de forma correcta todos los pasos de validación deseados para cada compilación y cada implementación de un contenedor?
- Integridad: Una vez probada su procedencia, ¿cómo garantizas que no se hayan modificado los contenedores antes de su ejecución?
Desde el punto de vista de la seguridad, no aplicar controles en relación con el origen de las imágenes presenta varios riesgos:
- Si no se aplican controles, un actor malicioso que haya comprometido un contenedor podría obtener privilegios de clúster suficientes para lanzar otros contenedores desde una fuente desconocida.
- Un usuario autorizado con permisos para crear Pods podría ejecutar un contenedor no deseado directamente dentro de un clúster, por accidente o de forma malintencionada.
- Un usuario autorizado podría reemplazar, por accidente o de forma malintencionada, una etiqueta de imagen de Docker por un contenedor funcional con un código no deseado agregado silenciosamente. En este caso, Kubernetes extraería e implementaría el contenedor de forma automática como parte de una implementación.
Para ayudar a los operadores de sistemas a evitar estos problemas, Google Cloud ofrece una función llamada Autorización binaria. Es un servicio administrado por Google Cloud que trabaja estrechamente con GKE para aplicar controles de seguridad en el momento de la implementación a fin de garantizar que solo se implementen imágenes de contenedor confiables. Con la Autorización binaria, puedes incluir registros de contenedores en la lista de entidades permitidas, exigir que autoridades confiables firmen las imágenes y aplicar esas políticas de manera centralizada. Aplicar esta política permite ejercer un mayor control sobre tu entorno de contenedores, ya que te asegurarás de que solo se integren las imágenes aprobadas o verificadas al proceso de compilación y actualización.
En este lab, implementaremos un clúster de Kubernetes Engine con la función de Autorización binaria habilitada, demostraremos cómo incluir registros de contenedores aprobados en la lista de entidades permitidas y explicaremos el proceso de creación y ejecución de un contenedor con firma.
Los ingenieros de GKE Helmsman crearon este lab para ayudarte a comprender mejor la Autorización binaria de GKE. Te invitamos a hacer cualquier aporte que creas conveniente.
Arquitectura
Las API de Binary Authorization y Container Analysis se basan en los proyectos de código abierto Grafeas y Kritis.
- Grafeas define una especificación de API para administrar metadatos sobre recursos de software, como imágenes de contenedor, imágenes de máquinas virtuales (VM), archivos JAR y secuencias de comandos. Puedes utilizar Grafeas para definir y agregar información sobre los componentes de tu proyecto.
- Kritis define una API para garantizar que se evite una implementación a menos que el artefacto (imagen de contenedor) cumpla con la política central y, de manera opcional, tenga las certificaciones necesarias.
En una canalización de implementación de contenedores simplificada como esta:
El contenedor transita 4 pasos como mínimo:
- El código fuente para crear el contenedor se almacena en el control de origen.
- Cuando se confirma un cambio en el control de origen, se compila y se prueba el contenedor.
- Si se completan los pasos de compilación y prueba, el artefacto de imagen de contenedor se coloca en un registro central de Container Registry, listo para su implementación.
- Cuando se envíe una implementación de esa versión del contenedor a la API de Kubernetes, el entorno de ejecución del contenedor extraerá esa imagen de Container Registry y la ejecutará como un Pod.
En la canalización de compilación de contenedores, existe la posibilidad de insertar procesos adicionales para indicar o "certificar" que se completó cada paso correctamente. Estos son algunos ejemplos: ejecución de pruebas de unidades, verificaciones de análisis de control de origen, análisis de vulnerabilidad, entre otros. A cada paso se le podría otorgar la facultad o la "autoridad de certificación" para firmar una vez que se haya completado. Una "autoridad de certificación" es una persona o un sistema con la clave de PGP correcta y la capacidad de registrar la "certificación" con la API de Container Analysis.
Mediante el uso de claves de PGP por separado, diferentes personas, sistemas o pasos de compilación de la canalización podrían realizar cada paso de la certificación (1). Cada clave de PGP se asocia con una "nota de certificación" que se almacena en la API de Container Analysis. Cuando un paso de compilación "firma" una imagen, se firma un fragmento de metadatos JSON de esa imagen a través de PGP y se envía a la API como un "caso de nota".
Una vez que se haya creado la imagen de contenedor y se hayan almacenado las certificaciones necesarias de manera centralizada (2), pueden consultarse como parte de un proceso de decisiones de políticas. En este caso, cuando un controlador de admisión de Kubernetes recibe una solicitud a la API para crear (create
) o actualizar (update
) un Pod:
- Envía un webhook a la API de Binary Authorization para una decisión de políticas.
- A continuación, se consulta la política de autorización binaria.
- Si es necesario, también se consulta la API de Container Analysis sobre los casos de certificación necesarios.
- Si la imagen de contenedor cumple con la política, puede ejecutarse.
- Si la imagen de contenedor no cumple con la política, el cliente de la API recibe un error con un mensaje que describe por qué se evitó.
Configuración
Antes de hacer clic en el botón Comenzar lab
Lee estas instrucciones. Los labs son cronometrados y no se pueden pausar. El cronómetro, que comienza a funcionar cuando haces clic en Comenzar lab, indica por cuánto tiempo tendrás a tu disposición los recursos de Google Cloud.
Este lab práctico te permitirá realizar las actividades correspondientes en un entorno de nube real, no en uno de simulación o demostración. Para ello, se te proporcionan credenciales temporales nuevas que utilizarás para acceder a Google Cloud durante todo el lab.
Para completar este lab, necesitarás lo siguiente:
- Acceso a un navegador de Internet estándar (se recomienda el navegador Chrome)
- Tiempo para completar el lab: Recuerda que, una vez que comienzas un lab, no puedes pausarlo.
Cómo iniciar su lab y acceder a la consola de Google Cloud
-
Haga clic en el botón Comenzar lab. Si debe pagar por el lab, se abrirá una ventana emergente para que seleccione su forma de pago. A la izquierda, se encuentra el panel Detalles del lab que tiene estos elementos:
- El botón Abrir la consola de Google
- Tiempo restante
- Las credenciales temporales que debe usar para el lab
- Otra información para completar el lab, si es necesaria
-
Haga clic en Abrir la consola de Google. El lab inicia recursos y abre otra pestaña en la que se muestra la página de acceso.
Sugerencia: Ordene las pestañas en ventanas separadas, una junto a la otra.
Nota: Si ve el diálogo Elegir una cuenta, haga clic en Usar otra cuenta. -
Si es necesario, copie el nombre de usuario del panel Detalles del lab y péguelo en el cuadro de diálogo Acceder. Haga clic en Siguiente.
-
Copie la contraseña del panel Detalles del lab y péguela en el cuadro de diálogo de bienvenida. Haga clic en Siguiente.
Importante: Debe usar las credenciales del panel de la izquierda. No use sus credenciales de Google Cloud Skills Boost. Nota: Usar su propia Cuenta de Google podría generar cargos adicionales. -
Haga clic para avanzar por las páginas siguientes:
- Acepte los términos y condiciones.
- No agregue opciones de recuperación o autenticación de dos factores (esta es una cuenta temporal).
- No se registre para obtener pruebas gratuitas.
Después de un momento, se abrirá la consola de Cloud en esta pestaña.
Activa Cloud Shell
Cloud Shell es una máquina virtual que cuenta con herramientas para desarrolladores. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud. Cloud Shell proporciona acceso de línea de comandos a tus recursos de Google Cloud.
- Haz clic en Activar Cloud Shell en la parte superior de la consola de Google Cloud.
Cuando te conectes, habrás completado la autenticación, y el proyecto estará configurado con tu PROJECT_ID. El resultado contiene una línea que declara el PROJECT_ID para esta sesión:
gcloud
es la herramienta de línea de comandos de Google Cloud. Viene preinstalada en Cloud Shell y es compatible con la función de autocompletado con tabulador.
- Puedes solicitar el nombre de la cuenta activa con este comando (opcional):
-
Haz clic en Autorizar.
-
Ahora, el resultado debería verse de la siguiente manera:
Resultado:
- Puedes solicitar el ID del proyecto con este comando (opcional):
Resultado:
Resultado de ejemplo:
gcloud
, consulta la guía con la descripción general de gcloud CLI en Google Cloud.
Tarea 1. Copia los recursos
- Ahora, debes copiar los recursos necesarios para este lab ejecutando el siguiente comando:
- Ve al directorio de esta demostración:
Configura tu región y zona
Algunos recursos de Compute Engine se encuentran en regiones y zonas. Una región es una ubicación geográfica específica donde puedes ejecutar tus recursos. Cada región tiene una o más zonas.
Ejecuta el siguiente comando para configurar una región y zona para tu lab (puedes usar la región/zona más adecuada para tu caso):
Actualiza los permisos de los archivos
- Cambia los permisos de algunos archivos necesarios para este lab para que se puedan leer, escribir y ejecutar:
Tarea 2. Establece la versión predeterminada del clúster
- Cambia la variable GKE_VERSION de
create.sh
adefaultClusterVersion
, como se indica a continuación:
Tarea 3. Pasos para la implementación
- Para implementar el clúster, ejecuta el siguiente comando. Puedes cambiar el texto
my-cluster-1
por el nombre del clúster que deseas crear.
Se mostrará el siguiente mensaje cuando se complete la secuencia de comandos create
:
La secuencia de comandos hará lo siguiente:
- Habilitará las API necesarias en tu proyecto; específicamente,
container
,containerregistry
,containeranalysis
ybinaryauthorization
. - Creará un clúster de Kubernetes Engine nuevo en la Zona, VPC y red predeterminadas.
- Recuperará las credenciales de tu clúster para habilitar el uso de comandos de
kubectl
.
Puedes omitir las advertencias.
Tarea 4. Validación
- La siguiente secuencia de comandos validará que se haya implementado correctamente la demostración:
Si falla la secuencia de comandos, se mostrará el siguiente mensaje:
Y/o
Si pasa la secuencia de comandos, se mostrará el siguiente resultado:
Prueba la tarea completada
Haz clic en Revisar mi progreso para verificar la tarea realizada. Si creaste de forma correcta un clúster de Kubernetes con autorización binaria, verás una puntuación de evaluación.
Tarea 5. Usa Autorización Binaria
Administra la política de autorización binaria
Para acceder a la IU de configuración de la política de Autorización binaria, sigue estos pasos:
- En la consola de Google Cloud, navega a Seguridad > Autorización Binaria.
- Haz clic en Editar política.
gcloud
:
gcloud beta container binauthz policy export > policy.yaml
.policy.yaml
.gcloud beta container binauthz policy import policy.yaml
.La política que está editando corresponde a la “predeterminada” y se aplica a todos los clústeres de GKE del proyecto de Google Cloud, a menos que esté vigente una política específica del clúster.
Se recomienda crear políticas específicas para cada clúster y lograr una operación correcta (incluye registros en la lista de entidades permitidas según sea necesario) y, luego, usar la configuración “Inhabilitar todas las imágenes” para la política predeterminada a nivel de proyecto. Cualquier clúster nuevo en este proyecto necesitará su propia política específica del clúster.
- Luego de hacer clic en Configura la política, aparecerá lo siguiente. Haz clic en la flecha hacia abajo junto a Reglas de exención personalizadas para mostrarlas, como se indica a continuación:
La regla de la política predeterminada es Permitir todas las imágenes
. Esta regla se comporta como si no estuviera habilitada la autorización binaria en el clúster.
Si se cambia la regla predeterminada a Inhabilitar todas las imágenes
o Permitir solo las imágenes aprobadas por todos los certificadores que se indican a continuación
, se bloquearán las imágenes que no coincidan con las rutas de acceso de las imágenes de registro exentas o que no tengan las certificaciones requeridas, respectivamente.
A continuación, realizarás algunas modificaciones en la política:
-
Cambia la Regla predeterminada de tu proyecto a
Inhabilitar todas las imágenes
. -
Pulsa en Crear reglas específicas en la configuración adicional para implementaciones de GKE y Anthos.
-
Pulsa en Seleccionar clúster de GKE en el menú desplegable y haz clic en Cambiar.
-
En Reglas específicas del clúster de GKE, haz clic en Agregar regla específica.
-
En el campo Agrega una regla específica para el clúster de GKE, ingresa tu ubicación y el nombre del clúster con el formato
ubicación.nombredelclúster
. Por ejemplo.my-cluster-1 que corresponde a la zona y al nombre del clúster my-cluster-1
. -
Selecciona la regla predeterminada
Permitir todas las imágenes
para tu clúster. -
Haz clic en AGREGAR.
- Haz clic en Guardar política.
Prueba la tarea completada
Haz clic en Revisar mi progreso para verificar la tarea realizada. Si actualizaste correctamente la política de autorización binaria y agregaste la regla Inhabilitar todas las imágenes a nivel de proyecto y Permitir todas las imágenes a nivel de clúster, verás una puntuación de evaluación.
Tarea 6. Crea una imagen de GCR privada
-
Para simular una configuración real, crea una imagen de contenedor de GCR privada en tu proyecto.
-
Extrae el contenedor de
nginx
del proyectogcr.io/google-containers/nginx
y envíalo a tu repositorio de GCR sin modificaciones. -
En Cloud Shell, extrae el contenedor
latest
denginx
:
- Autentica Docker en el proyecto:
Cuando se te pregunte, Do you want to continue (Y/n)?
Ingresa Y
.
- Configura la variable de shell PROJECT_ID:
- Etiquétalo y envíalo al GCR del proyecto actual:
- Enumera la imagen nginx "privada" en tu repositorio de GCR:
Tarea 7. Inhabilita todas las imágenes
Para comprobar que la política de inhabilitación de imágenes funcionará según lo previsto, primero verifica que se aplique la regla allow
específica del clúster y que permita que se ejecuten todos los contenedores.
- Para hacer esto, lanza un solo Pod de
nginx
:
Deberías ver un mensaje que indique lo siguiente: pod/nginx created
.
- Enumera los Pods:
Resultado:
Si esto falla, verifica la región y el nombre del clúster otra vez y vuelve a intentarlo.
- Ahora, borra el siguiente Pod:
- A continuación, verifica que la política de autorización binaria pueda bloquear la ejecución de imágenes no deseadas en el clúster.
En la página Autorización binaria, haz clic en Editar política.
-
Haz clic en los tres puntos verticales a la derecha de tu regla específica del clúster de GKE y luego haz clic eneditar.
-
A continuación, selecciona
Inhabilitar todas las imágenes
y haz clic en Enviar.
Tu política debería ser similar a la siguiente:
- Por último, haz clic en Guardar política para aplicar los cambios.
Prueba la tarea completada
Haz clic en Revisar mi progreso para verificar la tarea realizada. Si actualizaste correctamente la política de autorización binaria a la regla Inhabilitar todas las imágenes a nivel de clúster, verás una puntuación de evaluación.
- A continuación, ejecuta el mismo comando que antes para crear el Pod de
nginx
estático:
Sin embargo, esta vez, deberías recibir un mensaje del servidor de la API que indique que la política impidió que este Pod se ejecutara correctamente:
Para poder ver cuándo la política de Autorización binaria bloquea todas las imágenes, ve a los registros de auditoría de GKE en Stackdriver y filtra los mensajes de error relacionados con esta actividad.
- En la consola de Google Cloud, navega hasta el menú de navegación > Logging > Explorador de registros.
- Propaga el Compilador de consultas con la siguiente información:
- Haz clic en Ejecutar consulta.
- Deberías ver errores correspondientes al bloqueo de ejecución del Pod de
nginx
.
Prueba la tarea completada
Haz clic en Revisar mi progreso para verificar la tarea realizada. Si verificaste correctamente la regla de admisión del clúster, verás una puntuación de evaluación.
Tarea 8. Inhabilita las imágenes, excepto aquellas de los registros de contenedores que figuran en la lista de entidades permitidas
-
Supongamos que, en realidad, deseas permitir que se ejecute solo ese contenedor de nginx. Para ello, lo más rápido es incluir en la lista de entidades permitidas el registro del que proviene.
-
Usarás el resultado del siguiente comando como la ruta de acceso de tu imagen:
-
Copia el resultado de la ruta de acceso de la imagen en tu búfer.
-
Ve al Menú de navegación > Seguridad > Autorización Binaria.
-
Edita la Política de Autorización Binaria, bajo Reglas de exención personalizadas, muestra las rutas de las imágenes, luego haz clic en Agregar un patrón de imagen.
-
Pega la ruta de acceso de la imagen que copiaste anteriormente y haz clic en Listo. En la siguiente imagen, se muestra un ejemplo de ruta de acceso.
- Haz clic en Guardar política y, luego, ejecuta lo siguiente:
Ahora deberías poder iniciar este Pod y comprobar que la inclusión de registros en la lista de entidades permitidas funciona correctamente.
- Ejecuta el siguiente comando para limpiar y prepararte para los siguientes pasos:
Prueba la tarea completada
Haz clic en Revisar mi progreso para verificar la tarea realizada. Si actualizaste correctamente la política de Autorización binaria para incluir el registro de contenedor en la lista de entidades permitidas, verás una puntuación de evaluación.
Tarea 9. Aplica certificaciones
Incluir registros de imágenes de contenedor en la lista de entidades permitidas es un buen punto de partida para evitar que se ejecuten imágenes de contenedor no deseadas dentro de un clúster, pero puedes hacer aún más para asegurarte de que el contenedor se haya compilado de forma correcta.
Puedes verificar de manera criptográfica que se aprobó la implementación de una imagen de contenedor determinada. Esto se logra mediante una "autoridad de certificación", que declara o certifica que se completó un determinado paso. Para esto, la autoridad de certificación usa una clave de PGP para firmar un fragmento de metadatos que describe el hash SHA256 de una imagen de contenedor y lo envía a un repositorio central de metadatos: la API de Container Analysis.
Más tarde, cuando el controlador de admisión valide si se permite la ejecución de una imagen de contenedor mediante la consulta de una política de autorización binaria que requiera que una imagen tenga certificaciones, verificará si la API de Container Analysis contiene los fragmentos firmados de metadatos que indican qué pasos se completaron. Con esa información, el controlador de admisión sabrá si debe permitir o denegar la ejecución de ese Pod.
A continuación, realiza una certificación manual de una imagen de contenedor. Asumirás la función de una autoridad de certificación humana y realizarás todos los pasos para firmar una imagen de contenedor, crear una política que requiera que las imágenes que se ejecutan dentro de tu clúster tengan una certificación y, luego, ejecutar correctamente esa imagen en un Pod.
Configura las variables necesarias
- Nombre y dirección de correo electrónico del certificador:
- ID de la nota de Container Analysis y descripción de la autoridad de certificación:
- Nombres de los archivos que crearán cargas útiles o solicitudes:
Crea una nota de certificación
El primer paso consiste en registrar la autoridad de certificación como una nota de Container Analysis con la API de Container Analysis. Primero, crea una nota ATTESTATION
y envíala a la API.
- Crea la carga útil de la nota
ATTESTATION
:
- Envía la nota
ATTESTATION
a la API de Container Analysis:
Deberías ver que el resultado del comando anterior muestra la nota que se creó, pero el siguiente comando también mostrará esta nota:
Crea una clave de firma de PGP
Dado que tu autoridad de certificación usa una clave de PGP para realizar la firma criptográfica de los metadatos de la imagen, crea una clave de PGP nueva y exporta la clave pública.
- Configura otra variable de shell:
- Crea la clave de PGP:
-
(Presiona Intro para usar una frase de contraseña vacía y confirmar la recepción de las advertencias).
-
Extrae la clave de PGP pública:
Registra el certificador en la API de Autorización Binaria
El paso siguiente consiste en crear el "certificador" en la API de Autorización Binaria y agregarle la clave de PGP pública.
- Crea el certificador en la API de Autorización Binaria:
- Agrega la clave de PGP al certificador:
- Indica el certificador que se acaba de crear:
El resultado debería ser similar al siguiente:
Tarea 10. "Firma" una imagen de contenedor
Los pasos anteriores solo se deben realizar una vez. A partir de ahora, este es el único paso que debe repetirse para cada imagen de contenedor nueva.
Ya se compiló y se encuentra disponible la imagen de nginx
en gcr.io/google-containers/nginx:latest
. Realiza las certificaciones manuales como si fuera tu propia imagen compilada por procesos propios y evita tener que compilarla.
- Establece algunas variables de shell:
- Obtén la huella digital de PGP:
- Obtén el resumen de SHA256 de la imagen de contenedor:
- Crea una carga útil de firma con formato JSON:
- Visualiza la carga útil de firma que se generó:
- "Firma" la carga útil con la clave de PGP:
- Visualiza la firma generada (mensaje de PGP):
- Crea la certificación:
- Visualiza la certificación que se acaba de crear:
Tarea 11: Ejecuta una imagen con la función de aplicación de certificación habilitada
El siguiente paso consiste en cambiar la política de Autorización Binaria para establecer que la certificación debe estar presente en todas las imágenes que no coincidan con los patrones incluidos en la lista de entidades permitidas.
- Para modificar la política de modo tal que exija certificación, ejecuta el siguiente comando y, luego, copia la ruta de acceso o el nombre completo de la autoridad de certificación:
- A continuación, edita la política de Autorización Binaria para modificar la regla específica del clúster de GKE con el comando
edit
.
Haz clic en los tres puntos que se encuentran junto al nombre de tu clúster y selecciona Editar para modificar las reglas específicas del clúster.
- Selecciona
Solicitar certificaciones (permitir solo imágenes verificadas por los siguientes certificadores)
en lugar deNo permitir ninguna imagen
en la ventana emergente.
- Después, haz clic en
Agregar certificadores
seguido deAgregar por ID de recurso del certificador
. Ingresa el contenido de tu portapapeles en el formato deprojects/${PROJECT_ID}/attestors/${ATTESTOR}
, luego haz clic en Agregar 1 certificador, después en Enviar y, finalmente, haz clic enGuardar política.
La política predeterminada aún debería tener la regla Inhabilitar todas las imágenes
, pero la regla específica del clúster debería requerir certificación.
- Ahora, obtén el resumen SHA256 más reciente de la imagen firmada de los pasos anteriores:
- Espera al menos 30 segundos desde el momento en que actualizaste la política de autorización binaria, ejecuta el Pod y comprueba que se realizó de forma correcta:
¡Felicitaciones! Ya certificaste manualmente una imagen de contenedor y aplicaste una política para esa imagen dentro de tu clúster de GKE.
Prueba la tarea completada
Haz clic en Revisar mi progreso para verificar la tarea realizada. Si actualizaste correctamente la política de autorización binaria para modificar la regla específica del clúster y permitir solo imágenes aprobadas por certificadores, verás una puntuación de evaluación.
Tarea 12: Maneja situaciones de emergencia
Desde la perspectiva de un usuario, la política de autorización binaria podría bloquear una imagen de forma incorrecta o podría producirse otro problema en el buen funcionamiento del webhook del controlador de admisión.
En este caso de "urgencia", existe una función de emergencia que aprovecha una anotación específica para indicarle al controlador de admisión que debe ejecutar el Pod y omitir la aplicación de la política.
Sin embargo, en este caso sus procedimientos de respuesta se pueden iniciar en cuestión de segundos después de que se produzca la actividad. Los registros están disponibles en Stackdriver:
- Para ejecutar un contenedor de
nginx
sin firma con la anotación de emergencia, ejecuta el siguiente comando:
-
En la consola de Google Cloud, ve al menú de navegación > Logging > página Explorador de registros.
-
Propaga el cuadro Compilador de consultas con la información de más abajo y haz clic en Ejecutar consulta.
resource.type="k8s_cluster" protoPayload.request.metadata.annotations."alpha.image-policy.k8s.io/break-glass"="true" -
Deberías ver eventos cuando el controlador de admisión permitió un Pod, ya que está presente la anotación. Desde este filtro, puedes crear un
Receptor
que envíe registros que coincidan con este filtro a un destino externo.
Tarea 13: Eliminación
Qwiklabs eliminará todos los recursos que creaste en este lab, pero es bueno saber cómo limpiar tu entorno.
- Con la siguiente secuencia de comandos, se destruirá el clúster de Kubernetes Engine:
Si, al comienzo del lab, creaste tu propio nombre de clúster, úsalo. En este ejemplo, se utilizó el nombre my-cluster-1
.
Las últimas líneas del resultado se verán así:
gcloud container clusters list
para realizar un seguimiento del progreso. Espera hasta que se elimine el clúster.
Prueba la tarea completada
Haz clic en Revisar mi progreso para verificar la tarea realizada. Si eliminaste correctamente tu clúster, verás una puntuación de evaluación.
Con los siguientes comandos, se eliminarán los recursos restantes.
- Borra la imagen de contenedor que se envió a GCR con el siguiente comando:
-
Si se te pregunta
Do you want to continue (Y/n)?
, ingresaY
. -
Borra el certificador con el siguiente comando:
- Borra la nota de Container Analysis con el siguiente comando:
Soluciona problemas en tu propio entorno
- Si actualizas la política de autorización binaria y rápidamente intentas lanzar un Pod o un contenedor nuevo, es posible que la política no tenga tiempo de aplicarse. Quizás debas esperar 30 segundos o más para que se active el cambio de política. Para volver a intentarlo, borra tu Pod con el comando
kubectl delete <nombredepod>
y vuelve a enviar el comando de creación de Pod. - Ejecuta el comando
gcloud container clusters list
para verificar el estado del clúster. - Si habilitas funciones adicionales, como
--enable-network-policy
,--accelerator
,--enable-tpu
o--enable-metadata-concealment
, es posible que debas agregar registros adicionales a la lista de entidades permitidas de tu política de Autorización binaria para que se puedan ejecutar estos Pods. Usakubectl describe pod <nombredelpod>
para encontrar la ruta de registro de la especificación de la imagen y agregarla a la lista de entidades permitidas con el formatogcr.io/example-registry/*
y guardar la política. - Si recibes errores sobre las cuotas, aumenta tu cuota en el proyecto. Obtén más información sobre cuotas de Recursos en la documentación de cuotas de recursos.
Materiales relevantes
- Cuotas de Google Cloud
- Registrarse en Google Cloud
- Google Cloud Shell
- Autorización binaria en GKE
- Notas de Container Analysis
- Controlador de admisión de Kubernetes
- Etapas de lanzamiento
¡Felicitaciones!
Finaliza la Quest
Este lab de autoaprendizaje forma parte de la Quest Google Kubernetes Engine Best Practices: Security de Qwiklabs. Una Quest es una serie de labs relacionados que forman una ruta de aprendizaje. Si completas esta Quest, obtendrás una insignia como reconocimiento por tu logro. Puedes hacer públicas tus insignias y agregar vínculos a ellas en tu currículum en línea o en tus cuentas de redes sociales.Inscríbete en esta Quest y obtén un crédito inmediato de finalización. Consulta el catálogo de Google Cloud Skills Boost para ver todas las Quests disponibles.
Realiza tu próximo lab
Continúa tu Quest con Cómo usar una política de red en Google Kubernetes Engine o consulta estas sugerencias:
- Cómo utilizar el control de acceso basado en funciones en Kubernetes Engine
- Cómo endurecer las configuraciones de clústeres de GKE predeterminadas
Última actualización del manual: 11 de octubre de 2023
Prueba más reciente del lab: 11 de octubre de 2023
Copyright 2024 Google LLC. Este software se proporciona tal como está, sin garantías ni declaraciones para ningún uso o propósito. El uso que hagas de él está sujeto a tu acuerdo con Google.