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.

Este documento ayuda a los operadores, los especialistas en redes y los especialistas en seguridad a comprender e implementar la seguridad de la red en los clústeres de GKE. Para obtener más información sobre los roles comunes y las tareas de ejemplo en Google Cloud, consulta Roles y tareas comunes de los usuarios 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 la base de datos en sí requiere autenticación.
  • Datos prácticos: Basar las decisiones de seguridad en datos El modelado de amenazas y la evaluación de riesgos determinan tu nivel 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 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 CiliumClusterwideNetworkPolicy para aplicar barreras de seguridad que se apliquen a todo el clúster. Las reglas de rechazo en NetworkPolicy tienen prioridad sobre las reglas de permiso de CiliumClusterwideNetworkPolicy.

  • 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 Service Mesh para implementar TLS mutua (mTLS), que controla la encriptación de forma automática.

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)
Aplicar reglas obligatorias en todo el clúster como administrador 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, lo que confirma que el tráfico legítimo fluye según lo esperado y que el tráfico no autorizado se bloquea.

¿Qué sigue?