GSP496

Descripción general

Este lab expone algunas de las preocupaciones de seguridad de la configuración predeterminada de un clúster de GKE y las medidas de endurecimiento correspondientes para prevenir las múltiples rutas de escape de Pods y la elevación de privilegios del clúster. Estas rutas de ataque son importantes en las siguientes situaciones:

1. Una falla de la aplicación en un Pod externo que permite ataques de falsificación de solicitudes del servidor (SSRF)
2. Un contenedor completamente vulnerado dentro de un Pod que permite la ejecución remota de comandos (RCE)
3. Un usuario interno malicioso o un atacante con un conjunto de credenciales de usuario interno vulneradas que tiene la capacidad de crear/actualizar un Pod en un espacio de nombres determinado

Los ingenieros de GKE Helmsman crearon este lab para ayudarte a comprender mejor el endurecimiento de los parámetros de configuración predeterminados de los clústeres de GKE.

El código de ejemplo para este lab se proporciona sin modificaciones ni garantías

Objetivos

Cuando finalices el lab, comprenderás la necesidad de proteger los metadatos de las instancias de GKE y definir políticas de PodSecurityPolicy en tu entorno.

Realizarás lo siguiente:

1. Crearás un clúster de GKE pequeño con la configuración predeterminada.
2. Validarás las rutas de escape de Pods más comunes y la elevación de privilegios del clúster desde la perspectiva de un usuario interno malicioso.
3. Endurecerás el clúster de GKE para prevenir estos problemas.
4. Validarás el clúster para que ya no se permitan esas acciones.

Configuración y requisitos

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)

Nota: Usa una ventana de navegador privada o de Incógnito para ejecutar este lab. Así evitarás cualquier conflicto entre tu cuenta personal y la cuenta de estudiante, lo que podría generar cargos adicionales en tu cuenta personal.

• Tiempo para completar el lab: Recuerda que, una vez que comienzas un lab, no puedes pausarlo.

Nota: Si ya tienes un proyecto o una cuenta personal de Google Cloud, no los uses en este lab para evitar cargos adicionales en tu cuenta.

Cómo iniciar tu lab y acceder a la consola de Google Cloud

1. 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 Cloud
   • El tiempo restante
   • Las credenciales temporales que debe usar para el lab
   • Otra información para completar el lab, si es necesaria

2. Haz clic en Abrir la consola de Google Cloud (o haz clic con el botón derecho y selecciona Abrir el vínculo en una ventana de incógnito si ejecutas el navegador Chrome).

   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 ves el diálogo Elegir una cuenta, haz clic en Usar otra cuenta.

3. De ser necesario, copia el nombre de usuario a continuación y pégalo en el diálogo Acceder.

   {{{user_0.username | "Username"}}}

   También puedes encontrar el nombre de usuario en el panel Detalles del lab.

4. Haz clic en Siguiente.

5. Copia la contraseña que aparece a continuación y pégala en el diálogo Te damos la bienvenida.

   {{{user_0.password | "Password"}}}

   También puedes encontrar la contraseña en el panel Detalles del lab.

6. Haz clic en Siguiente.

   Importante: Debes usar las credenciales que te proporciona el lab. No uses las credenciales de tu cuenta de Google Cloud. Nota: Usar tu propia Cuenta de Google podría generar cargos adicionales.

7. Haga clic para avanzar por las páginas siguientes:

   • Acepta los Términos y Condiciones.
   • No agregues opciones de recuperación o autenticación de dos factores (esta es una cuenta temporal).
   • No te registres para obtener pruebas gratuitas.

Después de un momento, se abrirá la consola de Google Cloud en esta pestaña.

Nota: Para ver un menú con una lista de productos y servicios de Google Cloud, haz clic en el menú de navegación que se encuentra en la parte superior izquierda.

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.

1. 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:

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

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.

2. Puedes solicitar el nombre de la cuenta activa con este comando (opcional):

gcloud auth list

3. Haz clic en Autorizar.

4. Ahora, el resultado debería verse de la siguiente manera:

Resultado:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. Puedes solicitar el ID del proyecto con este comando (opcional):

gcloud config list project

Resultado:

[core] project = <project_ID>

Resultado de ejemplo:

[core] project = qwiklabs-gcp-44776a13dea667a6 Nota: Para obtener toda la documentación de gcloud, consulta la guía con la descripción general de gcloud CLI en Google Cloud.

Tarea 1. Crea un clúster de GKE simple

