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, se te guiará para que puedas implementar nuestra guía actual a fin de endurecer tu clúster de Google Kubernetes Engine (GKE).

En esta guía, se priorizan las mitigaciones de seguridad de alto valor que requieren acciones por parte del cliente durante la creación del clúster. Las funciones menos importantes, la configuración segura predeterminada y las opciones que pueden habilitarse luego del momento de la creación se mencionan más adelante en el documento. Para obtener una descripción general sobre los temas de seguridad, consulta la Descripción general de seguridad.

Muchas de estas recomendaciones, así como otras configuraciones erróneas comunes, se pueden verificar automáticamente con Estadísticas del estado de la seguridad.

Se especifica si las siguientes recomendaciones se relacionan con una Recomendación de CIS GKE Benchmark.

Actualiza tu infraestructura de GKE de manera oportuna (configuración predeterminada: 11-11-2019)

Recomendación de CIS GKE Benchmark: 6.5.3. Asegúrate de que la actualización automática de nodos esté habilitada para nodos de GKE

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.

Consulta los Boletines de seguridad de GKE para obtener información sobre los parches de seguridad.

En Google Kubernetes Engine, se aplican parches en los planos de control y se actualizan automáticamente. La actualización automática de nodos también actualiza los nodos en tu clúster de forma automática.

Si decides inhabilitar la actualización automática de nodos, te recomendamos que realices una actualización mensual según tus preferencias. Para los clústeres más antiguos, se debería habilitar la actualización automática de nodos y seguir de cerca los Boletines de seguridad de GKE en busca de los parches fundamentales.

Para obtener más información, consulta Cómo actualizar automáticamente los nodos.

Restringe a la red el acceso del plano de control y los nodos

Recomendaciones de CIS GKE Benchmark: 6.6.2. Prefiere clústeres nativos de la VPC, 6.6.3. Asegúrate de que las redes autorizadas de la instancia principal estén habilitadas, 6.6.4. Asegúrate de que los clústeres se creen con el extremo privado habilitado y el acceso público inhabilitado, y 6.6.5. Asegúrate de que los clústeres se creen con nodos privados

Deberías limitar la exposición en Internet del plano de control y los nodos de tu clúster. Esta configuración solo se puede establecer en el momento de la creación del clúster.

Según la configuración predeterminada, el plano de control y los nodos del clúster de GKE tienen direcciones enrutables de Internet a las que se puede acceder desde cualquier dirección IP.

Para el plano de control del clúster de GKE, consulta la página Configura un clúster privado. Existen tres tipos diferentes de clústeres privados que pueden ofrecer protección a nivel de red:

  • Acceso al extremo público inhabilitado: Esta es la opción más segura, ya que impide el acceso a Internet a los planos de control y a los nodos. Esta es una buena alternativa si configuraste tu red local para conectarte a Google Cloud mediante Cloud Interconnect y Cloud VPN. Esas tecnologías conectan la red de tu empresa a tu VPC en la nube de forma eficaz.
  • Acceso al extremo público habilitado, redes autorizadas habilitadas (recomendado): Esta opción proporciona acceso restringido al plano de control desde las direcciones IP de origen que definas. Esta es una buena opción si no tienes una infraestructura de VPN existente o tienes usuarios remotos o sucursales que se conectan a través de la Internet pública en lugar de la VPN corporativa, Cloud Interconnect o Cloud VPN.
  • Acceso al extremo público habilitado, redes autorizadas inhabilitadas: Este es el valor predeterminado y permite que cualquier persona en Internet realice conexiones de red al plano de control.

Para inhabilitar el acceso directo a Internet de los nodos, especifica la opción --enable-private-nodes de la herramienta de gcloud cuando crees un clúster.

Esto le indica a GKE que debe aprovisionar a los nodos con direcciones IP internas, lo que significa que no se puede acceder directamente a los nodos a través de la Internet pública.

Recomendamos que los clústeres usen al menos redes autorizadas y nodos privados. Esto garantiza que el plano de control sea accesible a través de las siguientes opciones:

  • Los CIDR permitidos en las redes autorizadas.
  • Los nodos dentro de la VPC de tu clúster.
  • Los trabajos de producción interna de Google que administran tu plano de control.

Esto se corresponde con las siguientes marcas de gcloud en el momento de creación del clúster:

  • --enable-ip-alias
  • --enable-private-nodes
  • --enable-master-authorized-networks

Autenticación de grupo (Beta)

Recomendación de CIS GKE Benchmark: 6.8.3. Considera administrar usuarios de RBAC de Kubernetes con Grupos de Google para GKE

Esta configuración solo se puede habilitar en el momento de la creación del clúster.

Debes usar grupos para administrar a tus usuarios. El uso de grupos permite controlar las identidades mediante el Sistema de administración de identidad y los Administradores de identidad. El ajuste de la membresía del grupo elimina la necesidad de actualizar tu configuración de RBAC cada vez que se agrega a alguien al grupo o se lo quita.

Para administrar los permisos del usuario con Grupos de Google, debes habilitar los Grupos de Google para GKE cuando creas tu clúster. Esto te permite administrar usuarios con los mismos permisos de forma sencilla, al tiempo que permite que tus administradores de identidad administren usuarios de manera centralizada y coherente.

A fin de habilitar Grupos de Google para GKE, crea un Grupo de Google, gke-security-groups, para administrar el acceso de los usuarios y especifica la marca --security-group de gcloud en el momento de la creación del clúster.

Opciones de nodo del contenedor

En las siguientes secciones, se describen opciones de configuración de nodo seguras.

Habilita nodos de GKE protegidos

Recomendación de CIS GKE Benchmark: 6.5.5. Asegúrate de que los nodos de GKE protegidos estén habilitados

Los nodos de GKE protegidos proporcionan una identidad y una integridad de nodo sólidas y verificables para aumentar la seguridad de los nodos de GKE y deberían estar habilitados en todos los clústeres de GKE.

Para habilitar los nodos de GKE protegidos, especifica la opción --enable-shielded-nodes de gcloud durante la creación o actualización del clúster. Los nodos de GKE protegidos deberían habilitarse con un inicio seguro. El inicio seguro no debe usarse si necesitas módulos de kernel sin firmar de terceros. Para habilitar el inicio seguro, especifica la marca --shielded-secure-boot de gcloud durante la creación del clúster.

Elige una imagen de nodo endurecido con el entorno de ejecución de containerd

La imagen de Container-Optimized OS con Containerd (cos_containerd) es una variante de la imagen de Container-Optimized OS con containerd como el entorno de ejecución principal del contenedor integrado directamente con Kubernetes.

containerd es el componente de entorno de ejecución principal de Docker y se lo diseñó con el fin de proveer funcionalidad de contenedor principal para la interfaz de entorno de ejecución del contenedor (CRI) de Kubernetes. Es significativamente menos complejo que el daemon de Docker completo y, por lo tanto, tiene una superficie de ataque más pequeña.

Para usar la imagen cos_containerd en tu clúster, especifica la marca --image-type=cos_containerd de gcloud en el momento de la creación o actualización del clúster.

cos_containerd es la imagen preferida de GKE, ya que se la personalizó, optimizó y endureció específicamente para contenedores en ejecución.

Habilita Workload Identity

Recomendación de CIS GKE Benchmark: 6.2.2. Prefiere usar cuentas de servicio de Google Cloud y Workload Identity dedicadas

Workload Identity es la forma recomendada de autenticarse en las API de Google. Reemplaza las prácticas anteriores que consistían en usar la cuenta de servicio de nodo o exportar claves de cuentas de servicio en secretos, como se describe en Autentica en Google Cloud con cuentas de servicio.

Workload Identity también reemplaza la necesidad de usar ocultamiento de metadatos, por lo que los dos enfoques son incompatibles. Workload Identity también protege los metadatos sensibles protegidos con la ocultación de metadatos.

Endurece el aislamiento de las cargas de trabajo con GKE Sandbox

