-
Notifications
You must be signed in to change notification settings - Fork 26
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
patch: enable existing secrets + minor ingress fixes #34
Conversation
This introduces the option for an existing secret to be supplied with the credentials for postgres, smtp, redis and s3. By allowing users to roll their own secrets for these values, we improve their security as they don't have to hard code any values into their supplied `values.yaml` file. The presumption is that if a user is supplying some credentials via a secret then all of the listed ones should be supplied.
The ingress manifests had some invalid references and a duplicate secretName for the tls which has now been corrected.
Just saw this 🤦 I'll close this |
@drew-viles you can keep it open, #16 have some breaking changes |
aaah thanks very much. I should have checked there first and this is just the first steps into lago I've taken (I was given it today to deploy into our infra). I'll keep trying to help out where I can though as I realise it's fairly early days (relatively speaking) for the chart! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, did you test it with both options or should I do a bunch of tests on it?
I ran a helm template command and reviewed the results both with and without the exstingSecret value but have only deployed using an external postgres/redis so far as I was in a fix to get that up and running yesterday. Happy to test this morning without it to ensure it works that way too. Give me a few minutes and I'll confirm for you! |
So it works fine but only if I provide this value: However, that value also has a typo in it (capitalised c) so I'll update that and get it pushed along with an update to the README about how it's required - unless we're happy to presume it as we do with the migrate job. It seems to stem from redis, for example, being enabled which in turn requires that value. Let me know your thoughts and I'll make any changes. |
oh yes we should use |
ok cool. I've got my standup shortly so once finished I'll take a look at those changes. |
ok I've pushed those changes now. I've adjusted how the All tested again too in terms of creating the release, creating an account and interacting with elements of the app. As I say I picked this up for the first time yesterday so if there are other things you can think of that need testing let me know. |
This introduces the option for an existing secret to be supplied with the credentials for postgres, smtp, redis and s3. By allowing users to roll their own secrets for these values, we improve their security as they don't have to hard code any values into their supplied
values.yaml
file.The presumption is that if a user is supplying some credentials via a secret then all of the listed ones should be supplied.
This also fixes a few issues with the ingress resources around invalid values references and how the secretName is defined.