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
|
@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. |
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.
|
This PR introduces a new enhancement proposal that extends the Zero Trust Workload Identity Manager with automatic OIDC route creation capabilities.