Endurecimiento de la seguridad del clúster

Debido a la gran velocidad de desarrollo en Kubernetes, a menudo hay nuevas características de seguridad que puedes usar. En esta página, aprenderás a implementar nuestra guía actual a fin de endurecer tu clúster de Google Kubernetes Engine. Para obtener una descripción general sobre los temas de seguridad, consulta la Descripción general de seguridad.

Inhabilita la IU web de Kubernetes (Panel)

Debes inhabilitar la IU web de Kubernetes (Panel) cuando se ejecuta en GKE.

La IU web de Kubernetes (Panel) se encuentra respaldada por una Cuenta de servicio de Kubernetes con una gran cantidad de privilegios. Cloud Console ofrece muchas funciones similares, por lo que no necesitas estos permisos.

Para inhabilitar la IU web de Kubernetes, usa lo siguiente:

gcloud container clusters update [CLUSTER_NAME] \
    --update-addons=KubernetesDashboard=DISABLED

Inhabilita ABAC

Debes inhabilitar el control de acceso basado en atributos (ABAC) y, en su lugar, usar el control de acceso basado en funciones (RBAC) en GKE.

En Kubernetes, RBAC se usa para otorgar permisos a los recursos en el nivel de clúster y espacio de nombres. RBAC te permite definir funciones con reglas que contienen un conjunto de permisos. Cuenta con importantes ventajas de seguridad y ahora es estable en Kubernetes, por lo que es momento de inhabilitar ABAC.

Si aún usas ABAC, primero revisa los Requisitos previos para usar RBAC. Si actualizaste tu clúster desde una versión anterior y usas ABAC, debes actualizar la configuración de controles de acceso:

gcloud container clusters update [CLUSTER_NAME] \
    --no-enable-legacy-authorization

Para crear un nuevo clúster con la recomendación anterior, usa lo siguiente:

gcloud container clusters create [CLUSTER_NAME] \
    --no-enable-legacy-authorization

Restringe el tráfico entre pods con una política de red

De forma predeterminada, todos los Pods en un clúster pueden comunicarse entre sí. Debes controlar la comunicación de Pod a Pod según sea necesario para tu carga de trabajo.

Puedes usar las Políticas de red de Kubernetes para que a los atacantes les resulte mucho más difícil moverse lateralmente dentro de tu clúster. También puedes usar la API de política de red de Kubernetes para crear reglas de firewall a nivel de Pod. Estas reglas de firewall determinan qué Pods y servicios pueden acceder entre ellos dentro de tu clúster.

Para habilitar la aplicación de políticas de red al momento de crear un nuevo clúster, especifica la marca --enable-network-policy:

gcloud container clusters create [CLUSTER_NAME] \
    --zone=[COMPUTE_ZONE] \
    --enable-network-policy

Después de habilitar la política de red, tienes que definir una política. Dado que esto es específico de tu topología exacta, no podemos proporcionar una recomendación puntual. Sin embargo, en la documentación de Kubernetes, puedes encontrar una excelente explicación sobre las implementaciones de nginx simples.

Para obtener más información sobre las políticas de red en GKE, consulta Configura una política de red de clúster.

Usa NetworkPolicy y PodSecurityPolicy en conjunto

Si usas una NetworkPolicy y tienes un Pod que depende de una PodSecurityPolicy, crea una función RBAC o ClusterRole que tenga permiso para usar la PodSecurityPolicy. Luego, vincula la función o ClusterRole a la cuenta de servicio del Pod. En este caso, otorgar permisos a las cuentas de usuarios no es suficiente. Para obtener más información, consulta Autoriza políticas.

Usa las cuentas de servicio con privilegios mínimos para tus nodos

Cada nodo de GKE tiene una cuenta de servicio de IAM asociada. De forma predeterminada, a los nodos se les asigna la cuenta de servicio predeterminada de Compute Engine, que puedes encontrar si te diriges a la sección de IAM de Cloud Console. Esta cuenta posee un acceso amplio de manera predeterminada, por lo que es útil para una gran variedad de aplicaciones. Sin embargo, tiene más permisos que los necesarios para ejecutar tu clúster de Kubernetes Engine. Debes crear y usar una cuenta de servicio con privilegios mínimos para ejecutar tu clúster de GKE, en lugar de usar la cuenta de servicio predeterminada de Compute Engine.

GKE requiere, como mínimo, que la cuenta de servicio tenga las funciones monitoring.viewer, monitoring.metricWriter y logging.logWriter. Obtén más información sobre las funciones de supervisión y las funciones de registro.

