Custom CA Integration using Kubernetes CSR
This feature requires Kubernetes version >= 1.18.
This task shows how to provision workload certificates using a custom certificate authority that integrates with the Kubernetes CSR API7. Different workloads can get their certificates signed from different cert-signers. Each cert-signer is effectively a different CA. It is expected that workloads whose certificates are issued from the same cert-signer can talk mTLS to each other while workloads signed by different signers cannot. This feature leverages Chiron8, a lightweight component linked with Istiod that signs certificates using the Kubernetes CSR API.
For this example, we use open-source cert-manager9.
Cert-manager has added experimental Support for Kubernetes CertificateSigningRequests
10 starting with version 1.4.
Deploy custom CA controller in the Kubernetes cluster
Deploy cert-manager according to the installation doc11.
Create three self signed cluster issuers
istio-system
,foo
andbar
for cert-manager. Note: Namespace issuers and other types of issuers can also be used.
Verify secrets are created for each cluster issuer
Export root certificates for each cluster issuer
Deploy Istio with default cert-signer info
Deploy Istio on the cluster using
istioctl
with the following configuration. TheISTIO_META_CERT_SIGNER
is the default cert-signer for workloads.Create the
bar
andfoo
namespaces.Deploy the
proxyconfig-bar.yaml
in thebar
namespace to define cert-signer for workloads in thebar
namespace.Deploy the
proxyconfig-foo.yaml
in thefoo
namespace to define cert-signer for workloads in thefoo
namespace.Deploy the
httpbin
andcurl
sample applications in thefoo
andbar
namespaces.
Verify the network connectivity between httpbin
and curl
within the same namespace
When the workloads are deployed, they send CSR requests with related signer info. Istiod forwards the CSR request to the custom CA for signing. The custom CA will use the correct cluster issuer to sign the cert back. Workloads under foo
namespace will use foo
cluster issuers while workloads under bar
namespace will use the bar
cluster issuers. To verify that they have indeed been signed by correct cluster issuers, we can verify workloads under the same namespace can communicate while workloads under the different namespace cannot communicate.
Set the
CURL_POD_FOO
environment variable to the name ofcurl
pod.Check network connectivity between service
curl
andhttpbin
in thefoo
namespace.Check network connectivity between service
curl
in thefoo
namespace andhttpbin
in thebar
namespace.
Cleanup
Remove the namespaces and uninstall Istio and cert-manager:
Reasons to use this feature
Custom CA Integration - By specifying a Signer name in the Kubernetes CSR Request, this feature allows Istio to integrate with custom Certificate Authorities using the Kubernetes CSR API interface. This does require the custom CA to implement a Kubernetes controller to watch the
CertificateSigningRequest
Resources and act on them.Better multi-tenancy - By specifying a different cert-signer for different workloads, certificates for different tenant’s workloads can be signed by different CAs.