Library structure

[tsandall]

Per discussion in open-policy-agent/gatekeeper#205 and the most recent weekly meeting, I'm opening an issue to decide how the library should be structured and track work for it.

Scope, goals, requirements

One of the main goals of Gatekeeper is to provide a reusable library that includes common policies for Kubernetes. We expect the library to grow over time and be community-owned. We've identified a few relevant personas:

• Admins who want to install the Gatekeeper library (or a subset of it) on their cluster and begin using it. It should be easy for Admins to install the template library on the cluster and get started.

• Developers who want to contribute to the Gatekeeper library by implementing new policies, improving or fixing existing policies, etc. It should be easy for developers to author, test, and debug their policies and contribute them to the upstream library.

• Tinkerers who want to try out Gatekeeper for the first time and kick the tires. It should be easy for these people to deploy Gateekeeper, instantiate a few templates, exercise them, and cleanup.

We have also identified a few goals & requirements related to these personas.

1. Policies should be organized into categories to facilitate browsing. For example, instead of having a single directory containing hundreds of policies, the library could be broken down into sub-directories for different categories like containers, images, networking, etc.

2. Installable templates should be located under a separate root directory. This allows admins to easily install templates into their cluster (e.g., kubectl apply -f <url>)

3. Policies contributed to the library should be accompanied with tests and at least one example constraint and resource for kicking the tires.

4. Since the installable templates will be located separately, there should be some basic automation that generates the installable templates from the source templates.

Proposal

The existing PSP library in this repo meets (1) and (3) above but lacks (2) and (4). One option would be to:

• Replace the spec.targets[].rego field with placeholder text and put a build step in place to template the templates (ha!).
• Take the output of the build step (which would be a set of installable templates) and dump it into a separate root directory in this repository (e.g., templates/)

Questions

• @maxsmythe do you think we should have unique names on the source files? One nice thing about the current naming convention is that it creates a simple abstraction for people contributing to the library.

[maxsmythe]

Unique names for the constraint template make it easier to copy templates around without losing context. It also allows storing more than one template per directory. I would argue that since the compiled templates are stored in a separate place from the source code (kubectl -f requirement), the developer argument may be moot.

One extra requirement I'd like to add:

Some way of bundling documentation with the constraints: "these are the parameters and here's what they do"

[lwindolf]

Just to add some user feedback: As a user with admin background I'd actually prefer a build script which I tell which policies from this library I want to use and which then creates a helm chart containing a copy of those policies for me. Then I can simply add this chart as a local chart to my helm chart based k8s cluster setup tooling.

[stale[bot]]

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.