Los siguientes comandos crean una cuenta de servicio de IAM con los permisos mínimos requeridos para operar GKE:

gcloud iam service-accounts create [SA_NAME] \
    --display-name=[SA_NAME]

gcloud projects add-iam-policy-binding [PROJECT_ID] \
    --member "serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com" \
    --role roles/logging.logWriter

gcloud projects add-iam-policy-binding [PROJECT_ID] \
    --member "serviceAccount:@[PROJECT_ID].iam.gserviceaccount.com" \
    --role roles/monitoring.metricWriter

gcloud projects add-iam-policy-binding [PROJECT_ID] \
    --member "serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com" \
    --role roles/monitoring.viewer

Si usas imágenes privadas en el Google Container Registry, también debes otorgar acceso a ellas:

gcloud projects add-iam-policy-binding [PROJECT_ID] \
  --member "serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com" \
  --role roles/storage.objectViewer

Si quieres que otro usuario pueda crear nuevos clústeres o grupos de nodos con esta cuenta de servicio, debes otorgarle la función de Usuario de cuenta de servicio en esta cuenta:

gcloud iam service-accounts add-iam-policy-binding \
  [SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com \
  --member=user:[USER] \
  --role=roles/iam.serviceAccountUser

Si tu clúster ya existe, ahora puedes crear un nuevo grupo de nodos con esta cuenta de servicio nueva:

gcloud container node-pools create [NODE_POOL] \
  --service-account=[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com" \
  --cluster=[CLUSTER_NAME]

Si necesitas que tu clúster de GKE tenga acceso a otros servicios de Google Cloud, debes crear una cuenta de servicio adicional y otorgarle a tus cargas de trabajo acceso a la cuenta de servicio mediante el almacenamiento de su clave privada en un secreto de Kubernetes. Para obtener más información, consulta Autentica Google Cloud Platform con cuentas de servicio.

Reduce los niveles de tu cuenta de servicio de nodo

Si no quieres usar una cuenta de servicio personalizada, una recomendación alternativa es reducir los permisos de la cuenta de servicio de nodo predeterminada.

De forma predeterminada, tu cuenta de servicio de nodo tiene niveles de acceso. Los niveles de acceso son el método heredado de especificar permisos para tu instancia. Antes de que existieran las funciones de IAM, los niveles de acceso eran el único mecanismo para otorgarles permisos a cuentas de servicio.

Si no creas una cuenta de servicio independiente para tus nodos, debes limitar los niveles de la cuenta de servicio de nodo a fin de reducir la posibilidad de una elevación de privilegios en un ataque. Esto garantiza que tu cuenta de servicio predeterminada no obtenga más permisos de los necesarios para ejecutar tu clúster. Si bien los niveles predeterminados son limitados, pueden incluir más niveles que los mínimos necesarios para ejecutar tu clúster.

Los niveles predeterminados para tus nodos en GKE son devstorage.read_only, logging.write, monitoring, service.management.readonly, servicecontrol, y trace.append. Cuando establezcas los niveles, estos se especifican como gke-default. Si accedes a imágenes privadas en Google Container Registry, los niveles mínimos necesarios son solo logging.write, monitoring y devstorage.read_only.

Para crear un clúster con los niveles personalizados, usa la opción --scopes:

gcloud container clusters create [CLUSTER_NAME] \
    --scopes=[CUSTOM_SCOPES]

Si no especificas niveles o una cuenta de servicio personalizada, se usa gke-default. Si especificas una cuenta de servicio personalizada, se usan cloud-platform y userinfo.email.

Si tu configuración de gcloud incluye container/new_scopes_behavior true, este comportamiento se habilita para todas las versiones de Kubernetes. Si quieres establecer el valor predeterminado para tu entorno, usa lo siguiente:

gcloud config set container/new_scopes_behavior true

Si quieres obtener más información sobre los permisos para todos los niveles, consulta los niveles de Google.

Restringe los métodos de autenticación de clientes

Existen varios métodos de autenticación en el servidor de la API de Kubernetes. En GKE, los métodos admitidos son tokens de conexión de OpenID, certificados de cliente x509 y contraseñas estáticas. GKE administra la autenticación a través de gcloud mediante el método de tokens de conexión de OpenID, la configuración de Kubernetes, la obtención de un token de acceso y la actualización constante.

Los otros métodos de autenticación, los certificados x509 y las contraseñas estáticas, poseen una superficie de ataque más amplia en relación con el compromiso del clúster. Con estos otros métodos, las credenciales se generan cuando creas un clúster nuevo. A menos que tu aplicación use estos métodos de autenticación, debes inhabilitarlos. Debes usar el método de autenticación de OpenID y, luego, inhabilitar el certificado de cliente de tu clúster y los métodos de autenticación con contraseña estática.

El certificado de cliente y la contraseña estática solo los puede recuperar un usuario con el permiso container.clusters.getCredentials. Ten en cuenta que las funciones roles/container.admin, roles/owner y roles/editor tienen este permiso, por lo que se recomienda usarlas con cuidado. Obtén más información sobre las Funciones de IAM de GKE.

Inhabilita la autenticación con un certificado de cliente

Con la autenticación del certificado, un cliente presenta un certificado que el servidor de API verifica con la autoridad certificada especificada. En GKE, los certificados de cliente están firmados por la Autoridad Certificada de raíz del clúster.

Con ABAC, los certificados de cliente se pueden autenticar en el servidor de API de forma predeterminada. Pero si está habilitado RBAC, los certificados de cliente deben obtener permisos. Un clúster con RBAC habilitado y ABAC inhabilitado posee estos certificados, pero estos no tienen ninguna utilidad.

Para crear un clúster sin generar un certificado de cliente, usa la marca--no-issue-client-certificate:

gcloud container clusters create [CLUSTER_NAME] \
    --no-issue-client-certificate

Por el momento, no hay manera de quitar un certificado de cliente de un clúster existente.

Inhabilita la autenticación con una contraseña estática

Una contraseña estática es una combinación de nombre de usuario y contraseña que el servidor de API valida. En GKE, estos se generan para un nombre de usuario “administrador” de forma predeterminada.

Para crear un clúster sin generar una contraseña estática, usa la opción --no-enable-basic-auth:

gcloud container clusters create [CLUSTER_NAME] \
    --no-enable-basic-auth

Para actualizar un clúster existente y quitar la contraseña estática:

gcloud container clusters update [CLUSTER_NAME] \
    --no-enable-basic-auth

Protege los metadatos de nodo

Algunos ataques prácticos contra Kubernetes dependen del acceso al servidor de metadatos de la VM para extraer las credenciales del nodo.

El primer paso para mitigar estos ataques, como ya se recomendó, es usar una cuenta de servicio con los privilegios mínimos. El siguiente paso es evitar que las cargas de trabajo se hagan pasar por nodos. Debes inhabilitar las API del servidor de metadatos heredados y usar el ocultamiento de metadatos con el fin de ayudar a proteger los metadatos del sistema que puedan ser sensibles de las cargas de trabajo que se ejecutan en tu clúster.

Para obtener más información, consulta Protege los metadatos del clúster.

Actualiza tus nodos de forma automática

Mantener la versión de Kubernetes actualizada es una de las tareas más simples que puedes realizar para mejorar tu seguridad. Kubernetes suele agregar nuevas funciones de seguridad y proporcionar parches de seguridad con frecuencia.

En Google Kubernetes Engine, no es necesario que apliques los parches y actualices las instancias principales tu mismo, pero los nodos siguen siendo tu responsabilidad. Debes habilitar la actualización automática de nodos a fin de recibir actualizaciones y parches de seguridad para tus grupos de nodos de manera automática.

Para obtener más información, consulta Actualización automática de nodos.

Si no quieres habilitar la actualización automática de nodos, asegúrate de consultar los boletines de seguridad de Kubernetes Engine de forma minuciosa para obtener información sobre los parches de seguridad.

Restringe los permisos de pods mediante una política de seguridad de pods (Beta)

De forma predeterminada, los pods en Kubernetes pueden operar con más funciones de las necesarias. Debes limitar las funciones del pod a solo las necesarias para esa carga de trabajo.

Kubernetes ofrece las herramientas para restringir tus pods de modo que se ejecuten con las funciones mínimas necesarias. La política de seguridad de pods te permite establecer valores predeterminados inteligentes para tus pods y aplicar los controles que quieres habilitar en tu flota. Debes definir las políticas según las necesidades de tu aplicación. La política de ejemplo restricted-psp.yaml es un buen punto de partida.

Para obtener más información sobre la política de seguridad de pods, consulta Usa PodSecurityPolicies.

Si usas políticas de red y políticas de seguridad de pods en tu clúster, consulta Usa políticas de red y políticas de seguridad de pods en conjunto.

Pasos siguientes

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...