Recomendación de CIS GKE Benchmark: 6.10.4. Considera usar GKE Sandbox a fin de endurecer el aislamiento de las cargas de trabajo, en especial para las cargas de trabajo que no sean de confianza.

GKE Sandbox proporciona una capa adicional de seguridad para evitar que el código malicioso afecte al kernel del host en los nodos de clústeres.

Obtén información sobre cómo usar GKE Sandbox en Endurece el aislamiento de las cargas de trabajo con GKE Sandbox.

Permisos

Usa las cuentas de servicio de Google con privilegios mínimos

Recomendación de CIS GKE Benchmark: 6.2.1. Prefiere no ejecutar clústeres de GKE con la cuenta de servicio predeterminada de Compute Engine

Cada nodo de GKE tiene una cuenta de servicio de administración de identidades y accesos (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.

Con el lanzamiento de Workload Identity, sugerimos un caso práctico más limitado para la cuenta de servicio de nodo. Esperamos que la cuenta de servicio de nodo la usen daemons del sistema responsables de registro, supervisión y tareas similares. En cambio, las cargas de trabajo en los Pods deberían aprovisionarse de identidades de Google con Workload Identity.

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

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:sa-name@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

Config Connector

Nota: En este paso, se necesita Config Connector. Sigue las instrucciones de instalación para instalar Config Connector en el clúster.

  1. Para crear la cuenta de servicio, descarga el siguiente recurso como service-account.yaml. Reemplaza [SA_NAME] por el nombre que deseas usar para la cuenta de servicio.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMServiceAccount
    metadata:
      name: [SA_NAME]
    spec:
      displayName: [SA_NAME]
    Luego, ejecuta lo siguiente:
    kubectl apply -f service-account.yaml

  2. Aplica la función logging.logWriter a la cuenta de servicio. Descarga el siguiente recurso como policy-logging.yaml. Reemplaza [SA_NAME] y [PROJECT_ID] por tu propia información.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMPolicyMember
    metadata:
      name: policy-logging
    spec:
      member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
      role: roles/logging.logWriter
      resourceRef:
        kind: Project
        name: [PROJECT_ID]
    kubectl apply -f policy-logging.yaml

  3. Aplica la función monitoring.metricWriter. Descarga el siguiente recurso como policy-metrics-writer.yaml. Reemplaza [SA_NAME] y [PROJECT_ID] por tu propia información.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMPolicyMember
    metadata:
      name: policy-metrics-writer
    spec:
      member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
      role: roles/monitoring.metricWriter
      resourceRef:
        kind: Project
        name: [PROJECT_ID]
    kubectl apply -f policy-metrics-writer.yaml

  4. Aplica la función monitoring.viewer. Descarga el siguiente recurso como policy-monitoring.yaml. Reemplaza [SA_NAME] y [PROJECT_ID] por tu propia información.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMPolicyMember
    metadata:
      name: policy-monitoring
    spec:
      member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
      role: roles/monitoring.viewer
      resourceRef:
        kind: Project
        name: [PROJECT_ID]
    kubectl apply -f policy-monitoring.yaml

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

gsutil

gsutil iam ch \
  serviceAccount:sa-name@project-id.iam.gserviceaccount.com:objectViewer \
  gs://bucket-name

El depósito que almacena tus imágenes tiene el nombre bucket-name con el siguiente formato:

  • artifacts.project-id.appspot.com para las imágenes enviadas a un registro en el host gcr.io, o
  • storage-region.artifacts.project-id.appspot.com

Reemplaza lo siguiente:

  • project-id: El ID de tu proyecto de Google Cloud Console.
  • storage-region la ubicación del depósito de almacenamiento:
    • us para los registros en el host us.gcr.io
    • eu para los registros en el host eu.gcr.io
    • asia para los registros en el host asia.gcr.io

Consulta la documentación de gsutil iam para obtener más información sobre el comando.

Config Connector

Nota: En este paso, se necesita Config Connector. Sigue las instrucciones de instalación para instalar Config Connector en el clúster.

Aplica la función storage.objectViewer a tu cuenta de servicio. Descarga el siguiente recurso como policy-object-viewer.yaml. Reemplaza [SA_NAME] y [PROJECT_ID] por tu propia información.

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-object-viewer
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/storage.objectViewer
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
kubectl apply -f policy-object-viewer.yaml

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

gcloud

gcloud iam service-accounts add-iam-policy-binding \
sa-name@project-id.iam.gserviceaccount.com \
--member=user:user \
--role=roles/iam.serviceAccountUser

Config Connector

Nota: En este paso, se necesita Config Connector. Sigue las instrucciones de instalación para instalar Config Connector en el clúster.

Aplica la función iam,serviceAccountUser a tu cuenta de servicio. Descarga el siguiente recurso como policy-service-account-user.yaml. Reemplaza [SA_NAME] y [PROJECT_ID] por tu propia información.

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-service-account-user
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/iam.serviceAccountUser
  resourceRef:
    kind: Project
    name: [PROJECT_ID]
kubectl apply -f policy-service-account-user.yaml

Si tu clúster ya existe, ahora puedes crear un nuevo grupo de nodos con la siguiente 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 otorgarles acceso a la cuenta de servicio a tus cargas de trabajo con Workload Identity.

Restringe el acceso al descubrimiento de API del clúster

De forma predeterminada, Kubernetes arranca los clústeres con un conjunto de permisos de ClusterRoleBindings de descubrimiento que dan un amplio acceso a la información sobre las API de un clúster, incluidas las de CustomResourceDefinitions.

Los usuarios deben tener en cuenta que el Grupo system:authenticated, incluido en los sujetos de los ClusterRoleBindings system:discovery y system:basic-user, puede incluir a cualquier usuario autenticado (incluso cualquier usuario con una Cuenta de Google) y no representa un nivel de seguridad significativo para clústeres en GKE.

Aquellos que deseen endurecer las API de descubrimiento de su clúster deben considerar una o más de las siguientes opciones:

Si ninguna de estas opciones es adecuada para tu caso práctico de GKE, debes tratar toda la información de descubrimiento de la API (es decir, el esquema de CustomResources, las definiciones de APIService y la información de descubrimiento alojada por los servidores de la API de extensión) como divulgada de manera pública

Usa espacios de nombres y RBAC para restringir el acceso a los recursos del clúster

Recomendación de CIS GKE Benchmark: 5.6.1. Crea límites administrativos entre los recursos que usan espacios de nombres

Brinda a los equipos el acceso a Kubernetes de privilegios mínimos mediante la creación de espacios de nombres o clústeres separados para cada equipo y entorno. Asigna centros de costos y etiquetas adecuadas a cada espacio de nombres para la rendición de cuentas y devolución del cargo. Solo brinda a los desarrolladores el nivel de acceso a su espacio de nombres que necesitan para implementar y administrar su aplicación, sobre todo en producción. Asigna las tareas que los usuarios deben realizar en el clúster y define los permisos que requieren para realizar cada tarea.

Para obtener más información sobre la creación de espacios de nombres, consulta la documentación de Kubernetes.

IAM y el Control de acceso según la función (RBAC) trabajan juntos, y una entidad debe tener permisos suficientes en cualquier nivel para trabajar con recursos en tu clúster.

Asigna las funciones de IAM adecuadas para GKE a grupos y usuarios con el fin de otorgar permisos a nivel de proyecto, y usa RBAC a fin de otorgar permisos a nivel de clúster y espacio de nombres. Para obtener más información, consulta Control de acceso.

Si quieres obtener más información, consulta Prepara un entorno de Google Kubernetes Engine para la producción.

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

Recomendación de CIS GKE Benchmark: 6.6.7. Asegúrate de que la política de red esté habilitada y configurada según corresponda

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 tus cargas de trabajo.

Restringir el acceso de la red a los servicios hace que sea mucho más difícil para los atacantes moverse de forma lateral dentro de tu clúster, y también ofrece a los servicios cierta protección contra la denegación accidental o deliberada del servicio. Dos formas recomendadas para controlar el tráfico son:

  1. Usa Istio. Consulta la página sobre cómo instalar Istio en GKE. Elige esta opción si te interesan el balanceo de cargas, la autorización de servicios, las regulaciones, las cuotas, las métricas y más.
  2. Usa las Políticas de red de Kubernetes. Consulta la página Crea una política de red de clúster. Elige esto si buscas la funcionalidad básica de control de acceso que expone Kubernetes. A fin de implementar enfoques comunes para restringir el tráfico con las políticas de red, sigue la guía de implementación de los planos de seguridad de Anthos. Además, en la documentación de Kubernetes, puedes encontrar una excelente explicación sobre las implementaciones de nginx simples. Considera usar el registro de políticas de red (Beta) para verificar que tus políticas de red funcionen según lo previsto.

Istio y la política de red pueden usarse en conjunto si es necesario.

Administración de secretos

Recomendación de CIS GKE Benchmark: 6.3.1. Considera encriptar Secretos de Kubernetes con claves administradas en Cloud KMS

Debes proporcionar una capa adicional de protección para datos sensibles, como los secretos, que se almacenan en etcd. Para hacer esto, necesitas configurar un administrador de secretos que esté integrado en los clústeres de GKE. Algunas soluciones funcionarán tanto en GKE como en GKE On-Prem, por lo que pueden ser más convenientes si ejecutas cargas de trabajo en varios entornos. Si eliges usar un administrador de secretos externo, como HashiCorp Vault, querrás configurarlo antes de crear tu clúster.

Tienes varias opciones para la administración secreta.

  • Puedes usar los secretos de Kubernetes de forma nativa en GKE. También tienes la opción de encriptarlos en la capa de aplicación con una clave que administres, mediante la Encriptación de secretos de la capa de la aplicación.
  • Puedes usar un administrador de secretos, como HashiCorp Vault. Cuando se ejecuta en un modo de HA endurecido, esto proporcionará una forma de administrar secretos coherente y lista para producción. Puedes autenticarte en HashiCorp Vault con una cuenta de servicio de Kubernetes o una cuenta de servicio de Google Cloud. Para obtener más información sobre el uso de GKE con Vault, consultaEjecuta HashiCorp Vault, y conéctate a él, en Kubernetes.

Las VM de GKE están encriptadas en la capa de almacenamiento de forma predeterminada, lo que incluye etcd.

Usa controladores de admisión para aplicar la política

Recomendación de CIS GKE Benchmark: 6.10.3. Asegúrate de que la Política de seguridad de pods esté habilitada y configurada según corresponda

Los controladores de admisión son complementos que rigen y aplican la forma en que se usa el clúster. Deben estar habilitados para usar algunas de las funciones de seguridad más avanzadas de Kubernetes y son una parte importante del enfoque de defensa en profundidad para endurecer tu clúster.

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 controles para restringir tus pods de modo que se ejecuten solo con las capacidades otorgadas de forma explícita. 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 una NetworkPolicy y tienes un pod que depende de una PodSecurityPolicy, debes crear una función de 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 la sección Autoriza políticas.

Supervisa la configuración de tu clúster

Debes auditar la configuración de tu clúster para detectar desviaciones de tu configuración definida.

Muchas de las recomendaciones que se incluyen en esta guía de endurecimiento, así como otras opciones de configuración incorrecta comunes, se pueden verificar de forma automática con las estadísticas del estado de la seguridad.

Valores predeterminados seguros

En las siguientes secciones, se describen las opciones que se configuran de forma segura en los clústeres nuevos de manera predeterminada. Debes verificar que los clústeres preexistentes estén configurados de forma segura.

Protege los metadatos de nodo (opción predeterminada para 1.12+)

Recomendaciones de CIS GKE Benchmark: 6.4.1. Asegúrate de que las API de metadatos de instancia de Compute Engine heredadas estén inhabilitadas y 6.4.2. Asegúrate de que el servidor de metadatos de GKE esté habilitado

El servidor de metadatos de instancia de Compute Engine expone los extremos heredados /0.1/ y /v1beta1/, que no aplican encabezados de consulta de metadatos. Estas API se han inhabilitado de forma predeterminada para los nuevos clústeres de 1.12+. Si actualizaste clústeres de versiones anteriores, deberías inhabilitar estas API heredadas de forma manual.

Algunos ataques prácticos contra Kubernetes dependen del acceso al servidor de metadatos de la VM para extraer credenciales. Esos ataques se bloquean si usas Workload Identity o el ocultamiento de metadatos .

Los extremos del servidor de metadatos v1beta1 y v0.1 de Compute Engine quedaron obsoletos y están programados para apagarse. Asegúrate de actualizar todas las solicitudes para usar el extremo v1.

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

Deja los métodos de autenticación de clientes heredados inhabilitados (predeterminado en 1.12+)

Recomendaciones de CIS GKE Benchmark: 6.8.1. Asegúrate de que la autenticación básica con contraseñas estáticas esté inhabilitada y 6.8.2. Asegúrate de que la autenticación mediante Certificados de cliente esté inhabilitada

Existen varios métodos de autenticación en el servidor de la API de Kubernetes. En GKE, los métodos admitidos son tokens del portador de la cuenta de servicio, tokens de OAuth y certificados del cliente x509. GKE administra la autenticación con gcloud para ti a través del método del token de OAuth; de este modo, configura la configuración de Kubernetes, obtiene un token de acceso y lo mantiene actualizado.

Antes de la integración de GKE con OAuth, los únicos métodos de autenticación disponibles eran un certificado x509 generado una sola vez o una contraseña estática, pero ya no son las opciones recomendadas y deben inhabilitarse. Estos métodos presentan una superficie de ataque más amplia para el compromiso del clúster y se inhabilitaron de forma predeterminada desde la versión 1.12 de GKE. Si usas métodos de autenticación heredados, te recomendamos que los desactives. La autenticación con una contraseña estática está obsoleta y se quitó desde la versión 1.19 de GKE.

Los clústeres existentes deben moverse a OAuth. Si un sistema externo al clúster necesita una credencial de larga duración, te recomendamos crear una cuenta de servicio de Google o una cuenta de servicio de Kubernetes con los privilegios necesarios y exportar la clave.

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

gcloud container clusters update cluster-name \
  --no-enable-basic-auth

Por el momento, no hay forma de quitar el certificado de cliente ya emitido de un clúster existente, pero no tiene permisos si RBAC está habilitado y ABAC está inhabilitado.

Deja Cloud Logging habilitado (predeterminado)

Recomendación de CIS GKE Benchmark: 6.7.1. Asegúrate de que Stackdriver Kubernetes Logging y Monitoring estén habilitados

Para reducir la sobrecarga operativa y mantener una vista consolidada de tus registros, implementa una estrategia de registro coherente en cualquier lugar en el que se implementen tus clústeres. Los clústeres de Anthos se integran en Cloud Logging de forma predeterminada y deben permanecer configurados.

Todos los clústeres de GKE tienen registro de auditoría de Kubernetes habilitado de forma predeterminada, lo que mantiene un registro cronológico de las llamadas que se realizaron al servidor de la API de Kubernetes. Las entradas de registro de auditoría de Kubernetes son útiles a fin de investigar solicitudes sospechosas a la API, recopilar estadísticas o crear alertas de supervisión para llamadas no deseadas a la API.

Los clústeres de GKE integran el registro de auditoría de Kubernetes con los registros de auditoría de Cloud y Cloud Logging. Los registros se pueden exportar desde Cloud Logging a tus propios sistemas de registro, si lo deseas.

Deja la IU web de Kubernetes (Panel) inhabilitada (predeterminado para 1.10+)

Recomendación de CIS GKE Benchmark: 6.10.1. Asegúrate de que la IU web de Kubernetes esté inhabilitada

No debes habilitar 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

Deja ABAC inhabilitado (predeterminado para 1.10+)

Recomendación de CIS GKE Benchmark: 6.8.4. Asegúrate de que la autorización heredada (ABAC) esté inhabilitada

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

Próximos pasos