dex: run 2 replicas without sticky service

[danish9039]

Summary of Changes

This PR updates Dex to run with replicas: 2 and aligns the validation strategy with Dex's Kubernetes-backed state model.

Instead of adding sticky routing, the change keeps the Dex Service non-sticky and adds validation that multi-replica authentication works correctly when Dex state is shared via Kubernetes CRDs.

Changes:

• common/dex/base/deployment.yaml
  • replicas: 1 -> 2
• common/dex/base/service.yaml
  • add explanatory comments clarifying why sessionAffinity is not required with storage.type=kubernetes
• tests/dex_login_test.py
  • refactor Dex login flow handling (timeouts, explicit request helpers, improved 403/oauth2 recovery path)
  • add parallel authentication burst (PARALLEL_SESSIONS=8)
  • assert authentication traffic is observed across at least two Dex pods
  • assert Dex authcode CRD objects are garbage-collected after the wait window

Dependencies

• None

Related Context

• Follow-up to the local investigation and review discussion: synchronize(dex): bump Dex manifests to v2.45.0 #3364 (comment)

Contributor Checklist

• I have tested these changes locally with kustomize.
• All commits are signed-off to satisfy the DCO check.
• I have considered adding my company to the adopters page to support Kubeflow and help the community, since I expect help from the community for my issue.

Local Validation

Validated on a fresh kind cluster using the Dex login flow and updated test:

• common/kubeflow-namespace/base
• ./tests/istio-cni_install.sh
• ./tests/oauth2-proxy_install.sh
• common/istio/kubeflow-istio-resources/base
• ./tests/dex_install.sh
• ./tests/central_dashboard_install.sh
• ingress port-forward
• python3 tests/dex_login_test.py

Observed result:

• both Dex pods became Ready
• single authentication passed
• parallel authentication validation passed
• authcode GC validation passed

Conclusion:

• Dex works with replicas: 2 without service stickiness when using Kubernetes-backed Dex storage, and the updated test now validates replica distribution and authcode cleanup behavior.

[github-actions]

Welcome to the Kubeflow Manifests Repository

Thanks for opening your first PR. Your contribution means a lot to the Kubeflow community.

Before making more PRs:
Please ensure your PR follows our Contributing Guide.
Please also be aware that many components are synchronizes from upstream via the scripts in /scripts.
So in some cases you have to fix the problem in the upstream repositories first, but you can use a PR against kubeflow/manifests to test the platform integration.

Community Resources:

• CNCF Slack channels: https://www.kubeflow.org/docs/about/community/#kubeflow-slack-channels
• Community meetings: https://www.kubeflow.org/docs/about/community/

Thanks again for helping to improve Kubeflow.

[Copilot]

Pull request overview

Updates the Kubeflow Dex base manifests to run Dex with two replicas and attempts to keep the multi-step login flow stable by enabling sticky routing at the Kubernetes Service layer.

Changes:

• Increase Dex Deployment replicas from 1 to 2
• Add sessionAffinity: ClientIP to the Dex Service

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
common/dex/base/deployment.yaml	Scales Dex to 2 replicas to improve availability.
common/dex/base/service.yaml	Enables Service-level ClientIP session affinity to reduce cross-pod auth-flow breakage.

[juliusvonkohout]

Thank you @danish9039

Let us please be precise as explained in the copilot-instructions.md. This is about authentication and not authorization.
Also check the naming convention in general in this file.

Are you sure that the storage backend supports it well https://github.com/danish9039/manifests/blob/d1b9474e935ef96d6786722b6c2d4c077e50674b/common/dex/base/config-map.yaml#L11 ? And please extend the Dex test to verify that multiple parallel sessions to different replicas and garbage collection works.

[google-oss-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign juliusvonkohout for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[danish9039]

Thank you @danish9039

Let us please be precise as explained in the copilot-instructions.md. This is about authentication and not authorization. Also check the naming convention in general in this file.

Are you sure that the storage backend supports it well https://github.com/danish9039/manifests/blob/d1b9474e935ef96d6786722b6c2d4c077e50674b/common/dex/base/config-map.yaml#L11 ? And please extend the Dex test to verify that multiple parallel sessions to different replicas and garbage collection works.

@juliusvonkohout Thank you for the feedback, sorry for the delay!
I updated tests/dex_login_test.py to keep the scope strictly on authentication, not authorization. The test now treats a completed OAuth callback plus oauth2_proxy session cookie as authentication success even if the final landing page is rejected later by RBAC, and I cleaned up the naming/comments to stay explicit about that distinction.

I also extended the test to validate the storage.type=kubernetes setup from common/dex/base/config-map.yaml by running parallel login sessions against the 2-replica Dex deployment, checking from Dex pod logs that both replicas actually handled authentication traffic, and inspecting authcodes.dex.coreos.com before and after the wait window. The kubectl calls are needed because the HTTP client alone cannot prove replica distribution or backend state behavior: pod discovery confirms the multi-replica setup, pod logs show where the authentication requests landed, and authcode counts let us observe the Kubernetes-backed auth state directly.

For garbage collection, the intent is to make sureauthcodeobjects created as part of the login flow do not persist unexpectedly after the exchange completes. With storage.type=kubernetes, Dex stores that transient auth state in Kubernetes resources, so checking the authcode count before the parallel auth login burst, after the burst, and again after GC_WAIT_SECONDS gives us a direct cluster-side signal that cleanup is still working and that the parallel flow is not leaving stale auth state behind.

[danish9039]

@juliusvonkohout can we proceed with this ?

[juliusvonkohout]

"The test now treats a completed OAuth callback plus oauth2_proxy session cookie as authentication success even if the final landing page is rejected later by RBAC" We must also test the authorization and RBAC later. Please do not remove it.

[juliusvonkohout]

CC also @abdullahpathan22 for review

[juliusvonkohout]

Please do not rely on kfp in a Dex / oauth2-proxy test. You also have to sign the dco. Less code is better and means less maintenance effort.

[danish9039]

"The test now treats a completed OAuth callback plus oauth2_proxy session cookie as authentication success even if the final landing page is rejected later by RBAC" We must also test the authorization and RBAC later. Please do not remove it.

@juliusvonkohout Just to clarify, this PR does not remove any existing RBAC / authorization coverage from the Dex workflow; that coverage was not part of this test path before.
I removed the later sidecar authorization test and kept this PR focused on Dex authentication, while the existing authorization checks remain in the component integration tests.