Comprende la seguridad de red en GKE

En este documento, se explican los conceptos básicos de seguridad de red de GKE, como el principio de privilegio mínimo, y se te ayuda a elegir las herramientas adecuadas para proteger tu clúster. Los objetivos principales de implementar la seguridad de red de GKE son el aislamiento de cargas de trabajo y la seguridad de usuarios múltiples. Para lograr estos objetivos, debes aplicar los principios de privilegio mínimo y defensa en profundidad, y usar datos prácticos para fundamentar tus decisiones de seguridad.

En Google Kubernetes Engine (GKE), aplicar el principio de privilegio mínimo al tráfico de red significa restringir la comunicación solo a lo que es necesario para que funcionen tus aplicaciones. De forma predeterminada, la red dentro de un clúster de GKE está abierta, lo que significa que cada Pod puede comunicarse con cualquier otro Pod.

GKE ahora admite un enfoque jerárquico para la seguridad de la red con ClusterNetworkPolicy para la aplicación a nivel administrativo en todos los espacios de nombres.

En este documento, se proporciona información que los operadores, los especialistas en redes y los especialistas en seguridad deben comprender y aplicar para proteger las redes dentro de los clústeres de GKE. Para obtener más información sobre los roles comunes y las tareas de ejemplo en Cloud de Confiance by S3NS, consulta Roles y tareas comunes del usuario de GKE.

Antes de leer este documento, verifica que conozcas los siguientes temas:

  • Conceptos de redes de GKE: Para obtener una descripción general, consulta Acerca de las redes de GKE.
  • Pods, servicios y espacios de nombres de Kubernetes: Estos recursos fundamentales de Kubernetes son esenciales para definir políticas de seguridad de red. Consulta la documentación de Kubernetes.
  • El principio de privilegio mínimo: Este principio de seguridad es un concepto fundamental que se aplica en todo este documento.

Objetivos de la seguridad de red de GKE

Las políticas de seguridad de red de GKE proporcionan un control de tráfico detallado y compatible con Kubernetes dentro de tu clúster. Estas políticas son un elemento fundamental de tu estrategia de seguridad general. Para implementar una seguridad de red sólida, considera estos principios fundamentales:

  • Privilegio mínimo: Otorga a los sistemas y servicios solo los privilegios mínimos necesarios para realizar sus funciones. Este principio reduce el posible impacto de una vulneración. Las políticas de red de Kubernetes te ayudan a pasar de una red abierta de forma predeterminada a una en la que solo se permiten las conexiones necesarias.
  • Defensa en profundidad: Aplica varias capas de controles de seguridad independientes. Una falla en un control no conduce a una vulneración total del sistema. Por ejemplo, puedes usar una política de red para aislar una base de datos, incluso si esta requiere autenticación.
  • Datos prácticos: Basar las decisiones de seguridad en datos El modelado de amenazas y la evaluación de riesgos fundamentan tu postura de seguridad. Las funciones como el registro de políticas de red proporcionan los datos para verificar las políticas y detectar posibles incumplimientos.

Elige una política de seguridad de red

Para elegir la política adecuada, identifica el tipo y el alcance del tráfico que necesitas controlar.

Tipos de tráfico

