SPIRE-150: Adds enhancement proposal for integrating OIDC route for Zero Trust Workload Identity Manager #1824
Conversation
openshift-ci
bot
added
the
do-not-merge/work-in-progress
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
anirudhAgniRedhat
force-pushed
the
oidc-route
branch
3 times, most recently
from
5a825af to
7cdf7cf
Compare
| - As a **cluster administrator** managing SPIRE deployments, | ||
| I want OIDC routes to be created automatically without additional configuration, | ||
| So that I can focus on trust domain management rather than networking and certificate setup. | ||
| - As a **cluster administrator** managing SPIRE deployments, I want OIDC discovery routes to be created and managed automatically (including cleanup) when I deploy or delete a `SpireOIDCDiscoveryProvider` so that external services can access SPIFFE identity verification endpoints without requiring me to manually configure networking, certificates, or route lifecycle management. |
There was a problem hiding this comment.
This user story covers entire feature, can you break it down to different user stories? Please refer to https://github.com/openshift/enhancements/blob/master/guidelines/enhancement_template.md#user-stories
| - As a **security engineer** responsible for cluster security, | ||
| I want OIDC discovery endpoints to be exposed with secure TLS termination by default, | ||
| So that external clients can safely discover SPIFFE identity information without compromising security. | ||
| - As a **security engineer** implementing zero-trust architecture, I want OIDC discovery endpoints to be exposed through secure TLS-terminated routes with automatic certificate management so that external clients can safely discover and validate SPIFFE workload identities while maintaining end-to-end encryption and security best practices. |
There was a problem hiding this comment.
What is the context of zero-trust architecture in this usecase?
| So that external clients can safely discover SPIFFE identity information without compromising security. | ||
| - As a **security engineer** implementing zero-trust architecture, I want OIDC discovery endpoints to be exposed through secure TLS-terminated routes with automatic certificate management so that external clients can safely discover and validate SPIFFE workload identities while maintaining end-to-end encryption and security best practices. | ||
|
|
||
| - As a **DevOps engineer** deploying applications that verify workload identities, I want to easily discover the OIDC endpoint URL with a predictable pattern so that I can configure my external services to validate JWT tokens from workloads running in the OpenShift cluster without needing deep knowledge of OpenShift networking internals. |
There was a problem hiding this comment.
This is internal to the oidc discovery implementation, how does this enhancement intend to propose solution of discovery?
anirudhAgniRedhat
changed the title
openshift-ci-robot
added
the
jira/valid-reference
openshift-ci
bot
removed
the
do-not-merge/work-in-progress
|
@anirudhAgniRedhat: This pull request references SPIRE-150 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.20.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
anirudhAgniRedhat
force-pushed
the
oidc-route
branch
from
8479c19 to
33e002f
Compare
anirudhAgniRedhat
force-pushed
the
oidc-route
branch
from
33e002f to
5d95045
Compare
There was a problem hiding this comment.
LGTM expect for one case:
Do we plan to add support for users to configure per-route TLS certificates in future? (Perhaps by utilizing Route's spec.tls.externalCertificate field)
IMHO that'd help improve the solution's flexibility. Currently the Entra ID users won't benefit from this enhancement if replacing cluster-wide ingress certs is not a feasible option for them. They need to explicitly disable this feature and create an Ingress/Route with custom TLS on their own in order to serve OIDC provider certificates issued from a publicly trusted CA.
|
|
|
||
| ## Summary | ||
|
|
||
| This enhancement extends the existing Zero Trust Workload Identity Manager controller to automatically create OIDC routes that enable external access to SPIRE OIDC Discovery Provider endpoints through OpenShift Routes. When a `SpireOIDCDiscoveryProvider` is deployed, the enhanced controller will automatically create routes to provide secure, externally accessible OIDC endpoints for workload identity verification and JWT token validation in multi-cluster and hybrid cloud environments. |
There was a problem hiding this comment.
Please update the "This enhancement proposes exposing SPIRE OIDC Discovery Provider endpoints through OpenShift Routes under the domain *.apps. for the selected default installation."
|
|
||
| ## Motivation | ||
|
|
||
| The current Zero Trust Workload Identity Manager provides OIDC Discovery Provider functionality through internal cluster services. However, in distributed and multi-cluster environments, external services and workloads running outside the OpenShift cluster need access to OIDC endpoints. |
There was a problem hiding this comment.
Replace with
"The SpireOIDCDiscoveryProvider serves as a critical bridge between SPIFFE identities and OIDC standards, allowing external systems to validate and trust SPIRE-issued JWTs. By exposing well-known endpoints (/.well-known/openid-configuration and /keys), it provides the OIDC discovery document and corresponding public keys required for verifying JWT-SVIDs.
In OpenShift environments, administrators need a straightforward and reliable way to make these endpoints accessible. They may choose to leverage the default OpenShift wildcard DNS entry (*.apps.), which points to the ingress routers, or alternatively configure a custom DNS entry that aligns with organizational requirements. Providing flexibility in how the SpireOIDCDiscoveryProvider endpoints are exposed ensures smoother integration with external identity consumers and supports varied deployment scenarios."
|
|
||
| ### User Stories | ||
|
|
||
| - As a OCP user using Zero Trust Workload Identity Manager, I want OIDC discovery routes to be created and managed by the operator when I enable the `managedRoute` flag so that I can access and verify the jwt tokens from the oidc discovery provider application through an endpoint. |
There was a problem hiding this comment.
- As an OpenShift cluster administrator, I want to enable a managed Route for the SPIRE OIDC Discovery Provider by setting spec.managedRoute.enabled: true, so that the discovery endpoints are exposed on the cluster’s default *.apps.<cluster-domain> without additional YAML or manual DNS steps.
- As an OpenShift cluster administrator, I want to optionally specify a custom host, so that I can expose the OIDC issuer on an organization-owned domain (e.g., oidc.example.com) that aligns with corporate DNS and certificate policies
- As an OpenShift cluster administrator, I want to disable the managed Route by setting, so that I can expose the endpoints through self-managed OpenShift routes or ingress.
- As an Openshift security engineer, I want to attach labels/annotations to the managed Route, so that I can integrate with tools for auditability.
- As an SRE, I want clear status conditions on the CR and events, so that I can quickly diagnose exposure, DNS, or certificate issues.
- As an OpenShift cluster administrator, I want RBAC guardrails and explicit errors if the operator lacks permission to manage Routes, so that I can understand required privileges and safely delegate responsibilities.
- As an OpenShift cluster administrator, I want the managed Route to default to Service CA certificates so that the endpoints are automatically secured and trusted in-cluster without manual certificate management.
- As an Openshift security engineer, I want the managed Route to support re-encrypt termination so that TLS is enforced end-to-end with cluster-managed certificates, providing stronger security than edge while avoiding the operational burden of passthrough.
| - Create default OpenShift Routes for OIDC discovery endpoints when a `SpireOIDCDiscoveryProvider` resource is deployed | ||
| - Routes are created with consistent naming and labeling conventions | ||
| - Implement reencrypt TLS termination to maintain end-to-end encryption | ||
| - Integrate with OpenShift's Service CA operator for automatic certificate provisioning and renewal |
There was a problem hiding this comment.
- Provide a managed Route option for the SpireOIDCDiscoveryProvider that automatically exposes OIDC discovery endpoints on the cluster’s default *.apps. domain.
- Allow administrators to disable the managed Route, supporting self-managed exposure of the endpoints through OpenShift Routes, ingress, or service mesh gateways.
- Support attaching labels and annotations to the managed Route for better auditing and monitoring.
- Default the managed Route to use Service CA–issued certificates, ensuring automatic TLS and certificate rotation.
- Default re-encrypt termination for the managed Route, providing end-to-end TLS with cluster-managed certificates as a stronger security option compared to edge termination, while avoiding the complexity of passthrough.
- Provide clear status conditions and events so that SREs can quickly diagnose DNS, TLS, or exposure issues.
- Validation check to reject updates to Route termination type or configurations that override usage of ServiceCA operator managed certificates.
- Allow the use of custom PKI with the default managed Route for TLS connections between clients and the ingress router.
| - Integrate with OpenShift's Service CA operator for automatic certificate provisioning and renewal | ||
|
|
||
| ### Non-Goals | ||
| - Implement custom ingress controllers or load balancers |
There was a problem hiding this comment.
- Manage custom PKI without default managed Route.
- Deletion of default managed Route automatically when the option is disabled.
- Support managed Route for applications that are not using default Openshift *.apps.<cluster-domain>
- Reconciliation of updates to DNS changes for SpireOIDCDiscoveryProvider endpoints.
- Support edge and passthrough termination types for default managed Route.
- Support usage of SVIDs for SpireOIDCDiscoveryProvider endpoints.
- Custom PKI integration for the default managed Route of the SpireOIDCDiscoveryProvider endpoints to replace Service CA–issued certificates when using re-encrypt termination.
anirudhAgniRedhat
force-pushed
the
oidc-route
branch
3 times, most recently
from
fcd241a to
b30a162
Compare
anirudhAgniRedhat
force-pushed
the
oidc-route
branch
from
b30a162 to
dcaebbf
Compare
|
@anirudhAgniRedhat: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
This PR introduces a new enhancement proposal that extends the Zero Trust Workload Identity Manager with automatic OIDC route creation capabilities.