<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=521127644762074&amp;ev=PageView&amp;noscript=1">

Common Kubernetes Misconfiguration Vulnerabilities

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 misconfigured by developers through inexperience or neglect.

Our recent Kubernetes Configuration Benchmark Report tells us that not all organizations have found steady footing with proper configuration of their Kubernetes environment, nor are they even half way there. 

Minor misconfigurations can produce major security holes if they are not found and addressed. For example, a common vulnerability is containers running with more security permissions than required, e.g., root-level access. Under particular configurations, a container may escalate its own privileges. Because configurations are not established by default, security-conscious teams need to explicitly set them.

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.

What are Security Misconfigurations?

Kubernetes security misconfigurations are often when configurations simply have not been set. Often this is because the fastest way to production is to move past the set up stage. Some sample security configurations include hostIPCSet, privilegeEscalationAllowed, insecureCapabilities, or privilegeEscalationAllowed. See a full list here

Tips to Avoid Deployments with Misconfigurations

Avoiding misconfigurations requires a few things. First, DevOps teams need to regularly scan Kubernetes clusters to ensure they have been configured correctly. Often organizations do this manually, with a spreadsheet, that is handed down to developers to fix. Unfortunately, those changes are not always made so the cycle keeps repeating. The number one tip for avoiding misconfigurations is to automatically and continuously scan clusters from dev through to production. Doing so helps to avoid these misconfigurations from entering any production environment. 

Better yet, using an Admission Controller to prevent misconfigurations can help to enable developers to configure Kubernetes better. The Admission Controller can be part of the CI/CD process helping to scan containers before checked into production for misconfigurations. Any issues will be alerted to the developer before it can go into production. This helps enable developers to fix their own problems and frees up DevOps to stop acting like a Kubernetes helpdesk. 

Common Kubernetes Security Misconfigurations

So how do you quickly and proactively identify Kubernetes security misconfigurations to prevent security risks? In our experience there are eight common Kubernetes security misconfigurations that lead to vulnerable deployments.

Not identifying and addressing these security setting 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, our team built Polaris, an open source tool, that checks configurations found in the securityContext attribute for both Kubernetes pods and containers. Where Polaris ends is where Fairwinds Insights picks up.

Fairwinds Insights is 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. 

Fairwinds Insights operationalizes Polaris checks by providing not only the findings, but also keeping a historical record of the results across all your clusters and offering remediation guidance. Fairwinds Insights 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 get the paper on how to manage Kubernetes configurations to improve security, efficiency and reliability.

 

Download Now