Para elegir la política adecuada, considera la fuente y el destino del tráfico que deseas administrar:

  • Comunicación entre Pods dentro del clúster: Para controlar cómo se comunican los microservicios entre sí, usa políticas que operen en etiquetas y espacios de nombres de Pods.

    • Como desarrollador de aplicaciones, usa el objeto NetworkPolicy estándar de Kubernetes para definir reglas de entrada y salida para tu aplicación dentro de su espacio de nombres.
    • Como administrador del clúster, usa la ClusterNetworkPolicy estándar de Kubernetes para aplicar medidas de seguridad obligatorias (nivel Admin) o establecer valores predeterminados de confianza cero (nivel Baseline) en todos los espacios de nombres. Este recurso es compatible con clústeres que ejecutan la versión 1.36.1-gke.1067000 o posterior de GKE.
    • Como administrador del clúster, usa la CiliumClusterwideNetworkPolicy patentada para el control especializado del tráfico en todo el clúster. Para las implementaciones nuevas, usa ClusterNetworkPolicy nativa de Kubernetes en lugar de esta política propietaria.

  • Tráfico de salida de Pods a servicios externos: Para controlar el tráfico de salida de Pods a servicios externos según los nombres de dominio, usa FQDNNetworkPolicy. Esta política es útil cuando las direcciones IP de los servicios externos no son estáticas, ya que resuelve y actualiza automáticamente las direcciones IP permitidas según el DNS.

  • Encriptación para todo el tráfico de servicio a servicio: Para garantizar que toda la comunicación entre servicios esté encriptada y autenticada, usa una malla de servicios. Usa Istio o Anthos Cloud Service Mesh para implementar TLS mutua (mTLS), que controla la encriptación de forma automática.

Niveles de evaluación de políticas

GKE evalúa las políticas de seguridad de red en tres niveles jerárquicos.

  1. Nivel de administrador (ClusterNetworkPolicy): Es el nivel de precedencia más alto. Usa este nivel para aplicar los requisitos de seguridad obligatorios. Las reglas de rechazo de este nivel anulan todas las demás políticas. Las reglas de aceptación permiten el tráfico y detienen la evaluación de ese paquete.
  2. Nivel de NetworkPolicy: Es el nivel en el que los desarrolladores definen la seguridad específica de la aplicación. Las políticas incluyen los recursos estándar NetworkPolicy, FQDNNetworkPolicy y CiliumClusterwideNetworkPolicy.
  3. Nivel de referencia (ClusterNetworkPolicy): Es el nivel de precedencia más bajo. Usa este nivel para establecer parámetros de protección predeterminados de "rechazo predeterminado" que los desarrolladores pueden anular de forma selectiva en el nivel NetworkPolicy.

Si no coincide ninguna política en ningún nivel, GKE usa de forma predeterminada un comportamiento implícito de "permitir todo".

Resumen de las opciones de políticas

En la siguiente tabla, se resume qué política usar según tu objetivo de seguridad.

Objetivo Política recomendada
Controla el tráfico entre Pods con etiquetas y espacios de nombres. Kubernetes NetworkPolicy
Controla el tráfico de salida a servicios externos por nombre de dominio. FQDNNetworkPolicy
Encripta y autentica todo el tráfico de servicio a servicio. Istio o Anthos Cloud Service Mesh (para mTLS)
Aplica barreras de seguridad obligatorias que no se puedan anular. ClusterNetworkPolicy (nivel de administrador)
Establece barreras de seguridad predeterminadas de "confianza cero" que los desarrolladores pueden anular. ClusterNetworkPolicy (nivel básico)
Configura políticas propietarias para todo el clúster (no se recomienda para implementaciones nuevas). CiliumClusterwideNetworkPolicy
Auditar y registrar las conexiones permitidas o rechazadas por las políticas Registro de políticas de red (habilitado para cualquier política)

Audita y soluciona problemas de políticas de red

Después de implementar las políticas de red, verifica que funcionen según lo previsto y diagnostica cualquier problema de conectividad. Puedes usar el registro de políticas de red como herramienta principal para esto.

Cuando habilitas el registro de políticas de red, GKE genera un registro en Cloud Logging para cada conexión que una política de red permite o rechaza. Estos registros son esenciales para realizar auditorías de seguridad y solucionar problemas de comportamiento inesperado. Revisar estos registros te permite ver los efectos concretos de tus reglas, confirmar que el tráfico legítimo fluye según lo esperado y que el tráfico no autorizado se bloquea.

A diferencia de las políticas estándar, que son solo de "permiso", los recursos ClusterNetworkPolicy admiten acciones explícitas de Denegar. Si una política administrativa descarta el tráfico, el registro atribuye el rechazo a la política específica responsable del bloqueo.

¿Qué sigue?