## Review using OPA Gatekeeper validate that CNFs continue to carry traffic when appropriate policies are enforced** Tasks: - [x] Research [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) - [ ] Create an outline - [ ] Create a rough draft - [ ] Peer review of draft - [ ] Iterate as needed, peer review (optional) - [ ] Add content to markdown ## Outline / Notes 1. The Open Policy Agent (OPA, pronounced “oh-pa”) is an open source, general-purpose policy engine that unifies policy enforcement across the stack. OPA provides a high-level declarative language that let’s you specify policy as code and simple APIs to offload policy decision-making from your software. You can use OPA to enforce policies in microservices, Kubernetes, CI/CD pipelines, API gateways, and more. 1. What is OPA Gatekeeper? OPA Gatekeeper is a new project that provides first-class integration between OPA and Kubernetes. For background information see this blog post on kubernetes.io and check out this Katakoda tutorial. OPA Gatekeeper adds the following on top of plain OPA: * An extensible, parameterized policy library. * Native Kubernetes CRDs for instantiating the policy library (aka “constraints”). * Native Kubernetes CRDs for extending the policy library (aka “constraint templates”). * Audit functionality. 1. [Enforce policies using Gatekeeper](https://docs.d2iq.com/ksphere/konvoy/latest/tutorials/gatekeeper/) * Pseudo enforcement of policy preventing privileged pods: ``` apiVersion: templates.gatekeeper.sh/v1beta1 kind: ConstraintTemplate metadata: name: k8spspprivilegedcontainer spec: crd: spec: names: kind: K8sPSPPrivilegedContainer targets: - target: admission.k8s.gatekeeper.sh rego: | package k8spspprivileged violation[{"msg": msg, "details": {}}] { c := input_containers[_] c.securityContext.privileged msg := sprintf("Privileged container is not allowed: %v, securityContext: %v", [c.name, c.securityContext]) } input_containers[c] { c := input.review.object.spec.containers[_] } input_containers[c] { c := input.review.object.spec.initContainers[_] } ``` 4. [Testing opa](https://www.openpolicyagent.org/docs/latest/#4-try-opa-run-server) #### Try opa eval Evaluate a trivial expression. ``` ./opa eval '1*2+3' ``` Evaluate a policy on the command line. ``` ./opa eval -i input.json -d example.rego 'data.example.violation[x]' ``` Evaluate a policy on the command line and use the exit code. ``` ./opa eval --fail-defined -i input.json -d example.rego 'data.example.violation[x]' echo $? ``` ## Draft #### Open Policy Agent is an open source, general-purpose policy engine that unifies policy enforcement across the stack. OPA Gatekeeper provides first-class integration between OPA and Kubernetes. We can use OPA for at [least one CNF Conformance test](https://docs.d2iq.com/ksphere/konvoy/latest/tutorials/gatekeeper/), and possibly more. The steps for using OPA and OPA Gatekeeper would be as follows: 1. Deploy Gatekeeper using Helm in the potential CNF's cluster ``` helm install mesosphere-staging/gatekeeper --name gatekeeper ``` 2. Create a privileged pod policy constraint template ``` kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/library/pod-security-policy/privileged-containers/template.yaml ``` 3. Create the privileged pod policy constraint ``` kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/library/pod-security-policy/privileged-containers/constraint.yaml ``` 4. Test that the constraint is enforced ``` kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/library/pod-security-policy/privileged-containers/example.yaml ``` 5. Check the output for errors ``` Error from server ([denied by psp-privileged-container] Privileged container is not allowed: nginx, securityContext: {"privileged": true}): error when creating "https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/library/pod-security-policy/privileged-containers/example.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by psp-privileged-container] Privileged container is not allowed: nginx, securityContext: {"privileged": true} ``` ## Final # TODO ## OPA vs K-rails OPA is more rigorous and all inclusive than K-Rails. OPA and Gatekeeper seem to be more configurable and should be able to handle more edge cases than K-Rails. OPA seems to be becoming the standard within the K8s community. OPA has more forks/stars/contributes OPA requires more configuration out of the box. K-rails has a monitor mode that allows default 'violations' to be monitored and reported on. K-rails has default violations/policies that need very little configuration. The violations are stored in a log and can be scraped. This can be useful for testing a cluster for containers that have privileged mode turned on, among other things. ref: s43