Restrict Namespace and Pod Selectors – OPA Gatekeeper NetworkPolicy Guardrail (Part 6)

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]