search

istio / old_issues_repo

Deprecated issue-tracking repo, please post new issues or feature requests to istio/istio instead.
37 stars 9 forks source link

[Istio Security] Integration with certs from external CAs #125

Open myidpt opened 6 years ago

myidpt commented 6 years ago

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 commented 6 years ago

@costinm @louiscryan

ldemailly commented 6 years ago

subscribe

eoftedal commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

@vadimeisenbergibm is the expert on this.

mchendil82 commented 6 years ago

Hi Oliver, Happy to see that the V1.0 is released with exciting features. Did we consider adding the CN name based validation along with SAN for certificates authentication when the Istio-CA based workloads connects with Non-Istio CA based workloads which sitting outside of Pod's cluster.. ?

myidpt commented 6 years ago

@mchendil82 We haven't considered supporting CN validation on proxies yet, for the reason that CN validation should be deprecated in favour of SAN validation. However for supporting legacy systems, I think we could support it if it's badly needed for Istio adoption. As far as I know, Envoy doesn't support validating the CN in the certificate. So it would require changes on Envoy.

mchendil82 commented 6 years ago

Hi Oliver,

Thanks a ton for kind and instant reply. Enterprise systems connecting to external systems securely is vital especially when the transactions are dependent on the partners system and their feeds.. This should be true for any bigger enterprises and mandatory. Hence our internal Istio SPIFEE workloads connecting to non-Istion partner workloads is crucial and istio adoption is becoming void without this use case as people see the system holistically in all aspects (Mutual security and performance).

I hope enabling this feature is really important and please let us know, if there is a procedure to talk about this and to make progress on this.. I can bring some people from our enterprise to request and have round table talk about this, if need..

On Mon, Aug 6, 2018 at 12:10 PM, Oliver Liu notifications@github.com wrote:

@mchendil82 https://github.com/mchendil82 We haven't considered supporting CN validation on proxies yet, for the reason that CN validation should be deprecated in favour of SAN validation. However for supporting legacy systems, I think we could support it if it's badly needed for Istio adoption. As far as I know, Envoy doesn't support validating the CN in the certificate. So it would require changes on Envoy.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/istio/old_issues_repo/issues/125#issuecomment-410780537, or mute the thread https://github.com/notifications/unsubscribe-auth/AifamVu8R49Yg0mhOJ-lnBCkcwp2Gp1Jks5uOHiFgaJpZM4Qi6XH .

myidpt commented 6 years ago

@mchendil82 Could you let me know what company you are in, and the scale of system you are planning to deploy Istio on? Do you need other features to make your deployment successful? This will help me to justify your request inside our team. Thanks :)

myidpt commented 6 years ago

For your use case, your Istio service is calling out to the non-Istio services, and not the opposite way, right? Is the connection TLS or mTLS?

mchendil82 commented 6 years ago

Hi Oliver,

Thanks for your continuous support.. It will be Mutual TLS Istio between, Spifee based certs workload from kube cluster <----Mutual TLS---> external Regular X.509 Workload (outside kube cluster, partners service (Both HTTP and TCP based endpoints are there)).

i.e. Both client and server should exchange certs and authenticate.. This is because due to compliance Mandate requirements in our domain..

Also about endpoints, I believe Istio envoy/gateway supports, HTTPS based endpoints but not TCP/TLS based endpoints such as Kafka, Cassandara services.. Correct me if I am wrong..

mchendil82 commented 6 years ago

Hi @myidpt

How are you? I have replied back on your last question.. Please go through it and let me know, if you need anymore details.. I am also interested to setup a meeting, if you are interested to do so..

myidpt commented 6 years ago

@mchendil82 Yes, I have gone through the doc. That's a good use case for Istio identity system integration. Feel free to set up a meeting with me yonggangl@google.com. I may also add people from Istio team. Thanks!

mchendil82 commented 6 years ago

Sure Oliver. Let me discuss this internally and come back on this.. Thanks for your support...

On Mon, Aug 13, 2018 at 1:00 PM, Oliver Liu notifications@github.com wrote:

@mchendil82 https://github.com/mchendil82 Yes, I have gone through the doc. That's a good use case for Istio identity system integration. Feel free to set up a meeting with me yonggangl@google.com. I may also add people from Istio team. Thanks!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/istio/old_issues_repo/issues/125#issuecomment-412608780, or mute the thread https://github.com/notifications/unsubscribe-auth/AifamfHcsZsMfLxv6JFKxuPM87y1p7gkks5uQb6lgaJpZM4Qi6XH .