Workload Identity for Network Security with SPIFFE
The problem we are trying to solve with workload identity is how do we enable service identity using a trusted identity system, and how do we use service identity to provide authorization for service requests in a Kubernetes cluster.
With zero-trust, every workload requires its own cryptographically protected identity.
- A certificate has to be associated with every identity for it to be cryptographically protected
- This certificate can then be used for provisioning security policies with the certificate as the perimeter of security
The challenges for such an implementation are
- How do you provision certificates in your workloads?
- For dynamically scaling workloads how do you provision the certificates?
- Who manages the private keys?
- How do you control the revocation of certificates?
Accuknox’s identity solution uses SPIFFE and SPIRE to provide workload identity and attestation.
- Framework and set of standards
- SPIFFE ID, a standard defining how services identify themselves
- Standard for Encoding SPIFFE ID in cryptographically verifiable SVID document
- API spec for issuing/retrieving SVID
- Reference implementation
- Perform node/workload attestation
- Signing framework for securely issuing and renewing SVIDs
- API implementation for registering nodes/workloads using SVIDs
Why should developers care about SPIFFE
- Enables consistent security primitives across different cloud platforms
- Common identity mechanism across all platforms enabling ease of policy handling
- Improved security
- Mandatory certificate based authentication
- Removes dependency on k8s shared secret (or any other static tokens)
- Enables Short-lived certificates
- App-developers can delegate security to the platform
- Transparent transport security
- Deployment Agility, since the app-devs don’t need to care about certificate provisioning
Accuknox Identity integration solution for service identity using SPIFFE
Accuknox provides Identity integration for Service Identity (via SPIFFE Ids for services) and JWT tokens for user identities. Accuknox supports Envoy based service identity integration for services where a SPIRE server is used to issue valid service identities (SVIDs).
How does this work?
Node attestation happens and a SPIFFE ID is assigned to a node.
Node attestation is done using the underlying cloud infra to attest a node to the cluster. SPIRE provides plugins to handle attestation.
An SVID is the document with which a workload proves its identity to a resource or caller. An SVID is considered valid if it has been signed by an authority within the SPIFFE ID’s trust domain.
The SVID (which contains the SPIFFE id) is then assigned to the node. spiffe://example.org/agent/aws_iid/ACCOUNT_ID/REGION/INSTANCE_ID
Workload registration is done so that the workload attributes are saved and to acknowledge the receipt of the SVID
Transparent End to End Encryption
Once SVIDs are available to workloads, they can then be used to provide transparent end to end encryption
Policy enabling end to end encryption
Usinv SVID as a perimeter for Security Policies
- We can also use SPIFFE ID as a k8s label allowed for L3/L4 authz based on SPIFFE ID
- Thus, allows use of classic Cilium Identity model for L3/L4 authz
SPIFFE provides a strong identity base flexible for most scenarios
- Integrating SPIFFE natively in the Cilium CNI has advantages
- integration didn’t change any data-path eBPF handling in Cilium
SPIFFE now supports Delegation Identity APIs
- allowing privileged process to request SVIDs on behalf of the workload
- privileged process needs to be on the same node but not in the same pod
I help fin-tech digital product teams to create amazing experiences by crafting top-level UI/UX.