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

Feat: Additional existing secrets #369

Merged
merged 3 commits into from
Mar 25, 2024
Merged

Feat: Additional existing secrets #369

merged 3 commits into from
Mar 25, 2024

Conversation

m4rg4sh
Copy link
Contributor

@m4rg4sh m4rg4sh commented Mar 19, 2024

Fixes: #368 #283 #370

This PR adresses several issues.

  • It fixes the regression described in Wrong Secret Keys for Redis and DB passwords #370 that breaks installation if existing secret refs are not used as redis and database passwords by changing the default keys.
  • It adds the possibility to also supply the NAUTOBOT_SECRET_KEY with a existing secret as requested in Add ability to provide secretKey via reference #283. The change should be backwards compatible by still allowing .Values.nautobot.secretKey to be specified but it also introduces a new structure named .Values.nautobot.django.* which takes priority. It still allows the user to specify a key in the configuration or, alternatively, to pass in a reference to an existing secret.
  • It also adds the possibility to pass in the NAUTOBOT_SUPERUSER_PASSWORD and _API_TOKEN in the same manner.

All these references can use a user-supplied secret and user-supplied key if necessary but do fall back to the defaults when necessary.
If no references or secret values are supplied the bitnami common chart is used to generate them and populate these secrets.
The superuser and secret key values are by default added to the existing *-env secret. But if referenced individually they are added as independet env variables to the relevant pods. If all of these variables are referenced to an existing secret the *-env secret becomes empty. However it is still created without any data to avoid broken secret references in the other objects.

If all of these features are used together it allows the user to not specify any secrets in the values.yaml file.

@m4rg4sh m4rg4sh force-pushed the develop branch 2 times, most recently from c068a6c to 781d711 Compare March 22, 2024 08:58
@m4rg4sh m4rg4sh changed the title Draft: Secret fixes and enhancements Feat: Existing secrets Mar 22, 2024
@m4rg4sh m4rg4sh changed the title Feat: Existing secrets Feat: Additional existing secrets Mar 22, 2024
@m4rg4sh m4rg4sh marked this pull request as ready for review March 22, 2024 09:19
@m4rg4sh m4rg4sh requested a review from ubajze as a code owner March 22, 2024 09:19
@m4rg4sh
Copy link
Contributor Author

m4rg4sh commented Mar 22, 2024

Hey @ubajze could you check this out, please? It's related to the previous PRs by @cardoe and myself.

@ubajze
Copy link
Contributor

ubajze commented Mar 22, 2024

@m4rg4sh, I'm sorry I haven't been more responsive, but I've been quite busy lately. I will try to schedule a time on Monday to check these PRs. Then we will have to prepare a new release to incorporate all these changes.

Copy link
Contributor

@ubajze ubajze left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@m4rg4sh I went through the PR. I think it all makes sense.

@ubajze ubajze merged commit af603ff into nautobot:develop Mar 25, 2024
2 of 4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add ability to provide superuser credentials via reference
2 participants