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!?
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.
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)?
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.
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