Containers are standard software units that package code with all its dependencies so you can run applications quickly and reliably in one computing environment or another. The goal is for them to be lightweight and isolated, running on top of a host operating system. While it shares the kernel with other containers, each container includes its own filesystem and process space, so you can run multiple applications on just one host, without allowing them to interfere with one another. A Pod is the smallest unit you can deploy and manage in Kubernetes, and a Pod can contain more than one container, which allows you to bring together multiple containers that you need to manage as a single entity. Usually this is because the containers are tightly coupled, and the Pod operates the way a single server would. Every container is able to access the other containers in the pod as different ports on localhost.
The containers in a Pod use the same network namespace and standard inter-process communications (IPC) namespace; they may also use shared volumes. By creating a “logical host” that runs the containers in a Pod, you can ensure data locality and make it possible for the containers to communicate efficiently. The Kubernetes Pods allow you to manage tightly coupled application containers as a single unit. The containers in a pod share the IPC namespace, so they can communicate with one another using standard inter-process communications, including SystemV semaphores and POSIX shared memory. This mechanism in the operating system allows processes to communicate with one other and synchronize all their actions. The ability to communicate between these processes can be seen as a method of cooperation between them. Processes can communicate with one other through both shared memory and message passing.
An IPC namespace allows you to isolate System V IPC objects, including shared memory segments, message quest, and semaphores. That means that processes in different IPC namespaces can’t see or use each other’s IPC objects; in this way, isolation can help prevent unauthorized access to IPC resources. These virtual environments can be used for security, performance, and isolation purposes. IPC namespaces are also a fairly simple way for developers to isolate processes from each other.
Host IPC is the IPC namespace that the host and containers share. Often, you use Host IPC for inter-container communication because it enables the containers to share data and communicate with one another without going through the host’s network stack. This sounds useful. Unfortunately, it can introduce security risks, because it allows containers to access the host resources, so if a container is compromised, it could access the host’s sensitive data or potentially take control of the host itself. Because of this risk, you should use Host IPC cautiously, and only enable it when absolutely necessary. Host IPC can also add some complexity to your Kubernetes management, in part because you have to make sure each container is in the correct IPC namespace. It may also add some costs, because it requires the host to have additional resources, including shared memory segments.
hostIPC to false The Host IPC namespace controls whether a pod's containers can be shared. Preventing the sharing of the Host IPC namespace ensures proper isolation between Docker containers and the underlying host. There are a few ways you can ensure that Host IPC is not configured to allow sharing of resources. You can:
RBAC Pod Security Policy — setting hostIPC to false for a Role or Cluster Role via PodSecurityPolicy
Workloads — setting hostIPC to false on individual workloads
Kind: PodSecurityPolicy – add a spec to the policyhostIPC: false
Kind: ClusterRole — a Role or ClusterRole must grant access to use the desired policies
Kind: ClusterRoleBinding — setting hostIPC via a policy and binding it to a Role or ClusterRole
Kind: Pod — Add to the spechostIPC: false
Example:
—
apiVersion: v1
kind: Pod
metadata:
name: example-pod
labels:
role: myrole
spec:
containers:
- name: web
image: nginx
hostIPC: false
ports:
- name: web
containerPort: 80
protocol: TCP
Cluster-level restrictions ensure that containers remain isolated using role-based access controls (RBAC). We have an open source project, RBAC Manager, which supports declarative configuration for RBAC with new custom resources. Controlling access based on roles and using policies can make it much easier to manage your configurations and keep your Kubernetes environment more secure. This recommendation addresses a Fairwinds Insights Action Item. You can implement it yourself. Once you apply the recommendation, the Action Item will go away in your list in Insights.
Setting the hostIPC to false helps you to harden your Kubernetes deployments. You can configure Host IPC on individual workloads, or you can configure a pod security policy and then bind it to a role to accomplish this on a larger scale within your cluster.
Watch a short video where I walk you through this information about Host IPC.
Want to see if you have Host IPC configured? Try out the free tier of Fairwinds Insights. It’s available for free for environments up to 20 nodes, two clusters, and one repo. Explore Fairwinds Insights for Free
