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 con el fin de endurecer tus clústeres de GKE On-Prem.

En esta guía, se priorizan las mitigaciones de seguridad de alto valor que requieren que intervengas durante la creación del clúster. Las funciones menos importantes, la configuración de seguridad predeterminada y las opciones que se pueden habilitar después de la creación del clúster se mencionan más adelante. Para obtener una descripción general de los temas de seguridad, consulta Seguridad.

Encripta VM de vSphere

Los nodos del clúster de GKE On-Prem se ejecutan en máquinas virtuales (VM) del clúster de vSphere. Sigue los lineamientos de seguridad de VMware vSphere y la guía de prácticas recomendadas para encriptar VM.

Actualiza la infraestructura de manera oportuna

Kubernetes agrega nuevas funciones de seguridad y proporciona parches de seguridad con frecuencia. Para obtener información sobre los parches de seguridad, consulta Boletines de seguridad de GKE On-Prem.

Eres responsable de mantener actualizados tus clústeres de GKE On-Prem. Revisa las notas de la versión de todas las versiones. Planifica la actualización a las versiones de parches nuevas todos los meses y a las versiones secundarias cada tres meses. Obtén más información sobre cómo actualizar los clústeres.

También eres responsable de actualizar y proteger la infraestructura de vSphere:

Configura OpenID Connect

Si deseas configurar la autenticación de usuario en los clústeres, usa OpenID Connect (OIDC).

También debes aprovechar los grupos de OIDC cuando otorgues acceso a través del control de acceso basado en funciones (RBAC). Esto quita la necesidad de actualizar la configuración de RBAC de forma manual a medida que los usuarios cambian de funciones.

Usa el principio de privilegio mínimo para las cuentas de servicio de Google Cloud

GKE On-Prem requiere cuatro cuentas de servicio de Google Cloud:

  • Una cuenta de servicio incluida en la lista blanca para acceder al software de GKE On-Prem, La creas cuando compras Anthos
  • Una cuenta de servicio de registro que usará Connect para registrar clústeres de GKE On-Prem en Google Cloud
  • Una cuenta de servicio de conexión que usará Connect para establecer una conexión entre los clústeres de GKE On-Prem y Google Cloud
  • Una cuenta de servicio de Cloud Logging que usará Cloud Logging para recopilar registros de clústeres

Durante la instalación, debes vincular las funciones de administración de identidades y accesos a estas cuentas de servicio. Esas funciones otorgan privilegios específicos a las cuentas de servicio dentro del proyecto. Debes configurar estas cuentas de servicio según el principio de privilegio mínimo: otorga solo los privilegios necesarios para cumplir con las funciones respectivas de las cuentas de servicio.

Usa espacios de nombres de Kubernetes y RBAC para restringir el acceso

Para otorgar a los equipos el acceso de privilegio mínimo a Kubernetes, crea clústeres específicos del entorno o espacios de nombres de Kubernetes. Asigna centros de costos y etiquetas adecuadas a cada espacio de nombres para la rendición de cuentas y la devolución del cargo. Solo brinda a los desarrolladores el nivel de acceso a los espacios de nombres que necesitan para implementar y administrar sus aplicaciones, sobre todo en la producción.

Planifica las tareas que los usuarios deben realizar en el clúster y define los permisos necesarios para completar cada una. Para otorgar permisos a nivel de clúster y de espacio de nombres, usa el RBAC de Kubernetes.

Más allá de los permisos para las cuentas de servicio de Google Cloud que se usan con el fin de instalar GKE On-Prem, IAM no se aplica a los clústeres de GKE On-Prem.

Restringe los permisos de RBAC de descubrimiento de clústeres

De forma predeterminada, Kubernetes inicia los clústeres con un conjunto de permisos de ClusterRoleBindings de descubrimiento, que dan un acceso amplio a la información sobre las API de un clúster, incluidas las de CustomResourceDefinitions (CRD). Estos permisos se reducen en Kubernetes 1.14, que estará disponible a partir de la versión 1.2 de GKE On-Prem. Si es necesario restringir el acceso, considera configurar tu firewall local de manera adecuada.

Administración de Secrets

Si deseas proporcionar una capa adicional de protección para los datos sensibles, como los secretos de Kubernetes almacenados en etcd, configura un administrador de secretos que esté integrado en los clústeres de GKE On-Prem.

Si ejecutas cargas de trabajo en varios entornos, te recomendamos que uses una solución que funcione para Google Kubernetes Engine y GKE On-Pre. Si eliges usar un administrador de secretos externo, como HashiCorp Vault, debes configurarlo antes de crear tus clústeres de GKE On-Prem.

Tienes varias opciones para la administración secreta.

  • Puedes usar los Secretos de Kubernetes de forma nativa en GKE On-Prem. Se espera que los clústeres usen la encriptación de vSphere para las VM como se describió antes, lo que proporciona a los secretos una protección básica de encriptación en reposo. Los secretos no tienen una encriptación mayor de forma predeterminada. Para encriptar estos secretos en la capa de la aplicación, puedes editar EncryptionConfig y usar un complemento del servicio de administración de claves.
  • Puedes usar un administrador de secretos externo, como HashiCorp Vault. Puedes autenticarte en HashiCorp mediante una cuenta de servicio de Kubernetes o de Google Cloud.

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

