Running secure workloads in Kubernetes can be challenging. Kubernetes enables engineers to configure the security features of containers using the securityContext field. Securing pods with this Kubernetes security context ensures that each resource has the permissions it needs, while also avoiding the pitfall of over permissioning. Security context defines permissions on a granular level, always adhering to the principle of least privilege. That said, many of the security rules you can define using security contexts can also be configured via pod security policies, which are not the same tool.
Why have both? Because security contexts are a replacement for pod security policies, which can be used to configure permissions for all pods running in Kubernetes cluster, provide less granular control than security context, which can be applied to singular pods.
A pod security policy in Kubernetes is a cluster-level resource that controls security-sensitive aspects of the pod specificiation. These policies are what define a set of conditions needed to run a pod that the system will accept, as well as defaults for the related fields. Although PodSecurityPolicies are enforced by enabling the admission controller, pods will not be created in the cluster if the proper policies are not authorized in the first place.
One setting that controls whether a container is able to write into its filesystem is readOnlyRootFilesystem,a feature you definitely want enabled, if possible, to provide additional defense-in-depth for your containerized workloads. If an attacker or bad actor manages to breach a cluster, readOnlyRootFilesystem will prevent them from tampering with the application or writing executables to a disk.
Kubernetes security best practices offer guidance on how to configure readOnlyRootFilesystem for a pod or container. Yes, the feature is essential to the security of Kubernetes, but what happens if users have not deployed a pod with the securityContext set to readOnlyRootFilesystem? In an ideal scenario, your team is able to identify this issue and apply the proper policy. Worst case, your pods are breached and compromised, which means identifying pods not running as read only need to be identified right away.
Here’s the problem with manually checking each pod for its securityContext—it’s prone to human error, not to mention it is wildly time consuming. Automating the process using policy enforcement tooling can reduce Kubernetes security risk considerably.
Fairwinds Insights, our SaaS governance platform for Kubernetes offers solutions. As a policy-driven configuration validation platform, Insights helps teams responsible for Kubernetes to identify when an incorrect security context has been set. Customers of Fairwinds Insights can implement these guardrails and feedback loops at every stage of the process—at the time of pull request, deployment, and for workloads already deployed in the cluster.
You can use Fairwinds Insights for free, forever. Get it here.
Based on the requirements of your organization, Fairwinds Insights automatically scans clusters to check for missing security context. This means your team can save time locating the privileged containers—time that can then be used to remediate the problem.
Once the Insights agent is installed, you will receive results in less than 10 minutes. When securityContext.readOnlyRootFilesystem is not true, Insights will provide a warning. Fairwinds Insights also ensure policies are enforced throughout deployment, so the security context is set for every pod. This move reduces security incidents by scanning configuration from CI/CD through to production. Insights also works to ensure Kubernetes security best practices are followed by all teams, across the enterprise.
