Skip to content
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

Custom secret resource name for the admin account. #4051

Open
aabmets opened this issue Sep 30, 2023 · 2 comments
Open

Custom secret resource name for the admin account. #4051

aabmets opened this issue Sep 30, 2023 · 2 comments

Comments

@aabmets
Copy link

aabmets commented Sep 30, 2023

Problem

I'm installing weave-gitops into my project namespace, because the cluster is shared between many projects and users are not allowed to create cluster-wide resources. I want to use the admin account as a backup, but currently weave-gitops supports only a secret resource named cluster-admin-auth. For my use case, I want the secret to be named <myapp>-gitops-auth, but this cannot be done, because your weave-gitops software that runs in your weave-gitops docker images expects the secret to have the hardcoded name. It won't suffice to just use a different name in the Helm chart, because the Pod that runs your software will start screaming about not being able to find a secret named cluster-admin-auth.

Solution

I want to be able to define a custom name for the admin secret resource in the values.yaml file of the Helm chart.

Additional context

I cannot contribute to this feature, because this requires changes in the server source code, for which I lack the capabilities to modify.

@opudrovs
Copy link
Contributor

opudrovs commented Oct 2, 2023

@LappleApple I think the current issue is a duplicate of:
#2237

I picked up a PR for 2237 but after local testing (and I think I did test installing it via a local HelmChart) and releasing this feature, the app was thrown into a crash loop after installing it via a HelmChart. So, I rolled the changes back for the time being.

AFAIR, the crash was happening because the new dynamic admin secret name was not also added to viewSecretsResourceNames.

So, we could re-visit this issue later. I can update that PR, but I would need help with thorough testing from an OSS auth expert, like @foot , for example. Because I don't have much context on the auth and what "small" things can possibly go wrong.

@bigkevmcd
Copy link
Contributor

@opudrovs I'm happy to collaborate on this with you, and I've touched a lot of the auth code recently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants