Workload Identities with OAuth

Demonstrates modern cloud-native techniques to use hardened OAuth client credentials for workloads.
Workloads can also potentially use sender-constrained OAuth access tokens to harden API requests.

Prerequisites

Deployments use a local Kubernetes cluster so your local computer needs the following prequisites:

• Docker
• KIND 0.30 or later
• Kubernetes CLI (kubectl)
• Helm

Also get a license file for the Curity Identity Server from the developer portal.

Deployment 1: Kubernetes Base System

The first deployment uses Kubernetes service account tokens with no need for additional infrastructure.
Workloads can use projected service account tokens to get a JWT credential for authentication.

• Run the Deployment

Deployment 2: Istio Service Mesh

The second deployment integrates the Curity Identity Server with an Istio service mesh.
The mesh upgrades internal OAuth requests to use mutual TLS, to ensure request confidentiality.

• Run the Deployment

Deployment 3: SPIFFE and SPIRE with JWT SVIDs

The third deployment integrates the Curity Identity Server with SPIFFE and SPIRE.
This deployment shows how workloads from any environment can use JWT SVIDs.

• Run the Deployment

Deployment 4: SPIFFE and SPIRE with X509 SVIDs

The fourth deployment also integrates the Curity Identity Server with SPIFFE and SPIRE.
This deployment shows how workloads can use X509 SVIDs as an authentication credential.

• Run the Deployment

More Information

• See the Non Human Identities tutorials for further details on the integrations.
• See the Kubernetes Tutorials for further related content, on topics like adding ingress and data sources.
• Please visit curity.io for more information about the Curity Identity Server.