We enabled mTLS in an Istio Cluster with multiple namespaces operated by different teams.
The teams are using
AuthorizationPolicy to control which other applications can access resources on their apps by specifying the service account names running those applications. Something like:
apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: myapp-acl spec: selector: matchLabels: app: myapp action: ALLOW rules: - from: - source: principals: ["cluster.local/ns/other-team-namespace/sa/other-app-account"] to: - operation: methods: ["GET", "DELETE", "POST"]
Now we have legacy applications not running on Kubernetes that need to communicate with some Istio managed applications.
We setup an Istio Gateway that requires mTLS and are now looking for a way how teams can configure a policy in their namespace so that they can somehow specify SubjectDNs of external client certificates which are allowed to access their apps through the central Istio gateway.
The istio gateway adds a x-forwarded-client-cert request header to incoming requests, so we tried to apply a policy condition on that header:
rules: - from: - source: principals: ["cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"] when: - key: request.headers[x-forwarded-client-cert] values: ["*;Subject=\"CN=other-app,OU=Services,O=Example\";*"]
This does not seem work. Apparently only request header begins-with (
value: ["SOMEVALUE*"]) and request header ends-with (
value: ["*SOMEVALUE"]) rules are implemented but not request header contains (
- Is it possible to configure the Istio Gateway in a way that it puts the Subject CN of the client certificate in a separate request header, e.g. something like
x-forwarded-client-cert-cnso we can use an exact match rule on that header in an
- Any other ideas how to achieve this kind of access control? We don’t want to directly put the ACL on the Istio Gateway but on the pod level.
Thanks for any thoughts in advance!