The SPIFFE runtime environment provides an implementation of SPIFFE specifications, to provide trust between software components.
This document provides an overview of how it is used in the example deployment.
SPIRE can be given an upstream root certificate authority and we provide one using cert-manager.
For demo purposes we use a root certificate with a 10 year lifetime.
A custom resource called a ClusterSPIFFEID is created in the helm-values.yaml
file:
default-spiffe-id:
spiffeIDTemplate: "spiffe://{{ .TrustDomain }}/ns/{{ .PodMeta.Namespace }}/sa/{{ .PodSpec.ServiceAccountName }}"
podSelector:
matchLabels:
spire-managed-identity: "true"
Workloads must use a label such as spire-managed-identity
to request a workload identity.
The SPIRE Controller Manager then registers an entry with the SPIRE server.
Workloads must then mount the SPIFFE Workload API to get SVIDs.
The SPIFFE CSI driver makes the SPIFFE Workload API available to application containers:
volumeMounts:
- name: spiffe-workload-api
mountPath: /spiffe-workload-api
readOnly: true
volumes:
- name: spiffe-workload-api
csi:
driver: "csi.spiffe.io"
readOnly: true
When pods mount the SPIFFE workload API they interact with the SPIRE agent instance on their Kubernetes node.
The SPIRE agent attests the workload and interacts with the SPIRE server to return SVIDs to the workload.
To integrate with Istio, the SPIRE agent must be updated to use the following fixed socket path.
Istio uses this fixed value and issues SPIRE identities to sidecars if the socket points to SPIRE:
/var/run/secrets/workload-spiffe-uds/socket
Use the following command to see details of the root certificate issued by cert-manager:
kubectl -n spire-server exec -t spire-server-0 -- ./bin/spire-server bundle show
Use an online certificate viewer to view the details:
Common Name : example-root-ca
Organization : example
Valid From : Jul 26,2024
Valid To : Jul 24,2034
Issuer : example