Pod Security Policies

Pod Security Policies are a good way to prevent pods with elevated privileges from running in your Kubernetes cluster. A part of our best practices, we created a set of our own policies to understand when containers with too much access are provisioned. Since our policies are enabled cluster wide, and across all clusters within your account, you can gain a holistic view of where potential vulnerabilities exist. These policies are enabled by default due to the importance of securing your containers and cluster. 

Container Running as Root

Root access isn’t something you give freely. Unless specifically defined, containers run their process as root,  allowing anyone that gains access to your container root access. The same type of protections you would have surrounding your Node’s root account should be considered for your containers. 

Our Container running as root policy checks your workloads to see if any of your containers are running as root. Aside from pods in the kube-system namespace, we examine the following entities to see if any are in violation. 

  • Deployments
  • DaemonSets
  • StatefulSets
  • Jobs
  • CronJobs
  • Pods

Acceptable values include running as a user with an id > 0, running as a group with an id > 0, or setting “runAsNonRoot” in your securityContext. For containers headed for production, we recommend identifying which UIDs are available inside your container and then setting them in your workloads. 

We believe this is a best practice since running as root presets a huge security vulnerability when running your containers.

Container Running in Privilege Mode

Kubernetes allows for you to run your container in privileged mode. This means that if your container has this set to true in your securityContext, your container will essentially have root access to the node it's scheduled on. You may run across this type of access when working with system level containers that need access, for example,  a container that needs to modify underlying network rules. When a developer is building a microservice for a non-system altering application, this type of access is typically unneeded. 

Our Container running in privilege mode policy checks your workloads to see if any of your containers have privilege set to true within your securityContext. Aside from pods in the kube-system namespace, we examine the following: 

  • Deployments
  • DaemonSets
  • StatefulSets
  • Jobs
  • CronJobs
  • Pods

to see if any are in violation. 

We have decided to create this best practice policy due to the amount of access given to the underlying host when this setting is set to true. If this setting is absolutely necessary, please proceed with caution. 

Container Running in PrivilegeEscalation Enabled

Containers with PrivilegeEscalation are allowed to have more privileges than their parent process. In other words, an action similar to sudo. Specifically, setting this to false prevents the execve system call from allowing privilege escalation, most commonly setuid and setgid. 

Our Container running in PrivilegeEscalation Enabled policy checks your workloads to see if any of your containers have allowPrivilegeEsclation set to true within your securityContext. Aside from pods in the kube-system namespace, we examine the following:

  • Deployments
  • DaemonSets
  • StatefulSets
  • Jobs
  • CronJobs
  • Pods

We have decided to create this best practice policy because allowing a child process to have more access than its parent opens up risk. This setting is also required to effectively enforce MustRunAsNonRoot, which is detected by our other policy, Container running with root. 

Container Running with Uncontrolled Linux Capabilities

Kubenetes allows a pod certain capabilities without giving full root access. In certain instances, such as with the CoreDNS pod for example, a pod may need certain capabilities such as “NET_BIND_SERVICE”. Unless you are provisioning pods that deal with system level changes, certain capabilities shouldn’t be provided. 

Our Container running with uncontrolled Linux capabilities policy checks your workloads to see if any of your containers have "SYS_ADMIN","NET_ADMIN", or "ALL" set for capabilities within your  securityContext. Aside from pods in the kube-system namespace, we examine the following:

  • Deployments
  • DaemonSets
  • StatefulSets
  • Jobs
  • CronJobs
  • Pods

We have decided to create this best practice policy to check for these 3 values "SYS_ADMIN","NET_ADMIN", and "ALL" because of the amount of access it gives to the underlying OS of the node. You may also find that the default capabilities granted may be too permissive as well. Consider explicitly dropping capabilities that are unnecessary.

Connect Magalix to your clusters to check if their K8s objects violate or comply with this advisor's policies. Start your 30-days free trial by clicking here