Helm chart

[kfox1111]

It would be nice if the library could compile into an easy to use helm chart.

[kfox1111]

Maybe related to #47

[sozercan]

Are you looking for helm chart for PSPs? In the past, we discussed aligning them into default, restricted buckets that's detailed under https://kubernetes.io/docs/concepts/security/pod-security-standards/. Is this close to what you are looking for?

[kfox1111]

Yeah.

Maybe a chart that includes all the ConstraintTemplate's and then maybe some default disabled but easily enable-able default restricted buckets like those? That way its easy to load the library of ConstraintTemplates and enable them as you need them with some sane defaults?

[kfox1111]

Maybe useful to https://github.com/kubernetes/community/tree/master/wg-multitenancy as well.

[stale]

This issue/PR has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[sathieu]

Not stale, and related to #47 .

[stale]

This issue/PR has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[sathieu]

not stale.

Having an helm chart would help installation.

[ritazh]

@kfox1111 @sathieu are you looking for specific groups of policies that can be part of a helm chart? Currently for validating policies, we have psp and general. are you looking for 1 helm chart for all psps (maybe filtered by PSS profile level) and 1 for all general policies or just a single helm chart for all?

Another concern: because each policy has its own version, it would be hard to determine how to update the chart's version whenever one of the policies bumps the version.

[sathieu]

@ritazh I think only one chart is needed (but I'm ok with having two).

On the versioning maybe we could use the max as chart version, and bump all policies to this same version?

Alternatively, the chart version can be independant, and bumped according to semantic versioning.

[starlightromero]

I agree with the chart version being independent. Usually the Helm chart version is not tied to the application/library version. In a Chart.yaml file, you will typically find the arguments version and appVersion.

[stale]

This issue/PR has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[sozercan]

another approach we discussed in the past was a CLI (similar to krew or brew), where users can add/remove/sync policies.

[kfox1111]

CLI's are harder to integrate into CI/CD systems.

[sozercan]

@kfox1111 would you elaborate more in your concerns? isn't helm a cli?

[kfox1111]

It isn't when your using a tool such as https://fluxcd.io/ (like: https://fluxcd.io/flux/guides/helmreleases/) or argocd (like: https://argo-cd.readthedocs.io/en/stable/user-guide/helm/)

Kubernetes objects are how you are causing deployment of the charts.

[starlightromero]

Or in my case, using the Helm Terraform provider, the policies can be codified and on VCS push, a Terraform run is triggered in Terraform Cloud.

[starlightromero]

@kfox1111 Would appreciate your feedback on PR #356

[stale]

This issue/PR has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[kfox1111]

/repoen
/notcompleted