Restrict Ingress Ports – OPA Gatekeeper NetworkPolicy Guardrail (Part 5)

 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.

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.

Aim :

Write a gatekeeper policy that denies anyone, trying to allow ingress access to the web server pod on any other port except 443. 

Scenario:  

A pod running a web-server should only be allowed ingress access on the port 443. 

template.yaml :

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8sblockports
spec:
  crd:
    spec:
      names:
        kind: K8sBlockPorts
      validation:
        # Schema for the `parameters` field
        openAPIV3Schema:
          properties:
            ports:
              type: array
              items: 
                type: integer
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |

        package k8sblockedports
        violation [{"msg": msg}] {
          input.review.object.spec.podSelector.matchLabels.app == "webserver"
          some i
          allowed := input.parameters.ports
          provided := input.review.object.spec.ingress[i].ports[i].port 
          provided != allowed[i]
          msg := "Applying Ingress rule for the provided port is not allowed"
        }

Understanding the REGO policy, 

Here, we define a schema for the parameter field. The parameters will be present inside the constraint.yaml file.

• input.review.object.spec.podSelector.matchLabels.app == “webserver”(Checks if the pod to which the policy is being applied has the label ‘app: webserver.)
• some i ( A variable to iterate through array)
• allowed := input.parameters.ports  ( A variable allowed will save the value of the ports we provided as a parameter inside the constraing.yaml file)
• provided := input.review.object.spec.ingress[i].ports[i].port (This will check for the port that has been provided by the user.)
• provided != allowed[i] (Finally it will check if the provided value is present inside the constraint parameter.)
• If it does not , then the NetworkPolicy will be rejected with a violation message.

constraint.yaml :

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

 Since we defined the parameter as an object array, having the value integer. We have defined the parameter here with the value of 443. This means, any NetworkPolicy trying to allow ingress access to the webserver pod on any other port will be rejected.

Now, deploy the template and the constraint.

NetworkPolicy Deny :

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-5000
spec:
  podSelector:
    matchLabels:
      app: webserver
  ingress:
  - ports:
    - port: 5000
 

NetworkPolicy Allow :

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-443
spec:
  podSelector:
    matchLabels:
      app: webserver
  ingress:
  - ports:
    - port: 443

Conclusion :

This was a very basic example of apply OPA gatekeeper policies, which denied any NetworkPolicy which gave ingress access to the web-server on any other port except 443. We will be looking at more such policies in our future blog posts.

Other Related articles:

• Restrict Namespace and Pod Selectors – OPA Gatekeeper NetworkPolicy Guardrail (Part 6).
• 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]