1. Configura una zona en una variable de entorno llamada MY_ZONE. Este lab usa “”, por lo que puedes seleccionar una zona si así lo prefieres:

export MY_ZONE={{{project_0.default_zone|ZONE}}}

2. Ejecuta este comando para iniciar un clúster de Kubernetes administrado por Kubernetes Engine que se llama simplecluster y configúralo para ejecutar 2 nodos:

gcloud container clusters create simplecluster --zone $MY_ZONE --num-nodes 2 --metadata=disable-legacy-endpoints=false --cluster-version=1.24

La creación de un clúster tarda varios minutos, ya que Kubernetes Engine aprovisiona las máquinas virtuales. A los fines de este lab, puedes ignorar de forma segura las advertencias sobre las funciones disponibles en las versiones nuevas.

3. Una vez que se haya creado el clúster, verifica tu versión instalada de Kubernetes con el comando kubectl version:

kubectl version

El comando gcloud container clusters create autenticó kubectl automáticamente.

4. Mira tus nodos en ejecución en la consola de Cloud. En Menú de navegación, haz clic en Compute Engine > Instancias de VM.

Ya puedes usar tu clúster de Kubernetes.

Haz clic en Revisar mi progreso para verificar el objetivo. Crea un clúster de GKE simple

Tarea 2. Ejecuta un Pod del SDK de Google Cloud

1. En el símbolo del sistema de Cloud Shell, inicia una sola instancia del contenedor de SDK de Google Cloud.

kubectl run -it --rm gcloud --image=google/cloud-sdk:latest --restart=Never -- bash

Este proceso tardará unos minutos en completarse.

Nota: Si ves un error que indique agotamiento del tiempo de espera, ejecuta el comando otra vez.

2. Ahora, deberías tener una shell Bash dentro del contenedor del Pod:

root@gcloud:/#

Es posible que el contenedor demore unos segundos en iniciarse y el símbolo del sistema, en aparecer. Si no ves el símbolo del sistema, presiona Intro.

Explora el extremo de metadatos de Compute

1. Ejecuta el siguiente comando para acceder al extremo de metadatos de Compute v1:

curl -s http://metadata.google.internal/computeMetadata/v1/instance/name

El resultado obtenido se verá así:

…snip… Tu cliente no tiene permiso para obtener la dirección URL /computeMetadata/v1/instance/name de este servidor. Missing Metadata-Flavor:Google header. …snip…

Observa que devuelve un mensaje de error que indica la necesidad de la presencia del encabezado HTTP personalizado.

2. Agrega el encabezado personalizado en la próxima ejecución y recupera el nombre de la instancia de Compute Engine que se ejecuta en este Pod:

curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/name

El resultado obtenido se verá así:

gke-simplecluster-default-pool-b57a043a-6z5v Nota: Si un encabezado HTTP personalizado no es necesario para acceder al extremo de metadatos de la instancia de Compute Engine, un atacante solo necesitaría una falla en la aplicación para engañar a una URL web y obtener las credenciales de usuario. Un ataque se hace más difícil cuando un encabezado HTTP personalizado es obligatorio, ya que el atacante necesitaría de una falla en la aplicación y, además, de un encabezado personalizado para lograr su objetivo.

Mantén disponible esta shell dentro del Pod para el próximo paso.

3. Si saliste del Pod por accidente, simplemente vuelve a ejecutar el siguiente comando:

kubectl run -it --rm gcloud --image=google/cloud-sdk:latest --restart=Never -- bash

Explora las credenciales de inicio del nodo de GKE

1. Desde el interior de la misma shell del Pod, ejecuta el siguiente comando para enumerar los atributos asociados con las instancias de Compute Engine subyacentes. Asegúrate de incluir la barra diagonal final:

curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/attributes/

Quizás, los datos más sensibles de la lista se encuentren en kube-env. Este elemento contiene distintas variables que kubelet usa como credenciales de inicio cuando se conecta con el nodo al clúster de GKE. Las variables CA_CERT, KUBELET_CERT y KUBELET_KEY contienen esta información y, por lo tanto, se consideran datos sensibles para quienes no son administradores del clúster.

2. Para ver los datos y variables potencialmente sensibles, ejecuta el siguiente comando:

curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/attributes/kube-env

Por lo tanto, en cualquiera de las siguientes situaciones:

• Una falla que permita la SSRF en la aplicación de un Pod
• Una falla en la aplicación o biblioteca que permita la RCE en un Pod
• Un usuario interno con la capacidad de crear o ejecutar dentro de un Pod

Existe una alta probabilidad de que los datos sensibles de las credenciales de inicio de kubelet se vulneren y se roben a través del extremo de metadatos de Compute. En determinadas circunstancias, es posible aprovechar las credenciales de kubelet para derivar los privilegios a los de cluster-admin y, por lo tanto, tener control total sobre el clúster de GKE, incluso sobre todos los datos, las aplicaciones y el acceso a los nodos subyacentes.

Aprovecha los permisos asignados a la cuenta de servicio de este grupo de nodos

De forma predeterminada, los proyectos de Google Cloud que tienen la API de Compute habilitada tienen una cuenta de servicio predeterminada con el formato NNNNNNNNNN-compute@developer.gserviceaccount.com en el proyecto, además del rol de Editor asignado a ella. También, de forma predeterminada, los clústeres de GKE que se crearon sin especificar una cuenta de servicio utilizarán la cuenta de servicio predeterminada de Compute y la vincularán a todos los nodos trabajadores.

1. Ejecuta el siguiente comando curl para enumerar los permisos de OAuth asociados con la cuenta de servicio vinculada a la instancia de Compute Engine subyacente:

curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/scopes

(Resultado)

https://www.googleapis.com/auth/devstorage.read_only https://www.googleapis.com/auth/logging.write https://www.googleapis.com/auth/monitoring https://www.googleapis.com/auth/service.management.readonly https://www.googleapis.com/auth/servicecontrol https://www.googleapis.com/auth/trace.append

La combinación de los permisos de autenticación y de la cuenta de servicio determina a qué pueden acceder las aplicaciones de este nodo. La lista anterior enumera los permisos mínimos necesarios para la mayoría de los clústeres de GKE; no obstante, algunos casos de uso requieren permisos más amplios.

Advertencia: Si configuraste el alcance de la autenticación durante la creación del clúster para que incluya `https://www.googleapis.com/auth/cloud-platform`, cualquier API de Google Cloud tendría el permiso y solo los permisos de IAM asignados a la cuenta de servicio determinarían el acceso.

Además, si la cuenta de servicio predeterminada con el rol de IAM predeterminado de Editor está en uso, ningún Pod de este grupo de nodos tiene permisos de Editor para acceder al proyecto de Google Cloud donde se implementa el clúster de GKE. Como el rol de Editor de IAM tiene una gran variedad de permisos de lectura/escritura para interactuar con los recursos del proyecto (por ejemplo, las instancias de procesamiento, los buckets de Cloud Storage y los registros de GCR, entre otros), esto representa un riesgo importante para la seguridad.

2. Escribe el siguiente comando para salir de este Pod:

exit Nota: Si no volviste a Cloud Shell, presiona ctrl + c

Tarea 3. Implementa un Pod que active el sistema de archivos del host

Una de las rutas más simples para "escapar" al host subyacente es activar el sistema de archivos del host en el sistema de archivos del Pod a través del uso de volumes y volumeMounts estándares de Kubernetes en la especificación de un Pod.

1. Como demostración, ejecuta el siguiente comando para crear un Pod que active el sistema de archivos del host subyacente / en la carpeta llamada /rootfs, que se encuentra dentro del contenedor:

cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: hostpath spec: containers: - name: hostpath image: google/cloud-sdk:latest command: ["/bin/bash"] args: ["-c", "tail -f /dev/null"] volumeMounts: - mountPath: /rootfs name: rootfs volumes: - name: rootfs hostPath: path: / EOF

2. Ejecuta kubectl get pod y vuelve a ejecutarlo hasta que esté en el estado “Running”:

kubectl get pod

(Resultado)

NAME READY STATUS RESTARTS AGE hostpath 1/1 Running 0 30s

Haz clic en Revisar mi progreso para verificar el objetivo. Implementa un Pod que active el sistema de archivos del host

Tarea 4. Explora y vulnera el host subyacente

1. Ejecuta el siguiente comando para obtener una shell dentro del Pod que acabas de crear:

kubectl exec -it hostpath -- bash

2. Cambia el sistema de archivos raíz de la shell del Pod para que apunte al del host subyacente:

chroot /rootfs /bin/bash

Con esos comandos simples, el Pod es eficazmente una shell root en el nodo. Ahora puedes hacer lo siguiente:

