In this series of blog posts, we will be looking at using 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 push the gatekeeper Audit logs to EFK, you can read the following article  on sending  logs to EFK.

Scenario:  

There are database servers running in the namespace called ‘backend’.

Aim:

Write a gatekeeper policy that denies anyone, trying to apply any kind of ingress/egress rules to the pod which matches the label ‘access: admin’ in the backend namespace.

template.yaml

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8sdenylabel
spec:
  crd:
    spec:
      names:
        kind: K8sDenyLabel
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8sdenylabel 
        violation [{"msg": msg}] {
          input.review.object.metadata.namespace == "backend"
          input.review.object.podSelector.matchLabels.access == "admin"
          msg := "You are not allowed to apply any network policies to the pod." }

Understanding the REGO policy, 

  • input.review.object.metadata.namespace == “backend” (Checks if the namespace is backend.)
  • Input.review.object.podSelector.matchLabels.access = “admin” (Check if the pod has the label access with a value ‘admin’.)
  • If it does, then the NetworkPolicy will be rejected with a violation message.

constraint.yaml

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sDenyLabel
metadata:
  name: deny-label
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
        labels:
                type: policy

spec:
        podSelector:
                matchLabels:
                        access: admin
        policyTypes:
                - Ingress
        ingress: [] 

NetworkPolicy Allow :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
        name: allow-ingress
        namespace: backend
        labels:
                type: policy

spec:
        podSelector:
                matchLabels:
                        access: user
        policyTypes:
                - Ingress
        ingress: []

Conclusion : 

This was a basic example of using gatekeeper as a Validating admission webhook inside our cluster. In the next blog posts we will be looking at more scenarios to create gatekeeper policies for networking inside the Kubernetes cluster.

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: