Problem Description
When using OpenShift authentication, users are automatically logged out during cluster upgrades because the console generates new random cookie encryption keys on every restart.
Current Behavior
In pkg/auth/oauth2/auth_openshift.go, the OpenShift authentication method generates random keys on each startup:
authnKey, err := utils.RandomString(64)
encryptionKey, err := utils.RandomString(32)
This causes all existing cookies to become invalid when the console pod restarts during upgrades, forcing users to re-authenticate.
Proposed Solution
Make cookie keys configurable for OpenShift authentication (similar to OIDC), allowing them to be persisted via Kubernetes secrets.
The infrastructure already exists in cmd/bridge/config/session/sessionoptions.go:
--cookie-encryption-key-file flag
--cookie-authentication-key-file flag
However, the validation in Validate() explicitly rejects these for non-OIDC auth types.
What is the reasoning behind not allowing other AuthTypes, such as those from the oauth-server (LDAP)? Would this feature be acceptable for inclusion? I'm happy to implement it if there's interest from the maintainers.
Problem Description
When using OpenShift authentication, users are automatically logged out during cluster upgrades because the console generates new random cookie encryption keys on every restart.
Current Behavior
In
pkg/auth/oauth2/auth_openshift.go, the OpenShift authentication method generates random keys on each startup:This causes all existing cookies to become invalid when the console pod restarts during upgrades, forcing users to re-authenticate.
Proposed Solution
Make cookie keys configurable for OpenShift authentication (similar to OIDC), allowing them to be persisted via Kubernetes secrets.
The infrastructure already exists in cmd/bridge/config/session/sessionoptions.go:
However, the validation in Validate() explicitly rejects these for non-OIDC auth types.
What is the reasoning behind not allowing other AuthTypes, such as those from the oauth-server (LDAP)? Would this feature be acceptable for inclusion? I'm happy to implement it if there's interest from the maintainers.