cncf-helm@lists.cncf.io | [EXTERNAL] Re: [cncf-helm] Is there any way to enforce constraints

Home Messages Hashtags Subgroups

Date Date 1 - 3 of 3

[EXTERNAL] Re: [cncf-helm] Is there any way to enforce constraints

Matt Fisher <matt.fisher@...> #358 So if I’m understanding correctly, you’re looking to validate that a particular resource provided by the user follows a certain schema. Kubernetes resources define a schema (also known as a GroupVersionKind, or a GVK) which determines whether the resource is well-formed or not. Custom resources can be defined by the user to conform to a custom schema defined by the cluster operator. In this case, I would not put the validation logic in the Helm chart, as Matt suggested. Instead, I’d recommend creating a new resource definition that conforms to the schema you desire, then when the user creates new instances of that resource, it will be validated and accepted (or rejected) by the Kubernetes API. Your Helm chart will only need to refer to the resource by its name, and the chart can safely rely on the schema’s validation logic to ensure that the correct data has been provided in the correct fields. Hope that helps. toggle quoted message Show quoted text From: cncf-helm@... <cncf-helm@...> On Behalf Of Loritsch, Berin via lists.cncf.io Sent: Monday, January 18, 2021 5:41 AM To: Matt Butcher <Matt.Butcher@...> Cc: cncf-helm@... Subject: Re: [EXTERNAL] Re: [cncf-helm] Is there any way to enforce constraints The idea is not to scan, but to validate that the specified secret is the right kind. I.e. the user specifies `example-secret`, and the helm chart fails if the secret that exists is not the right kind... i.e. they accidentally supplied a basic-auth secret or something like that. The ability to fail fast and provide a comprehensible error message is rather important. On Fri, Jan 15, 2021 at 5:57 PM Matt Butcher <Matt.Butcher@...> wrote: 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: Example: I am creating a chart for a single page app server. In it I want the ability to add a reference to the TLS secret. The TLS secret would be provided by the person using the chart. In my chart I want to enforce that the provided Secret is the type: kubernetes.io/tls I want that constraint enforced prior to deploying the chart. -- Berin Loritsch DOMEX Architect 7921 Jones Branch Drive McLean, VA 22102 Email bloritsch@... Office (703) 735-6281 Mobile (571) 215-7708 -- Berin Loritsch DOMEX Architect 7921 Jones Branch Drive McLean, VA 22102 Email bloritsch@... Office (703) 735-6281 Mobile (571) 215-7708 -- Berin Loritsch DOMEX Architect 7921 Jones Branch Drive McLean, VA 22102 Email bloritsch@... Office (703) 735-6281 Mobile (571) 215-7708
More All Messages By This Member
Loritsch, Berin <bloritsch@...> #357 The idea is not to scan, but to validate that the specified secret is the right kind. I.e. the user specifies `example-secret`, and the helm chart fails if the secret that exists is not the right kind... i.e. they accidentally supplied a basic-auth secret or something like that. The ability to fail fast and provide a comprehensible error message is rather important. toggle quoted message Show quoted text On Fri, Jan 15, 2021 at 5:57 PM Matt Butcher <Matt.Butcher@...> wrote: 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: Example: I am creating a chart for a single page app server. In it I want the ability to add a reference to the TLS secret. The TLS secret would be provided by the person using the chart. In my chart I want to enforce that the provided Secret is the type: kubernetes.io/tls I want that constraint enforced prior to deploying the chart. -- Berin Loritsch DOMEX Architect 7921 Jones Branch Drive McLean, VA 22102 Email bloritsch@... Office (703) 735-6281 Mobile (571) 215-7708 -- Berin Loritsch DOMEX Architect 7921 Jones Branch Drive McLean, VA 22102 Email bloritsch@... Office (703) 735-6281 Mobile (571) 215-7708 -- Berin Loritsch DOMEX Architect 7921 Jones Branch Drive McLean, VA 22102 Email bloritsch@... Office (703) 735-6281 Mobile (571) 215-7708
More All Messages By This Member
Matt Butcher <matt.butcher@...> #356 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'. toggle quoted message Show quoted text 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: Example: I am creating a chart for a single page app server. In it I want the ability to add a reference to the TLS secret. The TLS secret would be provided by the person using the chart. In my chart I want to enforce that the provided Secret is the type: kubernetes.io/tls I want that constraint enforced prior to deploying the chart. -- Berin Loritsch DOMEX Architect 7921 Jones Branch Drive McLean, VA 22102 Email bloritsch@... Office (703) 735-6281 Mobile (571) 215-7708 -- Berin Loritsch DOMEX Architect 7921 Jones Branch Drive McLean, VA 22102 Email bloritsch@... Office (703) 735-6281 Mobile (571) 215-7708
More All Messages By This Member

1 - 3 of 3

1

Previous Topic Next Topic

Home Hashtags Subgroups Terms