Re: [EXTERNAL] Re: [cncf-helm] Is there any way to enforce constraints
|
Matt Butcher <matt.butcher@...>
The preferred method is requiring the user to set a value that points to an existing secret. If the user points to the wrong thing, then Helm should fail to deploy that release.
We advise people not to write charts that try to scan for SSL certificates on clusters, as that is a security warning sign. So I would advise not using
lookup in this (or any) case.
Helm is not and should not be used as a release manager tool. It is a package manager whose dependencies should be calculated up front and whose configuration should be passed by a user, not autoconfigured. In other words, think of Helm as 'apt-get', not 'chef'
or 'puppet'.
From: cncf-helm@... <cncf-helm@...> on behalf of Loritsch, Berin via lists.cncf.io <bloritsch=novetta.com@...>
Sent: Friday, January 15, 2021 12:46 PM To: cncf-helm@... <cncf-helm@...> Subject: [EXTERNAL] Re: [cncf-helm] Is there any way to enforce constraints It appears this did not garner any attention. Is there any way to enforce constraints on a chart's dependencies?
For example, I would like to have my chart enforce a specific _type_ of secret the consumer provides.
My container can use TLS secrets and make use of them if they are provided. However, it won't make sense if the user supplies a service account token or basic-auth token. It would be fine if the secret is not provided at all, but if it is provided it
should be a specific type.
I am clear on how to create the templates, and mount the secret to my container. I'm not clear on how to enforce rather important constraints like that.
On Tue, Jan 12, 2021 at 10:17 AM Loritsch, Berin <bloritsch@...> wrote:
Berin Loritsch
DOMEX Architect
7921 Jones Branch Drive Office (703) 735-6281 Mobile (571) 215-7708 |
|
|
