OVERVIEW

We all know running anything as root is bad practice. We also know giving an authorized user more access than necessary is also bad practice. In a Kubernetes world, credentials and permission are handled by RBAC (role-based access control). But what about the pods themselves? Did you know that unless specified, the process inside your container is most likely running as root? To top that off, if someone deploys a privileged pod, the container now has root access to the node it’s scheduled on. Sounds like a security risk, doesn’t it?

Securing your Workloads

At the heart of your Cloud-Native stack is Kubernetes. As development teams gain more access to self-serve, it becomes increasingly challenging to monitor every single pod, or deployment that happens across your organization. Even if you had spare cycles, you would have to:

• Examine every Dockerfile to see which user is running the process,
• Understand what user IDs are available within the container
• Search each deployment chain to see if containers are getting run with escalated privileges
• Verify each deployment isn’t using the root user and has a user and group set
• Manage access to volumes and various paths
• Double check the usage of host ports
• Ensure nobody is giving themselves additional Linux capabilities

#devops #kubernetes #governance #policies