ejecutar el comando estándar de Docker con los permisos completos	docker ps
enumerar imágenes de Docker	docker images
ejecutar un contenedor con privilegios de tu elección a través de docker run	docker run --privileged <imagename>:<imageversion>
examinar los Secrets de Kubernetes activados	mount | grep volumes | awk '{print $3}' | xargs ls
ejecutar a través de exec en cualquier contenedor activo (incluso en otro Pod ubicado en otro espacio de nombres)	docker exec -it <docker container ID> sh

Casi todas las operaciones que puede realizar el usuario root están disponibles para esta shell del Pod. Esto incluye mecanismos de persistencia, como agregar usuarios/claves SSH, ejecutar contenedores de Docker con privilegios en el host sin que se vea en Kubernetes y mucho más.

3. Si quieres salir de la shell del Pod, ejecuta exit dos veces: una vez para abandonar el chroot y otra vez para abandonar la shell del Pod.

exit exit Nota: Si no volviste a Cloud Shell, presiona ctrl + c.

4. Ahora, puedes borrar el Pod hostpath:

kubectl delete pod hostpath

Comprende los controles disponibles

Los próximos pasos de esta demostración incluirán las siguientes acciones:

• Inhabilitar el extremo de la API de metadatos de Compute Engine heredado: cuando se especifique una clave y un valor de metadatos personalizados, el extremo de metadatos v1beta1 ya no estará disponible desde la instancia.
• Habilitar el ocultamiento de metadatos: cuando se realice una configuración adicional durante la creación de un clúster o un grupo de nodos, se instalará un proxy ligero en cada nodo que enrutará todas las solicitudes a la API de metadatos y prohibirá el acceso a los extremos sensibles.
• Habilitar y configurar PodSecurityPolicy: cuando se configure esta opción en un clúster de GKE, se agregará el controlador de admisión PodSecurityPolicy que puede usarse para restringir el uso de configuraciones inseguras durante la creación del Pod. En el caso de esta demostración, prohibirás que los contenedores se ejecuten como el usuario raíz y tengan la capacidad de activar el sistema de archivos del host subyacente.

Tarea 5. Implementa un segundo grupo de nodos

Ahora, crearás un segundo grupo de nodos que incluya dos parámetros de configuración adicionales para que puedas experimentar los extremos de metadatos con las protecciones vigentes y sin ellas. Los Pods programados en el grupo de nodos genérico no tendrán protección, mientras que los Pods programados en el segundo grupo de nodos tendrán la protección habilitada.

Nota: Los extremos heredados quedaron obsoletos el 30 de septiembre de 2020. En las versiones de GKE 1.12 y posteriores, la configuración `--metadata=disable-legacy-endpoints=true` estará habilitada automáticamente. El siguiente comando lo define de manera explícita para mayor claridad.

• Crea el segundo grupo de nodos:

gcloud beta container node-pools create second-pool --cluster=simplecluster --zone=$MY_ZONE --num-nodes=1 --metadata=disable-legacy-endpoints=true --workload-metadata-from-node=SECURE

Haz clic en Revisar mi progreso para verificar el objetivo. Implementa un segundo grupo de nodos

Tarea 6. Ejecuta un Pod del SDK de Google Cloud

1. En Cloud Shell, inicia una sola instancia del contenedor del SDK de Google Cloud que se ejecutará solo en el segundo grupo de nodos con las protecciones habilitadas y no lo hará como el usuario raíz:

kubectl run -it --rm gcloud --image=google/cloud-sdk:latest --restart=Never --overrides='{ "apiVersion": "v1", "spec": { "securityContext": { "runAsUser": 65534, "fsGroup": 65534 }, "nodeSelector": { "cloud.google.com/gke-nodepool": "second-pool" } } }' -- bash Nota: Si se produce un error de tiempo de espera agotado, ejecuta el comando otra vez.

2. Ahora, deberías tener una shell Bash dentro del contenedor del Pod que se ejecuta en el segundo grupo de nodos llamado second-pool. Deberías ver lo siguiente:

nobody@gcloud:/$

El contenedor puede tardar algunos segundos en iniciar y el símbolo del sistema, en abrir.

Si no ves un símbolo del sistema, presiona Intro.

Explora los distintos extremos bloqueados

1. Cuando la configuración del segundo grupo de nodos está establecida como --workload-metadata-from-node=SECURE, el siguiente comando destinado a recuperar el archivo con datos sensibles, kube-env, fallará:

curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/attributes/kube-env

(Resultado)

