Istio CA Certificate Rotation and Management

SPIFFE

Istio implements the Secure Production Identity Framework for Everyone (SPIFFE) specification to issue identities. In short, Istio creates an X.509 certificate, which sets the certificate’s subject alternative name (SAN) to a uniform resource identifier (URI) that describes the service. Istio defers to the platform for identity attributes. In a Kubernetes deployment, Istio uses a pod’s service account as its identity, encoding it into a URI:

• Ex) spiffe://ClusterName/ns/Namespace/sa/ServiceAccountName

In Kubernetes, a pod will use the “default” service account for the namespace it’s deployed in if the ServiceAccount field is not set in the pod specification. This means that all services in the same namespace will share a single identity if service accounts aren’t already set up for each service.

SPIFFE is a specification for a framework that can bootstrap and issue identities. SPIRE (the SPIFFE Runtime Environment) is the SPIFFE community’s reference implementation, and Citadel (formerly Istio Auth) is a second implementation. The SPIFFE specification describes three concepts:

• An Identity, as a URI, used by services to communicate
• A standard encoding of that Identity into a SPIFFE Verifiable Identity Document (SVID)
• An API for issuing and retrieving SVIDs (the Workload API)
• SPIFFE requires that a service’s identity be encoded as a URI with the scheme spiffe, like: spiffe://trust-domain/path

The trust domain is the root of trust of the identity (e.g., an organization, an environment, or a team), and is the URI’s authority field (specifically the host section of the authority). The specification allows the path section of the URI to be anything—a universally unique identifier (UUID), a trust hierarchy, or nothing. On Kubernetes, Istio encodes a service’s ServiceAccount using the local cluster’s name as the trust domain, and creates a path using the ServiceAccount name and namespace. For example, the default ServiceAccount is encoded as:

• spiffe://cluster.local/ns/default/sa/default. (“ns” for namespace, “sa” for service account).

SPIFFE also describes how to encode this identity into an X.509 SVID. An X.509 certificate can be verified to prove identity. The specification stipulates that the Identity URI be encoded as the certificate’s SAN field. There are three verifications to perform when validating an SVID:

• Perform normal X.509 validation.
• Verify that there is exactly one SAN in the certificate with the SPIFFE scheme.
• Confirm that the certificate is not a signing certificate. Signing certificates cannot be used for identification according to the specification.

SPIFFE defines a Workload API, which is an API for issuing and retrieving SVIDs; however, this is where Istio diverges from SPIFFE. Istio implements certificate provisioning using a custom protocol, the CA Service, instead. The Citadel Node Agent issues a CSR via that API when a new workload is scheduled; Citadel performs validation on the request and returns an SVID for the workload. Both the SPIFFE Workload API and the CA service accomplish a similar goal (prove some information about the workload to receive an identity for it).

Finally, while the SPIFFE specification does not require it, both SPIRE and Istio issue X.509 SVIDs that are short lived—they expire on the order of an hour after issuance. This is in contrast with traditional usage of X.509 certificates, which tend to be used for HTTPS TLS termination and commonly expire a year or more after issuance.

• Benefits: Benefit of short-lived certificates is that attacks are bounded within that expiry time without requiring certificate revocation (and making revocation easy if you do choose to use it).
• Drawback: This use of short-lived certificates comes with one big disadvantage, though: it’s difficult to issue and rotate certificates on every workload across the fleet on a short interval.

---