Re: [EXTERNAL] Re: [cncf-helm] Is there any way to enforce constraints
Matt Fisher <matt.fisher@...>
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.
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:
-- Berin Loritsch DOMEX Architect 7921 Jones Branch Drive Office (703) 735-6281 Mobile (571) 215-7708 |
|