The rego-policies from redhat-cop

Gatekeeper: ignore core namespaces

Need to check docs on how to tell gatekeeper not to look at core namespaces, i.e.: openshift-*

🦇 move to cop-action once pr is merged

track the github-actions repo for conftestbats so we don't need to use @garethahealy 's dodgy repo/branch

Use the Horizontal Pod Autoscaler for apps with variable usage patterns

Parent: #23
Suggestion: https://learnk8s.io/production-best-practices#application-development
Solved By: TODO

Understand the difference between the different root level methods

We currently have:

deny
warn

But there's also 'violation'. I've googled but can't find a link that explains the different root level "types" and when/why you'd use them.

If anyone finds a link, please share.

Should we provide example manifests/charts/etc. to test against

Interested to see others thoughts on whether we should add examples to test our policies against. Seems like it could be a bit of overhead involved, but feels like a bit of context would also make them a bit more useful.

deprecated policies gatekeeper tests

write tests for gatekeeper

remove konstraint ignore
write gatekeeper tests, and check they work

Write container-resources-*-memory-greater-than gatekeeper tests

Gatekeeper doesn't support k8s memory units yet, needs: https://github.com/open-policy-agent/opa/pull/2403/files

Once it's merged:

remove konstraint ignore
remove skip in gatekeeper tests, and check they work

Look into adding tests for inventory based via conftest --data

conftest supports --data - see if we can provide the data.inventory for these policies so they can be tested locally

Should the package be set per policy?

Currently, all the policies live in the package main as that's what the OPA examples tell you. But if you look at "real world" examples in gatekeeper, they are all in their own packages. I presume this is so multiple policies don't fire for one constraint - not 100% sure.

If we did update the packages to be unique per policy, it would make the testing easier as their would be no cross-firing of rules, i.e.: 1 rule fires against its own test data, vs currently, all rules fire against 1 set of test data.

Avoid Pods being placed into a single node

Parent: #23
Suggestion: https://learnk8s.io/production-best-practices#application-development
Solved By: TODO

Liveness probes values aren't the same as the Readiness

Parent: #23
Suggestion: https://learnk8s.io/production-best-practices#application-development
Solved By: https://github.com/redhat-cop/rego-policies/blob/0.0.1/policy/warn-k8s_ocp-deployment_deploymentconfig-bestpractices.rego#L60-L72

Set Pod disruption budgets

Parent: #23
Suggestion: https://learnk8s.io/production-best-practices#application-development
Solved By: https://github.com/redhat-cop/rego-policies/blob/0.0.1/policy/warn-k8s-deployment-conftestcombine-bestpractices.rego#L27-L47

Update the 'combine' rules to also work against gatekeeper

Gatekeeper supports looking at cached data, should explore that with conftest combine

https://github.com/open-policy-agent/gatekeeper/blob/1c99315f63f1f7529378b66e2244c0e1171aa8ed/README.md#replicating-data
remove konstraint ignore
remove skip in gatekeeper tests, and check they work

Enable network policies

Parent: #23
Suggestion: https://learnk8s.io/production-best-practices#application-development
Solved By: https://github.com/redhat-cop/rego-policies/blob/0.0.1/policy/warn-k8s-namespace-conftestcombine-bestpractices.rego#L3-L21

Namespaces have ResourceQuotas

Parent: #23
Suggestion: https://learnk8s.io/production-best-practices#application-development
Solved By: TODO

Come up with a policy testing strategy

How should a new or updated policy be tested to verify it does the right thing?
This will also be helpful for reviewing PRs and can be used for CI as well.

operators.coreos.com/v1 policies overlap

both do the same check - should be merged.

Check triggers containerName matches DC container

@InfoSec812 hit an issue where the container name in the triggers was not the same as in the containers, causing the trigger to never fire, which led to lots of confusion

Resources have technical labels defined

Parent: #23
Suggestion: https://learnk8s.io/production-best-practices#application-development
Solved By: https://github.com/redhat-cop/rego-policies/blob/0.0.1/policy/warn-k8s_ocp-all-bestpractices.rego#L3-L27

Resources have security labels defined

Parent: #23
Suggestion: https://learnk8s.io/production-best-practices#application-development
Solved By: TODO

🙈 tidy up the policies to get greater reuse across modules 🙈

Each warn has four lines repeated, let's consider turning them into some kinda util or loaded thing. Could do it as a function too.

https://www.openpolicyagent.org/docs/latest/policy-language/#imports

#30

FYI @garethahealy

Policy to deny pod running with high vulnerabilities

Investigate if it's possible to hookup the data from the below operator to deny images that are bad:

https://operatorhub.io/operator/project-quay-container-security-operator

Set an appropriate Quality of Service (QoS) for Pods

Parent: #23
Suggestion: https://learnk8s.io/production-best-practices#application-development
Solved By: TODO

The namespace has a LimitRange

Parent: #23
Suggestion: https://learnk8s.io/production-best-practices#application-development
Solved By: TODO

Add prow to test gatekeeper

We've got a script which will deploy gatekeeper:
https://github.com/redhat-cop/rego-policies/blob/master/_test/deploy-gatekeeper.sh

and a script which will test it:
https://github.com/redhat-cop/rego-policies/blob/master/_test/gatekeeper-integrationtests.sh

but no prow/ci to execute.

@pabrahamsson ; is it possible to get the bot hooked up with prow to execute the above?

Update naming to follow gatekeeper format

OPA Gatekeeper suggests a structure:

https://github.com/open-policy-agent/gatekeeper/tree/master/library

which konstraint also uses:

https://github.com/plexsystems/konstraint#how-template-and-constraint-naming-works

I am thinking it is a good idea to follow that.

cc @tylerauerbeck @pabrahamsson @springdo

Profile / Benchmarking policies

Look into:

https://www.openpolicyagent.org/docs/latest/policy-performance/#profiling

Could this be added as part of the CI?

Resources have business labels defined

Parent: #23
Suggestion: https://learnk8s.io/production-best-practices#application-development
Solved By: TODO

unknown registry fires if image is empty

Policy: https://github.com/redhat-cop/rego-policies/tree/master/policy/ocp/bestpractices/container-image-unknownregistries
Example: https://github.com/redhat-cop/helm-charts/blob/master/charts/dev-ex-dashboard/templates/deploymentconfig.yaml#L29

It should ignore/skip over this.

Containers have Readiness probes

Parent: #23
Suggestion: https://learnk8s.io/production-best-practices#application-development
Solved By: https://github.com/redhat-cop/rego-policies/blob/0.0.1/policy/warn-k8s_ocp-deployment_deploymentconfig-bestpractices.rego#L36-L46

Namespaces have LimitRange

Parent: #23
Suggestion: https://learnk8s.io/production-best-practices#application-development
Solved By: TODO

Enable ci bot

@pabrahamsson ; you good to enable the bot?

📣 base image warning from podman - needs to be more configurable ie no hardcode sha

current tests are looking for a given sha to be in the imaga layer history. This policy is a great start but to be super useful across multiple projects, it would be better if we could pass in the SHA's to check against.

#33

FYI
@garethahealy @noelo