Introduction

In this article, we’ll look into the OPA policy to deny host network. The reason is because setting the “hostNetwork: true” allows pods to access the network namespace of the host machine, on which the pod is running. For those who are wondering why a container accessing the host’s network namespace is a bad idea, I’ll start by telling what a container is.

What is a container?

A container, in reality, is nothing but the use of “cgroups” and “namespaces” to give us a picture of an isolated machine running within our host machine. cgroups are responsible to restrict the use of the host machine’s resources like CPU, Memory etc.  Namespaces restrict the visibility of the process running on the host machine. These are used jointly to form something, called a container, that is isolated from the host machine and has its own resources, file system, network interface and so on.

Why do we need this policy?

From a security standpoint, when a container with access to the host’s network namespace is compromised, the attackers will have access to the host’s network interfaces through the compromised container. This will give the attacker the ability to sniff the data that’s going on in the host machine’s network. So it’s a safe practice to prohibit host network unless it’s required for the functionality of an application.

Deny Host Network

template.yaml

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8sblockhostnetwork
  annotations:
    description: Blocks HostNetwork.
spec:
  crd:
    spec:
      names:
        kind: K8sBlockHostNetwork
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8sblockhostnetwork

        violation[{"msg": msg, "details": {}}]{
        input.review.object.spec.hostNetwork 
        msg := sprintf("HostNetwork is prohibited",[])
        }

We can notice right away that the “validation” part is missing in our template. This is the example we talked about in our first blog post. We can always skip the validation section if we are not going to use any parameters.

Rego Policy explained:

  1. Returns true if the “hostNetwork” is set to true.
  2. Denies the pod creation and displays the message if the above is true.

constraint.yaml

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sBlockHostNetwork
metadata:
  name: block-host-network
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]

The parameters section is not there as we won’t be using any parameters.

deployment-non-violation.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-host-networking-ports-allowed
  labels:
    app: nginx-host-networking-ports
spec:
  hostNetwork: false
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 9000
      hostPort: 80

This pod will get created as the “hostNetwork” is set to false.

deployment-violation.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-host-networking-ports-disallowed
  labels:
    app: nginx-host-networking-ports
spec:
  hostNetwork: true
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 9001
      hostPort: 9001

This will get denied as it violates our policy by setting “hostNetwork” to true.

Conclusion

I’ll wrap up this post for now. The takeaways from this post are:

  • It’s always advised to not let pods use “hostNetwork” unless it’s required as it just violates the whole point of isolating the container from the host.
  • The “validation” section of the template can be skipped if we are not using any parameters.

Other related articles:

Practice here:

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

References:

 

Thank you for reading! – Vishal Pranav 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: