Organize PSP policies into standardized buckets

[sozercan]

Describe the solution you'd like
There are quite a few PSP policies in the library. It might be confusing to users which ones to deploy and what constraints parameters to set.

sig-auth provides a set of standardized PSP definitions (https://docs.google.com/document/d/1d9c4BaDzRw1B5fAcf7gLOMZSVEvrpSutivjfNOwIqT0/edit#heading=h.ihgl7qlgtyzu) that we can align on, ranging from unrestricted to common best practices to restricted.

We should create guidance and buckets for users to adopt PSP policies easily, and mention that these can be customized by users.

[maxsmythe]

It'd be good to do this in a separate library Repo. I think we've graduated to the point where the library should have its own lifecycle.

[tallclair]

I'll take a first pass at adding these to https://github.com/open-policy-agent/gatekeeper-library, based on the spec in https://kubernetes.io/docs/concepts/security/pod-security-standards/

[jsturtevant]

for anyone landing here, https://github.com/open-policy-agent/gatekeeper/tree/master/library/pod-security-policy is the currently list but is not separated into the buckets from https://kubernetes.io/docs/concepts/security/pod-security-standards/ as of now (privileged, baseline/default, and restricted)

[ritazh]

Thanks @jsturtevant! The plan is to move the policies in https://github.com/open-policy-agent/gatekeeper/tree/master/library/pod-security-policy to https://github.com/open-policy-agent/gatekeeper-library within their own buckets. Hopefully we will get to this soon.

[ritazh]

As discussed on the community call, here are some ideas to consider for implementation to support pod security standards:

• create a folder for each bucket: baseline, restricted, privilege under https://github.com/open-policy-agent/gatekeeper-library/tree/master/library/pod-security-standards (a new folder)
• use kustomize and labels (maybe?) to replicate copies of applicable constraint templates and constraints folders in https://github.com/open-policy-agent/gatekeeper-library/tree/master/library/pod-security-policy to these three folders

[maxsmythe]

As discussed on the community call, here are some ideas to consider for implementation to support pod security standards:

• create a folder for each bucket: baseline, restricted, privilege under https://github.com/open-policy-agent/gatekeeper-library/tree/master/library/pod-security-standards (a new folder)

We may run into other common use cases for GK policies. Do we want to create a folder to group these into?

gatekeeper-library/policy-packs/pod-security-standards/{privileged,baseline,restricted}

• use kustomize and labels (maybe?) to replicate copies of applicable constraint templates and constraints folders in https://github.com/open-policy-agent/gatekeeper-library/tree/master/library/pod-security-policy to these three folders

The constraints will have to be purpose-built to implement the relevant standard, so will probably live (and be developed) directly in these folders. How to integrate the templates is an interesting problem. We probably don't want them living side-by-side with constraints because:

• Users will probably apply multiple tiers of these standards per cluster, we probably don't want to duplicate templates if they do so
• Users will want to customize these "packs" (adopting that name for "bundle of constraints" for the sake of discussion) to apply to specific namespaces (e.g. "prod" is restricted, "dev" is baseline). That means injecting specific matchers into all constraints in a given pack. We wont want to inject matchers into ConstraintTemplates as that's not a valid thing to do.

How would users consume packs?

Ideally we'd want something where a user can declare "namespace foo is privileged" with a minimum amount of complexity.

The low-level pipeline for that would be:

• Gather any missing templates
• Gather the constraints from the appropriate directory
• Apply a namespace matcher to all the constraints

What would the output device be? Is this going straight to kubectl apply? Or is there some source-of-truth repository the output will be added to? This matters for templates -- without a cluster to query, it's hard to know how we'd detect "missing templates"

kpt is targeted at the use case of "apply a bundle of manifests", kind of like how gomod manages golang packages. That makes it seem a likely way of doing this, though I don't know about the part where we're injecting a matcher into all constraints. A kpt function could do that. I'm not sure if there is one ready-made to help with this.

Another option would be to use what @sozercan suggested, writing our own custom binary, though then we'd need to have a pipeline for hosting/delivering that.

None of the above addresses the template problem. I don't think there is a great prepackaged solution here. Kustomize is tempting, but we'd need to include files outside the Kustomize file's base directory. We probably don't want to put anything inside the template tree, as that couples the "packages" directory with our source code, which will hurt maintainability in the future. If we used the custom binary idea, we could scan the library directory for templates that support the underlying kind as part of a build process.

Another option would be to require the user to add templates manually, that would be a one-time cost. That would sidestep the "missing template" problem.

[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]

not stale

[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.