SPIFFE in a Nutshell

I have been studying SPIFEE(Secure Production Identity Framework For Everyone)[1] for some time and here I am drafting the flow as I have understood now, for the benefit of anyone else trying to understand the flow.

• Identity Registry — SPIRE server has an own identity registry which keeps two coarse-grained attributes that decides how the SPIFFE IDs will be issued to a workload. It keeps details as in the below table.

A separate registration API is provided to manage these entries in the identity registry.

• Node Selector — This defines a machine (physical or virtual) where a workload can be running on. The exact type of selector to be used is decided based on the infrastructure provider (AWS, GCP, bare metal) that the workload is running. Eg. AWS EC2 Instance ID, a serial number of a physical machine. Node attestor act based on the infrastructure provider to honor their selectors.
• Workload Selector — This defines how to identify a process as representing a workload, after the node is identified. This can be described in terms of attributes of the process itself (eg. Linux UID) or in terms of indirect attributes such as a kubernetes namespace. The node agent is responsible to verify that a particular process on a machine qualifies for its workload selector. Workload attestor act based on the process attributes to honor the process selectors.
• SPIRE Node Agent — A process that sits on the node, verifies the provenance of workloads running on the node, and provides those workloads with certificates via the Workload API, based on the selectors.

1. Registration API is called by either an administrator or a third party application to populate the identity registry with the required SPIFFE IDs and relevant selectors.
2. Node agent gets authenticated with the SPIRE server using a pre-established cryptographic key pair or based in the infrastructure provider. For example in the case of AWS EC2, node agent will submit the node’s Instance Identification Document(IID) issued by AWS.
3. Node attestor in the SPIRE server validates the provided identification document based on the used mechanism. If the AWS IID is used, the relevant attestor will validate it with AWS settings. Upon successful validation, SPIRE server sends back a set of SPIFFE IDs that can be issued to the node along with their process selector policies.
4. When workload start to run in the node, it first makes a call to the node agent asking ‘who am I?’.
5. Based on the process selectors node agent received in the previous step, and using the workload attestors, the agent decides on the SPIFFE ID to be given to workload. It generates a key pair based on that and sends the CSR(Certificate Signing Request) to the SPIRE server.
6. SPIRE server responds to the node agent with the signed SVID for the workload along with the trust bundles, indicating which other loads can be trusted by this workload.
7. Upon receiving the response from SPIRE server, node agent, handover the received SVID, trust bundles the generated private key to the workload. This private key never leaves the node its workload belongs to.

Please feel free to suggest any correction, if you notice.

[1] — https://spiffe.io

[2] — https://docs.google.com/document/d/1RZnBfj8I5xs8Yi_BPEKBRp0K3UnIJYTDg_31rfTt4j8/edit#

[3] — https://pushpalankajaya.blogspot.com/2018/12/authorization-for-multi-cloud-system.html

Originally published at pushpalankajaya.blogspot.com.