In this series of blog posts, we will be looking at deploying the OPA gatekeeper as the admission controller for our Kubernetes cluster. We will be focusing specifically on 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. 

Aim:

Write a gatekeeper policy which denies anyone, trying to allow ingress access to the ‘mysql’ pod from any other pods except the ones which match the label ‘webserver’. 

Scenario:  

A pod running Mysql is present. Only the webserver can be allowed to have ingress access to it.

template.yaml

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8sdenyingress
spec:
  crd:
    spec:
      names:
        kind: K8sDenyIngress
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8sdenyingress 
        violation [{"msg": msg}] {
          input.review.object.spec.podSelector.matchLabels.app == "mysql"
      input.review.object.spec.ingress[_].from[_].podSelector.matchLabels.app!="webserver"
          msg := "Cannot allow ingress access for the selected pod."
        }

Understanding the REGO policy, 

  • input.review.object.spec.podSelector.matchLabels.app == “mysql” (Checks if the pod to which the policy is being applied is mysql.)
  • Input.review.object.spec.ingress[_].from[_].podSelector.matchLabels.app != “webserver” (Check if the ingress access is from a pod which has the label ‘app: webserver’.)
  • If it does not , then the NetworkPolicy will be rejected with a violation message.

(Note:- Here the ‘_’ iterates through the array. It is the same as before when we took a variable i (some i) and used it inside the bracket (ingress[i]).)

constraint.yaml

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sDenyIngress
metadata:
  name: deny-ingress
spec:
  match:
    kinds:
      - apiGroups: ["networking.k8s.io"]
        kinds: ["NetworkPolicy"]

We have not defined any parameters inside our template.yaml so we won’t be providing any in the constraint.yaml file. Always remember that the apiGroups and kinds should match the apiVersion and the Kind of your deployment.

Now, deploy the template and the constraint.

NetworkPolicy Deny :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress
  namespace: backend
spec:
  podSelector:
    matchLabels:
            app: mysql
  ingress:
    - from:
            - podSelector:           
                matchLabels:
                  app: kv
Network policy denied.

NetworkPolicy Allow :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress
  namespace: backend
spec:
  podSelector:
    matchLabels:
            app: mysql
  ingress:
    - from:
            - podSelector:           
                matchLabels:
                  app: webserver
Network policy allowed.

Conclusion : 

This was a very basic example of apply OPA gatekeeper policies, which denied anyone trying to give ingress access to the mysql pod from any other pods except the webserver. We will be looking at more such examples in the next blog posts.

Other Related articles:

Practice here:

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

References:

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

Leave a Reply

%d bloggers like this: