Restrict Egress Ports – OPA Gatekeeper NetworkPolicy Guardrail (Part 7)

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 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 replica set of 5 nginx web servers running.

Aim:

Write a gatekeeper policy which denies anyone, trying to allow any kind of egress access to the nginx webservers to any other port except 3306. 

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[_].ports[_].port != 3306
          msg := "Cannot allow egress access."
        }
          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[_].ports[_].ports != 3306  (Checks if the egress rules being applied is only to the port 3306)
• 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:
  - ports: 
     - port: 6739
       protocol: TCP

NetworkPolicy Allow:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress
  namespace: frontend
spec:
  podSelector: 
    matchLabels: 
      app: webserver
  egress:
  - ports: 
     - port: 3306
       protocol: TCP

Other Related articles:

• Restrict Ingress/Egress CIDR Ranges – OPA Gatekeeper NetworkPolicy Guardrail (Part 8)
• A Series of blog posts on using OPA Policies and Gatekeeper for Kubernetes security.

Practice here:

https://www.katacoda.com/cloudsecops/courses/opagatekeeper-policy/denyports

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]