This talk was presented by Dr. Tao Li on 11/29/2017 at the Cloud Native Online meetup.
https://www.meetup.com/Cloud-Native-Online-Meetup/events/245027581/
Summary:
In today's talk, Tao will cover the general Istio Security roadmap, including authentication and authorization. And then he will focus on the authentication part from CA to node identity to workload identity.
Bio:
Dr. Tao Li is a software engineer at Google. He has been with Google for more than 5 years. Currently he serves as a TL of Istio Security, focusing on Authentication, which includes CA, identity provisioning, service-to-service communication, etc.
Organized by StackPointCloud - https://stackpoint.io
2. Confidential & ProprietaryGoogle Cloud Platform 2
Problem Statement
IT’s shift to a modern distributed architecture has left
enterprises unable to monitor, manage or secure their
services in a consistent way.
7. Confidential & ProprietaryGoogle Cloud Platform 7
Istio Security incorporates the learnings of securing millions of service
endpoints in Google’s production environment
9. Confidential & ProprietaryGoogle Cloud Platform 9
Istio Security Scopes
● Mutual authentication and encryption between Istio endpoints
○ Based on service accounts
○ Encoded in x509 cert
○ Mutual TLS (mTLS) between client/server proxies (Envoy)
● Support additional authN
○ TLS + JWT for end user authentication
● Security policy to allow fine control
○ A unique interface to config Authn/Authz/Audit policy
11. Confidential & ProprietaryGoogle Cloud Platform 11
Securing the service communication
SAN: “spiffe://myorg.com/ns/default/sa/team1”
EnvoyFrontend Envoy Backend
SAN: “spiffe://myorg.com/ns/default/sa/team2”
Client Server
K8s PodK8s Pod
12. Confidential & ProprietaryGoogle Cloud Platform 12
Securing the service communication
EnvoyFrontend Envoy Backend
Client Server
mTLS Handshake
K8s PodK8s Pod
13. Confidential & ProprietaryGoogle Cloud Platform 13
Securing the service communication
EnvoyFrontend Envoy Backend
Secure Naming Info
Can “spiffe://.../team2” run service
“Backend”?
Client Server
mTLS Handshake
Discovery Service
K8s PodK8s Pod
SAN: “spiffe://.../team2”
14. Confidential & ProprietaryGoogle Cloud Platform 14
Securing the service communication
EnvoyFrontend Envoy Backend
Secure Naming Info
Client Server
mTLS Handshake
Discovery Service Mixer
AuthZ
Should I accept “spiffe://...//team1”?
K8s PodK8s Pod
SAN: “spiffe://.../team1”
15. Confidential & ProprietaryGoogle Cloud Platform 15
Securing the service communication
EnvoyFrontend Envoy Backend
Secure Naming Info
Secure data transmission
Client Server
mTLS Handshake
Discovery Service Mixer
AuthZ
K8s PodK8s Pod
For k8s cluster, CA generates key/cert for workloads and we use k8s secret and volume mount to deliver to key/cert to workload container. This is what we did in our 0.1 release, which is about 4 months ago, in the next release, we extend to support VM. We introduce a node agent running on each VM. It generates private/public key pair, as well as CSR. sends the CSR to CA for sign. And CA sends back the cert. In this way, private key never leaves node agent.
For k8s cluster, CA generates key/cert for workloads and we use k8s secret and volume mount to deliver to key/cert to workload container. This is what we did in our 0.1 release, which is about 4 months ago, in the next release, we extend to support VM. We introduce a node agent running on each VM. It generates private/public key pair, as well as CSR. sends the CSR to CA for sign. And CA sends back the cert. In this way, private key never leaves node agent.