Feature Overview (aka. Goal Summary)  

OpenShift Service Mesh (OSSM) 3.0 is based on Istio and centrally manages Envoy sidecars for service-to-service communication. ZTWIM is Red Hat’s productized implementation of SPIFFE/SPIRE for OpenShift, providing workload identity based on cryptographic attestation, short-lived credentials, and automated rotation.

Customer benefits: 

ZTWIM brings the missing pieces:
• Attested identity issuance
• Workload API
• Short-lived SVIDs as first-class primitives
• X.509-SVID and JWT-SVID semantics
• Portable trust domains
• Federation-ready

This work will integrate OSSM 3.0 with ZTWIM so that Envoy sidecars and mesh-managed workloads can consume SPIFFE-based identities issued by ZTWIM and use them for authentication and authorization in production environments.

The integration will be implemented and validated for the following three use cases:

1. Envoy with SPIFFE and ZTWIM (general identity integration)

1. Envoy with X.509-SVIDs (mTLS using SPIFFE IDs)

1. Envoy with JWT-SVIDs (token-based SPIFFE identity)

Goals:

• Enable OSSM workloads to use ZTWIM-issued SPIFFE identities in production

• Leverage ZTWIM’s short-lived, attested credentials

• Enable Envoy sidecars to consume ZTWIM-issued credentials

• Enforce identity-based authentication and authorization using SPIFFE IDs

• Support automated rotation and revocation

• Ensure operational stability, observability, and upgrade compatibility

• Produce reference configurations and runbooks

Use Case 1: Envoy with SPIFFE and ZTWIM (General Identity Integration)

Objective:
Enable workloads in OSSM 3.0 to consume SPIFFE identities issued by ZTWIM and make them available to Envoy for authentication and authorization decisions in a production environment.

Engineering scope:

• Integrate Envoy sidecars with ZTWIM using supported Istio extension points (e.g., SDS, EnvoyFilters, ext_authz, JWT filters)

• Ensure SPIFFE IDs are available to Envoy for downstream and upstream identity decisions

• Enable identity propagation across services in the mesh

• Ensure credentials are short-lived and automatically rotated

• Ensure behavior is stable across pod restarts, node restarts, and upgrades

Deliverables:

• Production-ready OSSM deployment using ZTWIM-issued SPIFFE identities

• Architecture diagram of the identity flow

• Sample configuration manifests

• Operational documentation (setup, rotation, failure modes)

Use Case 2: Envoy with X.509-SVIDs (mTLS using SPIFFE IDs)

Objective:
Secure service-to-service communication using SPIFFE-based X.509-SVIDs issued by ZTWIM and integrated with OSSM 3.0 for production use.

Engineering scope:

• Configure Envoy sidecars to obtain X.509-SVIDs from ZTWIM

• Integrate ZTWIM with Istio’s mTLS mechanisms using supported extension points

• Ensure SPIFFE IDs appear in certificate SANs

• Configure trust bundles and trust domain handling

• Enable automated certificate rotation and revocation

• Enforce identity-based authorization using SPIFFE IDs

• Validate behavior under credential expiration, rotation, and ZTWIM outages

Validation requirements:

• mTLS between services uses ZTWIM-issued certificates

• Mutual authentication is based on SPIFFE IDs

• SPIFFE identities are used in authorization decisions

• Traffic is denied if SPIFFE identity does not match policy

• Rotation occurs without traffic disruption

Deliverables:

• Production-grade configuration

• Example policies

• Certificate and trust chain validation outputs

• Runbooks for rotation, incident response, and troubleshooting

Use Case 3: Envoy with JWT-SVIDs (Token-based SPIFFE Identity)

Objective:
Enable JWT-SVIDs issued by ZTWIM to be validated and enforced by Envoy and OSSM authorization mechanisms in production.

Engineering scope:

• Configure ZTWIM to mint JWT-SVIDs for workloads

• Configure Envoy and OSSM to validate JWT-SVIDs (JWT Filter)

• Extract SPIFFE ID and claims from JWT-SVIDs

• Enforce authorization decisions based on JWT-SVID identity

• Support service-to-service access control using JWT-SVIDs

• Validate token rotation, expiration, and revocation behavior

Validation requirements:

• JWT-SVIDs are minted by ZTWIM

• Envoy validates JWT-SVIDs

• OSSM policies enforce SPIFFE identity

• Unauthorized identities are denied

• Token rotation does not break traffic

Deliverables:

• Production-grade JWT-SVID identity flows
• Token validation examples
• Docs

Cross-cutting production requirements:

• ZTWIM is the source of SPIFFE identities for workloads

• Credentials must be short-lived and automatically rotated

• No manual credential injection

• All integrations must use supported Istio extension points

• Identity must survive pod restarts, node drains, and rolling upgrades

• Metrics, logs, and alerts must exist for identity issuance and failures

• Clear documentation must exist for setup, teardown, rotation, and incident response

Success criteria:

• Envoy sidecars consume ZTWIM-issued credentials

• SPIFFE IDs are visible and usable for authN and authZ

• X.509-SVID and JWT-SVID flows both work

• Identity-based authorization is enforced

• Rotation and expiration are handled without downtime

• Setup is reproducible

• Upgrade paths are documented

Requirements (aka. Acceptance Criteria):

Activity	Dependencies	Dependency contacts
Service Mesh already supports SPIRE upstream. This effort is to integrate Operator with RHOSM and provide federation support	OpenShift ServiceMesh team	Jamie Longmuir Nir Yechiel

 __ 

Anyone reviewing this Feature needs to know which deployment configurations that the Feature will apply to (or not) once it's been completed.  Describe specific needs (or indicate N/A) for each of the following deployment scenarios. For specific configurations that are out-of-scope for a given release, ensure you provide the OCPSTRAT (for the future to be supported configuration) as well.

Use Cases (Optional):

Include use case diagrams, main success scenarios, alternative flow scenarios.  Initial completion during Refinement status.

At a minimum we should be able to do the integrations mentioned https://spiffe.io/docs/latest/microservices/

OPA Authorization 

Questions to Answer (Optional):

Include a list of refinement / architectural questions that may need to be answered before coding can begin.  Initial completion during Refinement status.

<your text here>

Out of Scope

High-level list of items that are out of scope.  Initial completion during Refinement status.

<your text here>

Background

Provide any additional context is needed to frame the feature.  Initial completion during Refinement status.

<your text here>

Customer Considerations

Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.  Initial completion during Refinement status.

<your text here>

Documentation Considerations

Provide information that needs to be considered and planned so that documentation will meet customer needs.  If the feature extends existing functionality, provide a link to its current documentation. Initial completion during Refinement status.

<your text here>

Interoperability Considerations

Which other projects, including ROSA/OSD/ARO, and versions in our portfolio does this feature impact?  What interoperability test scenarios should be factored by the layered products?  Initial completion during Refinement status.

<your text here>