-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OIDC Client ID should be configurable via environment variable #1017
Comments
Hi, thanks for the feedback There no plan to change the way the OIDC Client ID is passed to Monocle, however if you'd like to propose a change to add the feature to override the Client ID from the config file via an environment variable that would be a nice contribution. Regarding the flow you described, you might need to wrap the Monocle deployment instructions (kubectl commands) into a script and override the Client ID, just after the OIDC secret resource is created by the operator. For instance by fetching the secret data, un-base64 then update the Monocle config file used to generate the configMap. |
Yep. I would like to try, just gotta learn Haskell first. Felt it was important to leave this issue as a marker in the meantime. |
For the record, here are the locations that needs to be changed in order to override the client id:
|
In our use case, OIDC client credentials are automatically issued via a Kubenetes operator along with the deployment of the client application (Monocle or other). The operator places both the Client ID and Client Secret in a kubernetes Secret resource.
In Monocle it's possible to configure the Client Secret via environment variable, but the Client ID must be provided in a config file mounted into the Pod. At the time at which the ConfigMap resource containing the Monocle configuration is constructed and passed to
kubectl apply
, the Client ID is not known nor predictable, pending the creation of the Secret resource by the OIDC client operator.If Monocle were to accept the OIDC Client ID via an environment variable the way it does with the Client Secret, this problem would be resolved.
The text was updated successfully, but these errors were encountered: