Terminating MTLS in ingressgateway - what about authorization?

Hey everybody,

We have two ingress scenarios:

  • JWT over simple TLS (terminating in ingress)
  • MUTUAL TLS (also terminating in ingress)

The first works perfectly. We can apply both an authentication policy and an authorization policy.
But in the latter scenario I can only find a way to authenticate (via SDS and the CA-certificate).

A single CA-certificate can of course authenticate more than one client certificate so how to do we apply an authorization policy that gives e.g. a single client certificate access to this and another client certificate access to that (when they have the same CA-certificate and the MUTUAL TLS has been terminated in the ingress gateway).

Optimally I would like the certificate info from the client certificate to be available in e.g. requestPrincipals as it is after JWT authentication. But that appears not to be the case!?

Hope for some insight :slight_smile:

Best regards
Jesper

Well, nothing yet I see :slight_smile:

Partially inspired by this:

I’ve played with an envoy filter in my AuthorizationPolicy:

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: ingressgateway-authz
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: ALLOW
  rules:
  - to:
    - operation:
        ports: ["443","9443"]
        hosts:
        - "pow.servicemesh.mybox"
    when:
    - key: experimental.envoy.filters.network.client_ssl_auth[certificates]
      values:
      - "[[fingerprint_sha256, 5234981512daca66a79ba1cc2cc5c759d636af07a6dd360077ae42d209b3306a]]"

But alas no success yet. I’m definitely still using the filter in wrong way. Any insight on this?

Even when I fix the envoy filter request I would still very much like to request built in Istio functionality to do authorization on certificates after authenticating them via SDS. E.g. via the hash value.

Best regards
Jesper Berggren

Is this essentially to match against more attributes (e.g. the fingerprint) in the x509 certificate in AuthorizationPolicy? We’re going to add some more support of this (more details in https://docs.google.com/document/d/12Vde40n6N_oGZBC6j0S4R7ztWpNjWiOhc8aIU7dDWrc/edit#bookmark=id.n0skem2l92fj, join Istio community to gain access)

This should allow you to match directly on the x509 URI and DNS san even if it’s your own cert (not issued by Istio).

Hi YangminZhu,

Thanks for your update :smile:

The design document does indeed look promising - especially the part about “additional attributes for matching”. I guess they will be available in an AuthorizationPolicy?

When do you think we can expect this much needed functionality (at least for us)?

Best regards
Jesper

yes, it will be available in the AuthorizationPolicy as some new attributes. Unfortunately this probably cannot meet the 1.8 timeline due to the limited resource, we will try to get them in the next version (1.9).

Also any community help on the implementation is greatly welcomed and appreciated, so feel free to reach out if you could help.

Hi @YangminZhu,

Do you know the status of this implementation?
We’re on 1.9.1 and it still doesn’t look like it’s available - at least not according to the current docs.

I would very much like to help out but we’re currently fighting to keep our project time lines, so maybe on another issue when timing is better :slight_smile:

Best regards
Jesper