Guest post originally published on the Fairwinds blog by Joe Pelletier, VP of strategy at Fairwinds
Securing workloads in Kubernetes is an important part of overall cluster security. The overall goal should be to ensure that containers are running with as minimal privileges as possible. This includes avoiding privilege escalation, not running containers as a root user, and using read only file systems wherever possible.
Security vulnerabilities can slip into production because of oversight or inexperience. Speed to delivery vs. critical security safeguards are often at odds as teams attempt to balance the velocity of engineering with the reactionary pace of security. This balancing act can result in messy Kubernetes configurations and unnecessary risk. Problems can arise if workloads are mis-configured by developers through inexperience or neglect.
Unfortunately, individual application developers often neglect security configuration for each workload. For example, it’s often easier to over-permission a deployment with root access to just get something working. Forcing individual contributors to design their own security configuration all but ensures inconsistency and mistakes.
Common Kubernetes Security Configurations That Lead to Vulnerable Deployments
So how do you quickly and proactively identify Kubernetes security misconfigurations to prevent breaches? In our experience there are common Kubernetes security misconfigurations that lead to vulnerable deployments.
Not identifying and addressing these configurations can have negative business consequences. For example, if a container runs as root but doesn’t necessarily need this level of access, then a malicious container could have the privileges to steal data or cause other damage to the system.
| Configuration | Severity | Description |
| security.hostIPCSet | danger | Fails when hostIPC attribute is configured. |
| security.hostPIDSet | danger | Fails when hostPID attribute is configured. |
| security.notReadOnlyRootFilesystem | warning | Fails when securityContext.readOnlyRootFilesystem is not true. |
| security.privilegeEscalationAllowed | danger | Fails when securityContext.allowPrivilegeEscalation is true. |
| security.runAsRootAllowed | danger | Fails when securityContext.runAsNonRoot is not true. |
| security.runAsPrivileged | danger | Fails when securityContext.privileged is true. |
| security.insecureCapabilities | warning | Fails when securityContext.capabilities includes one of the capabilities listed here |
| security.dangerousCapabilities | danger | Fails when securityContext.capabilities includes one of the capabilities listed here |
To address these common kubernetes security threats, teams need a way to quickly check configurations found in the securityContext attribute for both Kubernetes pods and containers. Using a configuration validation tool that provides visibility into an organization’s Kubernetes security posture by auditing workloads and validating configurations for weaknesses, container vulnerabilities, and misconfigured deployments can help.
There are open source tools and configuration validation software available that can present configuration findings, keep a historical record of the results across all clusters and offer remediation guidance. Look for one that allows you to track and prioritize security, efficiency and reliability issues, collaborate across teams, and apply best practices as applications move from development to production.
Learn more about Fairwinds Insights or the open source tool Polaris free to download from GitHub.