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:
- Returns true if the “hostNetwork” is set to true.
- 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:
- OPA Gatekeeper Audit and Logging using EFK
- A Series of Blog Posts on using OPA Policies & Gatekeeper for Kubernetes Security
Practice here:
https://www.katacoda.com/cloudsecops/courses/opagatekeeper-policy/hostnetwork
References:
- https://github.com/open-policy-agent/gatekeeper
- https://github.com/open-policy-agent/gatekeeper-library
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