Este extremo de metadatos está oculto.

2. Sin embargo, otros comandos para los extremos no sensibles seguirán funcionando si se proporciona el encabezado HTTP adecuado:

curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/name

(Resultado de ejemplo)

gke-simplecluster-second-pool-8fbd68c5-gzzp

3. Sal del Pod:

exit

Ahora, deberías estar nuevamente en Cloud Shell.

Tarea 7. Implementa los objetos de PodSecurityPolicy

1. Para tener los permisos necesarios y poder continuar, otorga permisos explícitos a tu propia cuenta de usuario de manera que sea cluster-admin:

kubectl create clusterrolebinding clusteradmin --clusterrole=cluster-admin --user="$(gcloud config list account --format 'value(core.account)')"

(Resultado)

clusterrolebinding.rbac.authorization.k8s.io/clusteradmin created

2. A continuación, implementa una PodSecurityPolicy más restrictiva sobre todos los usuarios autenticados en el espacio de nombres predeterminado:

cat <<EOF | kubectl apply -f - --- apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: restrictive-psp annotations: seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default' apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default' seccomp.security.alpha.kubernetes.io/defaultProfileName: 'docker/default' apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default' spec: privileged: false # Required to prevent escalations to root. allowPrivilegeEscalation: false # This is redundant with non-root + disallow privilege escalation, # but we can provide it for defense in depth. requiredDropCapabilities: - ALL # Allow core volume types. volumes: - 'configMap' - 'emptyDir' - 'projected' - 'secret' - 'downwardAPI' # Assume that persistentVolumes set up by the cluster admin are safe to use. - 'persistentVolumeClaim' hostNetwork: false hostIPC: false hostPID: false runAsUser: # Require the container to run without root privileges. rule: 'MustRunAsNonRoot' seLinux: # This policy assumes the nodes are using AppArmor rather than SELinux. rule: 'RunAsAny' supplementalGroups: rule: 'MustRunAs' ranges: # Forbid adding the root group. - min: 1 max: 65535 fsGroup: rule: 'MustRunAs' ranges: # Forbid adding the root group. - min: 1 max: 65535 EOF

(Resultado)

podsecuritypolicy.extensions/restrictive-psp created

3. Luego, agrega el objeto ClusterRole que proporciona la capacidad necesaria para “usar” esta PodSecurityPolicy:

cat <<EOF | kubectl apply -f - --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: restrictive-psp rules: - apiGroups: - extensions resources: - podsecuritypolicies resourceNames: - restrictive-psp verbs: - use EOF

(Resultado)

clusterrole.rbac.authorization.k8s.io/restrictive-psp created

4. Finalmente, crea un objeto RoleBinding en el espacio de nombres predeterminado para que cualquier permiso de usuario autenticado aproveche la PodSecurityPolicy.

cat <<EOF | kubectl apply -f - --- # All service accounts in kube-system # can 'use' the 'permissive-psp' PSP apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: restrictive-psp namespace: default roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: restrictive-psp subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: system:authenticated EOF

(Resultado)

rolebinding.rbac.authorization.k8s.io/restrictive-psp created Nota: En un entorno real, considera reemplazar el usuario system:authenticated en el objeto RoleBinding por el usuario o las cuentas de servicio específicos que desees que tengan la capacidad de crear Pods en el espacio de nombres predeterminado.

Haz clic en Revisar mi progreso para verificar el objetivo. Implementa los objetos de PodSecurityPolicy

Habilita la política de PodSecurity

• Habilita el controlador de admisión PodSecurityPolicy:

gcloud beta container clusters update simplecluster --zone $MY_ZONE --enable-pod-security-policy

Este proceso tarda unos minutos en completarse.

Tarea 8. Implementa un Pod bloqueado que active el sistema de archivos del host

Debido a que se le otorgó permisos de administrador de clúster a la cuenta que implementó el clúster de GKE en el paso anterior, se debe crear otra cuenta de "usuario" para que interactúe con el clúster y valide la aplicación de la PodSecurityPolicy.

1. Para ello, ejecuta el siguiente comando:

gcloud iam service-accounts create demo-developer

(Resultado)

Cuenta de servicio creada [demo-developer].

2. Luego, ejecuta los siguientes comandos para otorgar estos permisos a la cuenta de servicio (la capacidad de interactuar con el clúster y crear Pods):