Debes limitar la exposición a Internet del plano de control y los nodos del clúster. Estas opciones no se pueden cambiar después de la creación del clúster.

De forma predeterminada, los nodos del clúster de GKE On-Prem se crean mediante direcciones RFC 1918 y no debes cambiar esto. Debes implementar reglas de firewall en tu red local para restringir el acceso al plano de control.

Usa políticas de red para restringir el tráfico entre Pods

De forma predeterminada, todos los Services de un clúster de GKE On-Prem pueden comunicarse entre sí. Debes controlar la comunicación entre Services según sea necesario en las cargas de trabajo.

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

  1. Para controlar el tráfico de la capa 7 en los extremos de tus aplicaciones, usa Istio. Elige esta opción si te interesa el balanceo de cargas, la autorización de servicios, la limitación, la cuota y las métricas.
  2. Para controlar el tráfico de la capa 4 entre Pods, usa políticas de red de Kubernetes. Elige este método si buscas la funcionalidad básica de control de acceso que expone Kubernetes.

Puedes habilitar la política de red de Istio y de Kubernetes después de crear los clústeres de GKE On-Prem. Puedes usarlas en conjunto si es necesario.

Usa el controlador de políticas de Anthos Config Management

Los controladores de admisión de Kubernetes son complementos que rigen y aplican la forma en que se usa un clúster de Kubernetes. Debes habilitar los controladores de admisión para que usen las funciones de seguridad avanzadas de Kubernetes. Los controladores de admisión son una parte importante del enfoque de defensa en profundidad para endurecer el clúster.

Se recomienda el uso del controlador de políticas de Anthos Config Management. El controlador de políticas usa el framework de restricción de OPA para describir y aplicar la política como CRD. Las restricciones que deseas aplicar en el clúster se deben definir en plantillas de restricciones, que se implementan en los clústeres.

Supervisa la configuración del clúster

Debes auditar la configuración del clúster para detectar desviaciones de la configuración definida. Para verificar esta configuración de forma automática, debes usar una solución que funcione con los clústeres de GKE On-Prem, sin importar en qué ubicación se implementen. Consulta Socios de Anthos.

Deja los métodos de autenticación de clientes heredados inhabilitados (opción predeterminada)

Existen varios métodos de autenticación en el servidor de la API de Kubernetes. OIDC es el mecanismo de autenticación recomendado. La autenticación básica está inhabilitada de forma predeterminada. No uses el certificado x509 para la autenticación.

Deja Cloud Logging habilitado (predeterminado)

Para reducir la sobrecarga operativa y mantener una vista consolidada de los registros, implementa una estrategia de registro coherente en cualquier lugar en el que se implementen los clústeres. GKE On-Prem está integrado en Google Cloud's operations suite de forma predeterminada. Debes habilitar Google Cloud's operations suite durante la instalación. Para ello, propaga la especificación stackdriver en el archivo de configuración de GKE On-Prem.

Todos los clústeres de GKE On-Prem tienen habilitado el registro de auditoría de Kubernetes de forma predeterminada. El registro de auditoría mantiene un registro cronológico de las llamadas realizadas al servidor de la API de Kubernetes. Las entradas de registros de auditoría son útiles para investigar solicitudes sospechosas a la API, recopilar estadísticas y crear alertas de supervisión de las llamadas no deseadas a la API.

Los clústeres de GKE On-Prem integran el registro de auditoría de Kubernetes a los registros de auditoría de Google Cloud y Cloud Logging. GKE On-Prem también puede enrutar de Logging a tu propio sistema de registro.

Google Cloud's operations suite recopila y agrega los registros de los clústeres. Si habilitas Google Cloud's operations suite, puedes obtener una mejor asistencia de Google. Para obtener más información, consulta Registros y supervisión.

Mantén inhabilitado el panel de Kubernetes (opción predeterminada)

El panel de Kubernetes está respaldado por una cuenta de servicio de Kubernetes con muchos privilegios y se aprovechó en varios ataques de alto perfil en Kubernetes. Google Cloud Console es la interfaz web recomendada para GKE On-Prem. Ofrece muchas funciones similares, admite IAM y el RBAC de Kubernetes sin privilegios elevados y proporciona funciones de Anthos, como la administración de varios clústeres.

El panel de Kubernetes no está incluido en GKE On-Prem.

Mantén inhabilitado el control de acceso basado en atributos (predeterminado)

En Kubernetes, debes usar el RBAC para otorgar permisos a los recursos a nivel de clúster y de espacio de nombres. RBAC te permite definir funciones con reglas que contienen un conjunto de permisos.

De forma predeterminada, el control de acceso basado en atributos (ABAC) está inhabilitado en los clústeres de GKE On-Prem, y no debes habilitarlo.

¿Qué sigue?