Explorando las Políticas de Seguridad de Istio para una Protección Mejorada de la Malla de Servicios con 3 Objetos

Las Políticas de Seguridad de Istio son cruciales para asegurar los microservicios dentro de un entorno de malla de servicios. Hemos discutido Istio y las capacidades que puede introducir a tus cargas de trabajo de Kubernetes. Sin embargo, hoy vamos a ser más detallados respecto a los diferentes objetos y recursos que nos ayudarían a hacer nuestras cargas de trabajo mucho más seguras y a reforzar la comunicación entre ellas. Estos objetos incluyen los objetos PeerAuthentication, RequestAuthentication y AuthorizationPolicy.

PeerAuthentication: Aplicando seguridad en la comunicación de pod a pod

PeerAuthentication se centra en asegurar la comunicación entre servicios aplicando autenticación y autorización mutua TLS (Transport Layer Security). Permite a los administradores definir políticas de autenticación para cargas de trabajo basadas en la fuente de las solicitudes, como namespaces específicos o cuentas de servicio. Configurar PeerAuthentication asegura que solo los servicios autenticados y autorizados puedan comunicarse, previniendo el acceso no autorizado y los ataques de intermediarios. Esto se puede lograr dependiendo del valor del modo donde se define este objeto siendo STRICT para solo permitir comunicación mTLS, PERMISSIVE para permitir ambos tipos de comunicación, DISABLE para prohibir la conexión mTLS y mantener el tráfico inseguro, y UNSET para usar la opción heredada. Este es un ejemplo de la definición del objeto:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: foo
spec:
  mtls:
    mode: PERMISSIVE

RequestAuthentication: Definiendo métodos de autenticación para cargas de trabajo de Istio

RequestAuthentication, por otro lado, proporciona un control detallado sobre la autenticación de solicitudes entrantes. Permite a los administradores especificar reglas y requisitos para validar y autenticar solicitudes entrantes basadas en factores como la validación de JWT (JSON Web Tokens), claves API o métodos de autenticación personalizados. Con RequestAuthentication, los propietarios de servicios pueden aplicar mecanismos de autenticación específicos para diferentes puntos finales o rutas, asegurando que solo los clientes autenticados puedan acceder a recursos protegidos. Aquí puedes ver un ejemplo de un objeto RequestAuthentication:

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: jwt-auth-policy
  namespace: my-namespace
spec:
  selector:
    matchLabels:
      app: my-app
  jwtRules:
    - issuer: "issuer.example.com"
      jwksUri: "https://example.com/.well-known/jwks.json"

Como se comentó, la validación de JWT es el enfoque más utilizado ya que los tokens JWT se están convirtiendo en el estándar de la industria para validaciones entrantes y el protocolo de autorización OAuth V2. Aquí puedes definir las reglas que el JWT necesita cumplir para ser considerado una solicitud válida. Pero el RequestAuthentication solo describe los “métodos de autenticación” soportados por las cargas de trabajo pero no lo aplica ni proporciona detalles sobre la Autorización.

Eso significa que si defines que una carga de trabajo necesita usar autenticación JWT, enviar la solicitud con el token validará ese token y asegurará que no esté expirado. Cumple con todas las reglas que has especificado en la definición del objeto, pero también permitirá pasar solicitudes sin token alguno, ya que solo estás definiendo lo que las cargas de trabajo soportan pero no lo aplicas. Para hacer eso, necesitamos introducir el último objeto de este conjunto, el objeto AuthorizationPolicy.

AuthorizationPolicy: Definición de Políticas de Autorización Detalladas para Políticas de Istio

AuthorizationPolicy ofrece potentes capacidades de control de acceso para regular el flujo de tráfico dentro de la malla de servicios. Permite a los administradores definir reglas y condiciones basadas en atributos como fuente, destino, encabezados e incluso carga útil de la solicitud para determinar si una solicitud debe ser permitida o denegada. AuthorizationPolicy ayuda a aplicar reglas de autorización detalladas, otorgando o denegando acceso a recursos o acciones específicas basadas en las políticas definidas. Solo los clientes autorizados con permisos apropiados pueden acceder a puntos finales específicos o realizar operaciones particulares dentro de la malla de servicios. Aquí puedes ver un ejemplo de un objeto Authorization Policy:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: rbac-policy
  namespace: my-namespace
spec:
  selector:
    matchLabels:
      app: my-app
  rules:
    - from:
        - source:
            principals: ["user:user@example.com"]
      to:
        - operation:
            methods: ["GET"]

Aquí puedes ser tan detallado como necesites; puedes aplicar reglas sobre la fuente de la solicitud para asegurar que solo algunas recomendaciones puedan pasar (por ejemplo, solicitudes que provienen de un token JWT para usar en combinación con el objeto RequestAuthentication), pero también reglas sobre el destino, si esto va a un host o ruta específica o método o una combinación de ambos. Además, puedes aplicar reglas de PERMITIR o DENEGAR (o incluso PERSONALIZADAS) y definir un conjunto de ellas, y todas se aplicarán en su conjunto. La evaluación se determina por las siguientes reglas como se indica en la Documentación Oficial de Istio:

• Si hay políticas PERSONALIZADAS que coinciden con la solicitud, evalúa y niega la solicitud si el resultado de la evaluación es denegado.
• Si hay políticas de DENEGAR que coinciden con la solicitud, niega la solicitud.
• Si no hay políticas de PERMITIR para la carga de trabajo, permite la solicitud.
• Si alguna de las políticas de PERMITIR coincide con la solicitud, permite la solicitud. Niega la solicitud.
  

Esto proporcionará todos los requisitos que podrías necesitar para poder hacer una definición completa de todas las políticas de seguridad necesarias.

 Conclusión

En conclusión, las Políticas de Seguridad de Istio proporcionan mecanismos robustos para mejorar la seguridad de los microservicios dentro de un entorno de malla de servicios. Los objetos PeerAuthentication, RequestAuthentication y AuthorizationPolicy ofrecen un conjunto de herramientas integral para aplicar controles de autenticación y autorización, asegurando la comunicación segura y el control de acceso dentro de la malla de servicios. Al aprovechar estas Políticas de Seguridad de Istio, las organizaciones pueden fortalecer la postura de seguridad de sus microservicios, protegiendo datos sensibles y previniendo el acceso no autorizado o actividades maliciosas dentro de su entorno de malla de servicios.