MYPROJECT=$(gcloud config list --format 'value(core.project)') gcloud projects add-iam-policy-binding "${MYPROJECT}" --role=roles/container.developer --member="serviceAccount:demo-developer@${MYPROJECT}.iam.gserviceaccount.com"

3. Obtén el archivo de credenciales de la cuenta de servicio con el siguiente comando:

gcloud iam service-accounts keys create key.json --iam-account "demo-developer@${MYPROJECT}.iam.gserviceaccount.com"

4. Configura kubectl para autenticar esta cuenta de servicio:

gcloud auth activate-service-account --key-file=key.json

5. Ejecuta el siguiente comando para configurar kubectl y, así, utiliza estas credenciales cuando te comuniques con el clúster:

gcloud container clusters get-credentials simplecluster --zone $MY_ZONE

6. Ahora, intenta crear otro Pod que active el sistema de archivos del host subyacente / en la carpeta llamada /rootfs, que se encuentra dentro del contenedor:

cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: hostpath spec: containers: - name: hostpath image: google/cloud-sdk:latest command: ["/bin/bash"] args: ["-c", "tail -f /dev/null"] volumeMounts: - mountPath: /rootfs name: rootfs volumes: - name: rootfs hostPath: path: / EOF

7. Este resultado valida que está bloqueado por PSP:

Error from server (Forbidden): error when creating "STDIN": pods "hostpath" is forbidden: unable to validate against any pod security policy: [spec.volumes[0]: Invalid value: "hostPath": hostPath volumes are not allowed to be used]

8. Implementa otro Pod que cumpla con los criterios de restrictive-psp:

cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: hostpath spec: securityContext: runAsUser: 1000 fsGroup: 2000 containers: - name: hostpath image: google/cloud-sdk:latest command: ["/bin/bash"] args: ["-c", "tail -f /dev/null"] EOF

(Resultado)

pod/hostpath created

9. Ejecuta el siguiente comando para ver la anotación que se agrega al Pod y que indica qué PodSecurityPolicy autorizó su creación:

kubectl get pod hostpath -o=jsonpath="{ .metadata.annotations.kubernetes\.io/psp }"

(Resultado agregado a la línea de comandos de Cloud Shell)

restrictive-psp

Haz clic en Revisar mi progreso para verificar el objetivo. Implementa un Pod bloqueado que active el sistema de archivos del host

¡Felicitaciones!

En este lab, configuraste un clúster de Kubernetes predeterminado en Google Kubernetes Engine. Después, sondeaste y aprovechaste los accesos disponibles a tu Pod, endureciste el clúster y validaste que esas acciones maliciosas ya no pudieran realizarse.

Finaliza la Quest

Este lab de autoaprendizaje es parte de la Quest Google Kubernetes Engine Best Practices: Security. 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, o en cualquiera que contenga este lab, 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 Seguridad de Google Kubernetes Engine: Autorización Binaria o consulta estos labs de Google Cloud Skills Boost:

• Cómo proteger aplicaciones en Kubernetes Engine: Tres ejemplos
• Cómo utilizar el control de acceso basado en roles en Kubernetes Engine

Próximos pasos y más información

IMPORTANTE: Si bien este lab explica varios problemas de seguridad de forma detallada, debes considerar otras áreas en tu entorno. Consulta Guía para el endurecimiento de la seguridad de clúster para obtener más información.

PodSecurityPolicy: Guía para usar las PodSecurityPolicies y Guía para el endurecimiento de la seguridad de clúster

Cuentas de servicio de nodos: Guía de permisos

Protección de los metadatos de nodos: Guía para proteger los metadatos de nodos

Capacitación y certificación de Google Cloud

Recibe la formación que necesitas para aprovechar al máximo las tecnologías de Google Cloud. Nuestras clases incluyen habilidades técnicas y recomendaciones para ayudarte a avanzar rápidamente y a seguir aprendiendo. Para que puedas realizar nuestros cursos cuando más te convenga, ofrecemos distintos tipos de capacitación de nivel básico a avanzado: a pedido, presenciales y virtuales. Las certificaciones te ayudan a validar y demostrar tus habilidades y tu conocimiento técnico respecto a las tecnologías de Google Cloud.

Última actualización del manual: 3 de octubre de 2023

Prueba más reciente del lab: 9 de octubre de 2023

Copyright 2024 Google LLC. All rights reserved. Google y el logotipo de Google son marcas de Google LLC. Los demás nombres de productos y empresas pueden ser marcas de las respectivas empresas a las que estén asociados.