Skip to content

SPIFFE trust domain workload certificates

In the context of Istio and service meshes, workload certificates are used to establish identity between services. These sample certificates specifically demonstrate the usage of the SPIFFE (Secure Production Identity Framework For Everyone) standard, where identities are formatted as SPIFFE URIs.^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__certs__README.md]

Certificate Structure and Naming

The provided samples include X.509 certificates and corresponding private keys for different workloads and authorities^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__certs__README.md]:

  • Root CA: The root certificate (root-cert.pem) acts as the trust anchor. An alternative root (root-cert-alt.pem) is also provided for testing scenarios^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__certs__README.md].
  • Intermediate CA: The Citadel (Istio's CA) operates as an intermediate CA. The sample files (ca-cert.pem, ca-key.pem) allow Citadel to sign workload certificates under this root^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__certs__README.md].
  • Workload Certificates: These are the leaf certificates issued to specific services.

Trust Domains and SANs

A key concept in these samples is the Trust Domain, which forms part of the SPIFFE identity. The Subject Alternative Name (SAN) of a workload certificate contains the full SPIFFE URI^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__certs__README.md].

The samples demonstrate two distinct trust domains:

  • Trust Domain 'foo': The certificate workload-foo-cert.pem contains the SAN spiffe://trust-domain-foo/ns/foo/sa/foo.^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__certs__README.md]
  • Trust Domain 'bar': The certificate workload-bar-cert.pem contains the SAN spiffe://trust-domain-bar/ns/bar/sa/bar.^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__certs__README.md]

In these URIs, the structure typically follows the pattern spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>. These certificates are signed by the intermediate CA key (ca-cert.key)^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__certs__README.md].

Certificate Generation

The sample README outlines how these specific identities and certificates are generated using shell scripts^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__certs__README.md]:

  • Standard Generation: Running ./generate-workload.sh foo or ./generate-workload.sh bar creates the respective certificate and key files for those specific service identities^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__certs__README.md].
  • Alternative Root: Parameters can be passed to the script to generate certificates signed by the alternative root CA (e.g., root-cert-alt.pem), allowing for the simulation of multi-trust-domain or root rotation scenarios^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__certs__README.md].
  • [[Public Key Infrastructure|PKI]]
  • [[Zero Trust Network Architecture]]
  • Istio
  • [[Mutual TLS]]

Sources

^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__certs__README.md]