[Istio Security] Integration with certs from external CAs

[myidpt]

Is this a BUG or FEATURE REQUEST?:
FEATURE REQUEST

Feature Request:
Y

Describe the feature:
Istio workload mTLS connections rely on the X509 certs issued by the Istio CA. The peer identities are extracted from the SAN field (URI type), at the client side for secure naming check, and at the server side for authz.
Workloads on non-Istio platforms may use certificates signed by non-Istio CAs. In this case, the identities may come from the CN, or non-URI type SAN field (such as DNS). We would like Istio workloads to be able to call out to / receive calls from non-Istio workloads. This requires Istio authn and secure naming to be able to extract / use identity from configured fields in cert (or disable secure naming).
This issue tracks the this effort.

[myidpt]

@costinm @louiscryan

[ldemailly]

subscribe

[eoftedal]

I've been looking at something similar to this. I've created a Root CA and two intermediate CAs. I gave one of the intermediate CAs to isitio, and then used the other CA for issuing client certs to external applications. From istios side this works like a charm, as long as I put spiffe-identifiers in the client certificates. I can use the mixer access control rules etc.
The only problem I have left is the fact that these certs issued by istio do not have DNS SAN fields, which creates a problem for some clients when they want to connect. For custom code, one could always change the client's cert validation to expect a host certificate with a given spiffe-field, but this is not necessarily possible in every system.
As far as I understand the istio TLS certs are bound to service accounts. A pod thus gets its TLS cert from the service account running it. I suppose one option could be that the ServiceAccounts are tagged with hostnames (labels: host), and then the istio CA includes the hosts in the cert.

[mchendil82]

Hi Oliver

We do have use case that Istio CA based workloads connecting to non-Istio CA workload or external partners using regular x.509 standard certificates and we are not able to proceed (we are facing handshake error). Is this feature is introduced in 0.8? Need your kind assistance on this

[myidpt]

Thanks for showing the interest. This requires Envoy to support validating the certificate from CN instead of SAN, which Envoy doesn't have today.
https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/auth/cert.proto#envoy-api-msg-auth-certificatevalidationcontext
In the long term, we will support this direct authentication. For now, I think a possible workaround for you is to use the ingress and egress gateways to terminate the TLS. The gateways know how to authenticate both ends.

[mchendil82]

Thanks a lot oliver for your kind reply.. I will try to use use ingress/egress gateways on this. is gateway capable of present/validatiing certificates when it connects non-istio workloads... Basically, I am still seeing Istio-ca based certs might fail here, when used by egress gateways.? (or) Should I need to use regular x.509 certificates for all the workloads on both ends (which we are not interested to do)?

[myidpt]

That's a good question, I'm not exactly sure how Istio egress gateways works with the certs.

@vadimeisenbergibm is the expert on this.