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 It does, just tested.Authorization
header, but appsearch would then reject it.
How can I make istio not try to parse those Authorization
headers?
Cheers,
Lena