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

por Alexandre Vazquez
2025-11-03

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.

Flujo de validación de la Política de Autorización de: https://istio.io/latest/docs/concepts/security/

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.

Etiquetas:Security Service Mesh

Exploring Istio Security Policies for Enhanced Service Mesh Protection with 3 Objects

por Alexandre Vazquez
2023-06-042024-09-29

Istio Security Policies are crucial in securing microservices within a service mesh environment. We have discussed Istio and the capabilities that it can introduce to your Kubernetes workloads. Still, today we’re going to be more detailed regarding the different objects and resources that would help us make our workloads much more secure and enforce the communication between them. These objects include PeerAuthentication, RequestAuthentication, and AuthorizationPolicy objects.

PeerAuthentication: Enforcing security on pod-to-pod communication

PeerAuthentication focuses on securing communication between services by enforcing mutual TLS (Transport Layer Security) authentication and authorization. It enables administrators to define authentication policies for workloads based on the source of the requests, such as specific namespaces or service accounts. Configuring PeerAuthentication ensures that only authenticated and authorized services can communicate, preventing unauthorized access and man-in-the-middle attacks. This can be achieved depending on the value of the mode where defining this object being STRICT for only allowed mTLS communication, PERMISSIVE to allow both kinds of communication, DISABLE to forbid the mTLS connection and keep the traffic insecure, and UNSET to use the inherit option. This is a sample of the definition of the object:

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

RequestAuthentication: Defining authentication methods for Istio Workloads

RequestAuthentication, on the other hand, provides fine-grained control over the authentication of inbound requests. It allows administrators to specify rules and requirements for validating and authenticating incoming requests based on factors like JWT (JSON Web Tokens) validation, API keys, or custom authentication methods. With RequestAuthentication, service owners can enforce specific authentication mechanisms for different endpoints or routes, ensuring that only authenticated clients can access protected resources. Here you can see a sample of a RequestAuthentication object:

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"

As commented, JWT validation is the most used approach as JWT tokens are becoming the de-facto industry standard for incoming validations and the OAuth V2 authorization protocol. Here you can define the rules the JWT needs to meet to be considered a valid request. But the RequestAuthentication only describes the “authentication methods” supported by the workloads but doesn’t enforce it or provide any details regarding the Authorization.

That means that if you define a workload to need to use JWT authentication, sending the request with the token will validate that token and ensure it is not expired. It meets all the rules you have specified in the object definition, but it will also allow bypassing requests with no token at all, as you’re just defining what the workloads support but not enforcing it. To do that, we need to introduce the last object of this set, the AuthorizationPolicy object.

AuthorizationPolicy: Fine-grained Authorization Policy Definition for Istio Policies

AuthorizationPolicy offers powerful access control capabilities to regulate traffic flow within the service mesh. It allows administrators to define rules and conditions based on attributes like source, destination, headers, and even request payload to determine whether a request should be allowed or denied. AuthorizationPolicy helps enforce fine-grained authorization rules, granting or denying access to specific resources or actions based on the defined policies. Only authorized clients with appropriate permissions can access specific endpoints or perform particular operations within the service mesh. Here you can see a sample of an Authorization Policy object:

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"]

Here you can go as detailed as you need; you can apply rules on the source of the request to ensure that only some recommendations can go through (for example, requests that are from a JWT token to use in combination with the RequestAuthenitcation object), but also rules on the target, if this is going to a specific host or path or method or a combination of both. Also, you can apply to ALLOW rules or DENY rules (or even CUSTOM) and define a set of them, and all of them will be enforced as a whole. The evaluation is determined by the following rules as stated in the Istio Official Documentation:

If there are any CUSTOM policies that match the request, evaluate and deny the request if the evaluation result is denied.
If there are any DENY policies that match the request, deny the request.
If there are no ALLOW policies for the workload, allow the request.
If any of the ALLOW policies match the request, allow the request. Deny the request.

Authorization Policy validation flow from: https://istio.io/latest/docs/concepts/security/

This will provide all the requirements you could need to be able to do a full definition of all the security policies needed.

Conclusion

In conclusion, Istio’s Security Policies provide robust mechanisms for enhancing the security of microservices within a service mesh environment. The PeerAuthentication, RequestAuthentication, and AuthorizationPolicy objects offer a comprehensive toolkit to enforce authentication and authorization controls, ensuring secure communication and access control within the service mesh. By leveraging these Istio Security Policies, organizations can strengthen the security posture of their microservices, safeguarding sensitive data and preventing unauthorized access or malicious activities within their service mesh environment.

Etiquetas:Istio Kubernetes Security Service Mesh