OIDC, SPIFFE Workload Identity, Service Mesh Analysis

• OIDC user identity focuses on user identity and is user-centric, whereas SPIFFE workload identity handles workload identities and authentication (e.g., services, containers).

  • OIDC: 

    • Identity Representation: user-centric claims (subject, email, name)

    • Authentication Method: OAuth2/OIDC tokens (JWTs)

    • Use Cases: Web app authentication and federation

    • Integration: Web apps, API gateways, CI/CD tools

    • Trust Domain: Defined by the IdP

  • SPIFFE Workload Identity: 

    • Identity Representation: SPIFFE ID (e.g., spiffe://trust-workload-name)

    • Authentication Method: X.509 certificates or JWTs

    • Use Cases: Service-to-service authentication

    • Integration: Kubernetes, service mesh, multiple cluster/cloud environments

    • Trust Domain: defined by SPIFFEE trust domains

• OIDC and SPIFFE can work together. 

  • Bridging user and work authentication; SPIFFE can authorize workloads acting on behalf of a user authenticated via OIDC

  • Interoperable Tokens: SPIFFE certificates or tokens can interoperate with systems expecting OIDC-based tokens

  • Combined Policies: Policies can be created for both OIDC user identities and SPIFFEE workload identities. For example, a specific user (via OIDC) may trigger a workload authenticated by SPIFFE

  • Complementary Functions: OIDC authenticates the user to a service, while SPIFFE secures subsequent service-to-service communication using workload identities

ONAP Context: 

In ONAP, user identities via OIDC are used alongside a Service Mesh, which secures service-to-service communication within a single cluster (with SPIFFE, a service mesh can work across multi cluster/clouds).

A direct comparison of service-to-service security should focus on Service Mesh vs. Workload identity. 

SPIFFE vs. Service Mesh:

• SPIFFE workload identity:

  • Focus: Securely identifying workloads

  • Core features: Providing unique, verifiable identities for workloads, mTLS; short-lived certificates or tokens

  • Use Case: Service-to-service authentication, federated identity across clusters or clouds

  • Integration: Integrates with existing Kubernetes, CI/CD, and other systems

• Istio Service Mesh:

  • Focus: Managing traffic between services

  • Core features: Traffic management (e.g., retries and load balancing), observability (metrics, tracing and logging), secure communication

  • Use case: advanced traffic routing and control, encrypting and managing service communication

  • Integration: integrates into the application network stack

• SPIFFE and Service Mesh can work together

  • Complementary Capabilities: SPIFFE provides robust workload identities and authentication, while service meshes handle traffic management, observability and security

  • Istio and SPIFFE Integration: Istio Service Mesh supports SPIFFE for secure microservice communication across multi-cluster or multi-cloud environments

  • Policies in the service mesh can leverage SPIFFE IDs, enabling fine-grained access control on workloads

OIDC-based Identities, SPIFFE-based identities, and Service Mesh handle distinct domain issues and can work together.