Deactivating RequestAuthentication/JWT token parsing (!) for specific workloads

I have a configuration where all my own services require JWT authentication. There are a few exceptions though; I do have an elastic appsearch in my cluster (same namespace) as well. That one cares about authentication itself. I had it running outside of istio for some time because it really wanted to care about its own certificates. That requirement is gone since a few releases, and I’m moving it into the service mesh.

Elastic Appsearch uses its own Bearer tokens, but those are not JWT tokens at all. Seems that although I deactivated JWT checking through an AuthorizationPolicy (does it work like that? Other q&as seem to suggest that), istio tries to parse that header as JWT. This is the error message: Jwt is not in the form of Header.Payload.Signature with two dots and 3 sections, which is true (the tokens look like search-abcdefghijklmnopqrstuvwxyz). Maybe I’m doing something wrong in another place as well, but those are the resources I currently do think come into play here:

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: generic-request-authentication
  namespace: apps
spec:
  jwtRules:
    - audiences:
        - some-audience
      forwardOriginalToken: true
      issuer: https://some-issuer
      jwksUri: >-
        https://some-jwks-uri
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  labels:
    app: search-and-tag-service-appsearch
  name: search-and-tag-service-appsearch-allow-all
  namespace: apps
spec:
  action: ALLOW
  rules:
    - from:
        - source:
            namespaces:
              - apps
        - source:
            namespaces:
              - elastic-system
  selector:
    matchLabels:
      app: search-and-tag-service-appsearch

Appsearch pods do have the label app: search-and-tag-service-appsearch set.

I hoped my AuthorizationPolicy already allows requests from the same namespace. It might even let the request pass if it did not have any Authorization header, but appsearch would then reject it. It does, just tested.
How can I make istio not try to parse those Authorization headers?

Cheers,
Lena

Hi Lena,

Did you end up finding a solution to this? I have nearly the exact same issue.

Cheers,

Liam

Hi Liam,
I “solved” this by pushing those services out of the mesh, because I did not find a better solution. If you find another solution, I’d be glad to hear, because I’d rather want to have those in the mesh…

Cheers,
Lena