Kubernetes security has always been a source of great interest among system architects. You still have to compromise between administrative control and developer flexibility and velocity to ensure you don’t leave any holes in our cluster.

There are various areas you need to consider to enable security within your cluster. Typically, cyber-criminals look at ways of taking control of the host worker node by hacking into a Kubernetes application. They can then use that opportunity to shut down your cluster or exploit it for illegal activities.

One way of preventing such control is by enforcing proper pod security policies within your Cluster, without impacting development velocity and adding admin overhead.

Kubernetes pod security policies are cluster-level resources that you can create to control security aspects of your containers running on Kubernetes. With pod security policies, you can prevent people from running privileged containers, not allowing host networking and ports, disallowing host path volumes, not allowing containers to run as the root user, and much more.

Here are some of the recommended best practices to ensure cluster security using pod security policies:

• Disable Privileged Containers — This one goes without saying. In most cases, you don’t need privileged containers. Unless you have specific use-case, disable them in all installations by setting the privileged flag to false. Even in that situation, best practice is to use a dedicated service account for that Pod and deploy a specific namespace.
• Enable Read-only file system where possible— There might be some containers that need not write to disk. For example, web applications that only need to write to a database. In those scenarios, there’s no real need to allow read-write to the container filesystem. So, you should enforce a read-only filesystem policy by setting the readOnlyRootFilesystem to true.
• Prevent Privilege escalation — Did I use the word privilege again? Well, you might think of running a container as non-root, but that doesn’t prevent the user from privilege escalation. Disable it if you don’t need it by setting the allowPrivilegeEscalation flag to false.
• Enforce non-root users — This may or may not be practical for your use case, but if possible, don’t allow applications to run as root (especially if you have the control). You can do that by setting the MustRunAsNonRoot flag to true on your Pod Security policy.
• Prevent **hostPath** volumes— Seriously don’t allow hostPaths. They are not only bad for your volume management, and ties your containers to particular nodes, but also will enable a way for cybercriminals to access your host file system. Even if you really have to use them, the best practice is to only allow hostPaths for a specific directory, so people are tied to particular directories only. Something like this:

allowedHostPaths:
  # This allows "/foo", "/foo/", "/foo/bar" etc., but
  # disallows "/fool", "/etc/foo" etc.
  # "/foo/../" is never valid.
  - pathPrefix: "/foo"
    readOnly: true # only allow read-only mounts

There are other controls you may want to enforce — you should look at restricting them as much as possible unless you need them for some reason.

#kubernetes #devops #cybersecurity