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. 

SPIFFE is 

  • 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

SPIRE is

  • 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. 

Example: spiffe://example.org/agent/aws_iid/ACCOUNT_ID/REGION/INSTANCE_ID

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

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

Summary

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

Other articles

Nat Natraj

Nat Natraj

July 13, 2021
Nat Natraj

Nat Natraj

July 13, 2021
Nat Natraj

Nat Natraj

July 13, 2021