mirror of https://github.com/istio/istio.io.git
116 lines
4.5 KiB
Markdown
116 lines
4.5 KiB
Markdown
---
|
|
title: Provisioning Identity through SDS
|
|
description: Shows how to enable SDS (secret discovery service) for Istio identity provisioning.
|
|
weight: 70
|
|
keywords: [security,auth-sds]
|
|
---
|
|
|
|
This task shows how to enable
|
|
[SDS (secret discovery service)](https://www.envoyproxy.io/docs/envoy/latest/configuration/secret#config-secret-discovery-service)
|
|
for Istio identity provisioning.
|
|
|
|
Prior to Istio 1.1, the keys and certificates of Istio workloads were generated
|
|
by Citadel and distributed to sidecars through secret-volume mounted files,
|
|
this approach has the following minor drawbacks:
|
|
|
|
* Performance regression during certificate rotation:
|
|
When certificate rotation happens, Envoy is hot restarted to pick up the new
|
|
key and certificate, causing performance regression.
|
|
|
|
* Potential security vulnerability:
|
|
The workload private keys are distributed through Kubernetes secrets,
|
|
with known
|
|
[risks](https://kubernetes.io/docs/concepts/configuration/secret/#risks).
|
|
|
|
These issues are addressed in Istio 1.1 through the SDS identity provision flow.
|
|
The workflow can be described as follows.
|
|
|
|
1. The workload sidecar Envoy requests the key and certificates from the Citadel
|
|
agent: The Citadel agent is a SDS server, which runs as per-node `DaemonSet`.
|
|
In the request, Envoy passes a Kubernetes service account JWT to the agent.
|
|
|
|
1. The Citadel agent generates a key pair and sends the CSR request to Citadel:
|
|
Citadel verifies the JWT and issues the certificate to the Citadel agent.
|
|
|
|
1. The Citadel agent sends the key and certificate back to the workload sidecar.
|
|
|
|
This approach has the following benefits:
|
|
|
|
* The private key never leaves the node: It is only in the Citadel agent
|
|
and Envoy sidecar's memory.
|
|
|
|
* The secret volume mount is no longer needed: The reliance on the Kubernetes
|
|
secrets is eliminated.
|
|
|
|
* The sidecar Envoy is able to dynamically renew the key and certificate
|
|
through the SDS API: Certificate rotations no longer require Envoy to restart.
|
|
|
|
## Before you begin
|
|
|
|
* Set up Istio by following the instructions using
|
|
[Helm](/docs/setup/kubernetes/install/helm/) with SDS setup and global mutual
|
|
TLS enabled:
|
|
|
|
{{< text bash >}}
|
|
$ cat install/kubernetes/namespace.yaml > istio-auth-sds.yaml
|
|
$ cat install/kubernetes/helm/istio-init/files/crd-* >> istio-auth-sds.yaml
|
|
$ helm dep update --skip-refresh install/kubernetes/helm/istio
|
|
$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system --values @install/kubernetes/helm/istio/values-istio-sds-auth.yaml@ >> istio-auth-sds.yaml
|
|
$ kubectl create -f istio-auth-sds.yaml
|
|
{{< /text >}}
|
|
|
|
## Service-to-service mutual TLS using key/certificate provisioned through SDS
|
|
|
|
Follow the [authentication policy task](/docs/tasks/security/authn-policy/) to
|
|
setup test services.
|
|
|
|
{{< text bash >}}
|
|
$ kubectl create ns foo
|
|
$ kubectl apply -f <(istioctl kube-inject -f @samples/httpbin/httpbin.yaml@) -n foo
|
|
$ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@) -n foo
|
|
$ kubectl create ns bar
|
|
$ kubectl apply -f <(istioctl kube-inject -f @samples/httpbin/httpbin.yaml@) -n bar
|
|
$ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@) -n bar
|
|
{{< /text >}}
|
|
|
|
Verify all mutual TLS requests succeed:
|
|
|
|
{{< text bash >}}
|
|
$ for from in "foo" "bar"; do for to in "foo" "bar"; do kubectl exec $(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name}) -c sleep -n ${from} -- curl "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "sleep.${from} to httpbin.${to}: %{http_code}\n"; done; done
|
|
sleep.foo to httpbin.foo: 200
|
|
sleep.foo to httpbin.bar: 200
|
|
sleep.bar to httpbin.foo: 200
|
|
sleep.bar to httpbin.bar: 200
|
|
{{< /text >}}
|
|
|
|
## Verifying no secret-volume mounted file is generated
|
|
|
|
To verify that no secret-volume mounted file is generated, access the deployed
|
|
workload sidecar container:
|
|
|
|
{{< text bash >}}
|
|
$ kubectl exec -it $(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name}) -c istio-proxy -n foo -- /bin/bash
|
|
{{< /text >}}
|
|
|
|
As you can see there is no secret file mounted at `/etc/certs` folder.
|
|
|
|
## Cleanup
|
|
|
|
Clean up test services and Istio control plane:
|
|
|
|
{{< text bash >}}
|
|
$ kubectl delete ns foo
|
|
$ kubectl delete ns bar
|
|
$ kubectl delete -f istio-auth-sds.yaml
|
|
{{< /text >}}
|
|
|
|
## Caveats
|
|
|
|
Currently, the SDS identity provision flow has the following caveats:
|
|
|
|
* You still need secret volume mount for enabling the control plane security.
|
|
Enabling SDS for the control plane security remains a work in progress.
|
|
|
|
* Smoothly migrating a cluster from using secret volume mount to using
|
|
SDS is a work in progress.
|