-
Notifications
You must be signed in to change notification settings - Fork 69
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
Add Capability to Inject Secrets, Configuration, Templates and Certificates #46
Conversation
Running into issues, going to close this PR and keep poking at it |
Okay, got the kinks worked out in my load balancer and database configuration. Should be good for review @maraino. |
going to work on the documentation for a bit tonight. |
Added documentation for new values fields. |
- Enables users to inject: - secrets - certificates - configuration - templates - Enables users to configure all capabilities of step-certificates using only the helm chart. - Enables users to use the native yaml to configure ca.json and have helm automatically translate it to json. Related Issues: - smallstep#45 - smallstep#2 - smallstep#9 add manifest separator fix formatting issue that results in invalid yaml. Add ability to inject configuration using values.yml. Add ability to inject certificates. add ssh key locations Clean up extra newlines and add template support remove configuration when injecting secrets Refactor secrets and clean up config maps simplified the secrets to eliminate complexity in ca.yaml Add readme documentation.
3da9022
to
f652c56
Compare
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.
Wow, this looks amazing, I've added a small comment, but if you can edit the conditions that display the bootstrap Job, Secrets, and ConfigMaps to depend on the inject variables it will make the users's values.yaml easier.
For example, if the inject of config, certificates and secrets are enabled, you don't need the bootstrap Job. If the inject of config is enabled you don't need the ConfigMap that has the contains the ca.json, ...
I can see that this might get a little bit complicated, we should consider if it just makes sense to have an inject.enabled
that disables the all the bootstrap resources, and forces you to set all the config, certificates, and secrets. What do you think?
There might be some users that only want to define a custom ca.json and let the bootstrapper create the secrets. But I think this can cause race conditions where the bootstrapper overwrites the ca.json
, and unless we add some "ifs" to the script we won't be able to solve those race conditions. So as I said before, we should consider if supporting all the cases makes sense.
- cleans up configmaps based on feedback. - Enabling inject.enabled now overrides and disabled any bootstrap functionality.
@maraino thanks for the review and pointing out where I could simplify the experience for the users. I have updated the pr to use a single enabled flag, rather than three and updated the conditions in the templates such that when |
There's no need to wait for 20 seconds until the configuration is ready if we inject it.
For some reason replacing a secret with a type does not properly work. The bootstrap script fails with the following message: ``` The Secret "step-certificates-ca-password" is invalid: type: Invalid value: "Opaque": field is immutable ```
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.
I had to make some changes to be able to run the bootstrapper properly.
Add ability to inject secrets, config & templates.
Enables users to inject:
Enables users to configure all capabilities of
step-certificates using only the helm chart.
Enables users to use the native yaml to configure
ca.json and have helm automatically translate it
to json.
Related Issues: