In this series of blog posts, we will be looking at deploying OPA gatekeeper as the admission controller for our Kubernetes cluster. We will be focusing specifically at creating gatekeeper policies for networking inside the Kubernetes cluster.
This article assumes that you are already familiar with installing OPA gatekeeper as the admission controller and also writing the gatekeeper policies. If you aren’t please read the following blog posts.
- Installing OPA gatekeeper as an admission controller in your Kubernetes cluster.
- Learn how to write custom gatekeeper policies.
If you want to know how the Audit logs are sent to EFK, you can read the following article on sending the logs to EFK.
Scenario:
The frontend namespace has a replicaset of 5 nginx web servers running.
Aim:
Write a gatekeeper policy that denies anyone, trying to allow any kind of egress access to the web-server other than the pods which match the label ‘app: mysql’.
Template.yaml
apiVersion: templates.gatekeeper.sh/v1beta1 kind: ConstraintTemplate metadata: name: k8sdenyegress spec: crd: spec: names: kind: K8sDenyEgress targets: - target: admission.k8s.gatekeeper.sh rego: | package k8sdenyegress violation [{"msg": msg}] { input.review.object.spec.podSelector.matchLabels.app == "webserver" input.review.object.spec.egress[_].to[_].podSelector.matchLabels.app != "mysql" msg := "Cannot allow egress access."
Understanding the REGO policy,
- input.review.object.spec.podSelector.matchLabels.app == “webserver” (Checks if the selected pod has the label webserver.)
- input.review.object.spec.egress[_].to[_].podSelector.matchLabels.app != “mysql” (Here it checks for the egress rule. It checks if someone tries to allow egress access on the webserver to a pod which does not have the label ‘mysql’)
- If it does not , then the NetworkPolicy will be rejected with a violation message.
constraint.yaml
apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sDenyEgress metadata: name: deny-egress spec: match: kinds: - apiGroups: ["networking.k8s.io"] kinds: ["NetworkPolicy"]
Since we have not defined any parameters in our template file, we won’t be using any here. One thing to remember is that the kind and the apiGroups should match the kind and the apiVersion of the deployment file. In our example that would be ‘NetworkPolicy’ and ‘networking.k8s.io.’
Now, deploy the template and the constraint.
NetworkPolicy Deny :
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-egress namespace: frontend spec: podSelector: matchLabels: app: webserver egress: - to: - podSelector: matchLabels: app: user
NetworkPolicy Allow:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-egress namespace: frontend spec: podSelector: matchLabels: app: webserver egress: - to: - podSelector: matchLabels: app: mysql
Other Related articles:
- Restrict Egress Ports – OPA Gatekeeper NetworkPolicy Guardrail (Part 7)
- A Series of blog posts on using OPA Policies and Gatekeeper for Kubernetes security.
Practice here:
https://www.katacoda.com/cloudsecops/courses/opagatekeeper-policy/podselectors
References:
- https://github.com/open-policy-agent/gatekeeper
- https://github.com/open-policy-agent/gatekeeper-library
Thank you for reading! – Siddarth Tanna and Setu Parimi
Sign up for the blog directly here.
Check out our professional services here.
Feedback is welcome! For professional services, fan mail, hate mail, or whatever else, contact [email protected]
0 Comments