istio.io/content/docs/tasks/security/auth-sds/index.md

title	description	weight	keywords
Provisioning Identity through SDS	Shows how to enable SDS (secret discovery service) for Istio identity provisioning.	70	security auth-sds

This task shows how to enable SDS (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-mount files, this approach has the following side effects:

• Traffic interruption: When certificate rotation happens, Envoy (Pilot agent) needs to restart to pick up key/certificate update, which causes traffic interruption.
• Potential security issue: Since key/certificate are file-mounted to sidecars, hackers could remote to sidecar container and steal key/certificate content.

These issues are addressed in Istio 1.1 through the support of SDS to provision identities.

Workload requests key/certificate from SDS server (node agent, which runs as per-node daemon set) using a Kubernetes service account JWT through the SDS API, node agent generates private key and send CSR request to Citadel, Citadel verifies the JWT and signs the certificate, the key/certificate will eventually be sent back to workload sidecar through SDS server(node agent). Since key/certificate which are generated through SDS are stored in workload sidecar's memory, it's more secure than file mount; also the workload doesn't need to restart to pick up the certificate change when rotation happens.

Before you begin

• Set up Istio by following the instructions using 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 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-mount file is generated

As mentioned, instead of using secret-mount file, key/certificate provisioned by SDS flow are stored in workload sidecar's memory, which is more secure and avoids traffic interruption.

Verify no secret-mount file is generated by remotely accessing to workload sidecar container that we just deployed:

{{< 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 >}}