Istio is an open-source service mesh that helps in connecting, securing, and managing microservices. It is designed to work with Kubernetes and introduces additional networking layers to facilitate better service communication. However, one of the commonly discussed issues in the Istio ecosystem revolves around the handling of HTTP headers, particularly the Authorization header. In certain cases, users find that Istio does not forward this header as expected.

Understanding the Issue

When a request is routed through the Istio sidecar proxy (based on Envoy), users may notice that the Authorization header is absent from the destination service's request context. This can be problematic for services that rely on bearer tokens or other forms of authorization headers for authentication and authorization.

Technical Explanation

1. Envoy Sidecar Proxy:
   Each microservice in an Istio-managed Kubernetes cluster is accompanied by a sidecar proxy. This proxy is responsible for intercepting all incoming and outgoing traffic. Istio leverages Envoy as the default sidecar proxy. By default, certain headers may not be forwarded due to either security policies or misconfigurations.
2. Istio Gateway Configuration:
   When an Istio Gateway is used to expose services outside the Kubernetes cluster, it might not be configured to handle or forward the Authorization header correctly. This can result from either missing configurations or due to the route and virtual service definitions that do not account for header propagation.
3. mTLS (Mutual TLS):
   Istio's mutual TLS feature is focused on securing service-to-service communications within the cluster. While mTLS is excellent for providing in-cluster encryption, it doesn't inherently handle or require application-layer headers such as Authorization .
4. Header Manipulation Rules:
   Istio's VirtualService and DestinationRule configurations allow for header manipulation. If these rules are applied incorrectly, they might alter the headers during routing, leading to unintended results where critical headers like Authorization are dropped.

Example Scenario

Suppose service A wants to call service B with an HTTP request that includes an Authorization header for authentication purposes.

• Kubernetes Service and Pod Annotations:
  It's crucial to correctly annotate the services and pods for the sidecar injection to honor the Authorization header. A misconfiguration here results in the sidecar not passing the header.
• Example Configuration:
  • service-b.namespace.svc.cluster.local
  • match:
    • uri:
    • destination:
• Properly Configure Istio Gateway and VirtualService:
• Disable mTLS if External Headers are Involved:
• Use Envoy Filters:
• Check Security Policies: