Maintaining and monitoring the security posture of organizations has been the goal of SecOps and SoC teams for as long as they have existed. Over the years, automation frameworks that utilized custom playbooks to check against the known inventory of systems in production became popular. Later, when private, public, and hybrid clouds became more mainstream, we saw the rise of solutions like Cloud Security Posture Management (CSPM), which could compare all of the services that were enabled on a given cloud platform against known best practices, along with any custom rules the organization created.

Detecting misconfigurations via CSPM works well at the cloud level, but some services need extra attention due to the sheer complexity that often exists within each instance. Kubernetes is a good case in point. The complexity is further compounded when you run it on multiple clouds using multiple distributions (like AKS and GKE), then extend it on-premises, where you use yet another set of distributions (such as OpenShift and RKE2). This doesn’t even include DIY clusters.

What is Kubernetes Security Posture Management (KSPM)?

Kubernetes Security Posture Management (KSPM) solutions are built with an inherent understanding of the complexity of the Kubernetes core platform and the ways in which it is extended within the ecosystem. So, regardless of which distribution, hosted offering, or local deployment of Kubernetes is in use, a KSPM solution will be able to maintain a consistent baseline to ensure the best possible Kubernetes security profile for the organization’s needs. This could mean enforcing anything from in-house rules like naming conventions to industry-standard best practices documented in the CIS Kubernetes Benchmarks.

What does KSPM do?

The short answer is that KSPM is like having a second opinion from another professional (like having another lawyer review a contract or getting a second estimate for a renovation project). A second set of eyes will usually notice something that the first set missed or, in this case, something that hadn’t been updated to the latest specification.

Visibility into the Entire Cluster 

For KSPM to be effective, it needs to run with the highest level of visibility into a cluster to ensure that it has access to review and remediate all aspects of the cluster’s configuration. 

This includes (but isn’t limited to):

Risk Assessments and Compliance Validation

Arguably the most important aspect of KSPM is that it constantly scans and validates against best practices and any standards that an organization’s security team or developers have chosen to implement. If anything does not meet the required standards, it can be flagged for the logging and alerting system to pick up. In many cases, it can even be automatically remediated.

For example, this might happen when: 

  • pods attempt to run with escalated privileges,
  • a new role is added unexpectedly,
  • a non-standard port is opened,
  • an ingress controller is created when TLS is not enabled.

Similarly, KSPM also watches workload deployments and any other configuration items so that it can flag anything that is using a deprecated API or other specification. For example, KSPM would notice if an API moved from beta to GA.

To understand how useful KSPM can be, just think about the phasing out of Kubernetes pod security policies. These policies, which have been a reliable way to ensure some level of pod compliance, have been marked as deprecated in favor of admission controllers in Kubernetes 1.21, and they will be phased out in version 1.25. If you’re using the current version, which is version 1.24, you could use KSPM to catch any pod security policies that exist across all of the clusters in your environment. Otherwise, you might have pod security policies in place in an application that is rarely updated, or your developers might not be aware of the situation, and your deployment could unexpectedly fail in six months after a routine upgrade. That would be the last thing you’d want to happen.

Automated Remediation 

After identifying new configurations or configurations that have drifted away from compliance, there are two main approaches to remediation. The first is to apply corrective action, such as removing a service that asked for a non-standard port. The second option is more proactive; you could apply admission controllers and similar policies to block changes that do not meet the requirements of the policies that you have in place. (You could even leverage other technologies like Open Policy Agent.) For example, if you come across an image with known CVEs, you could simply choose not to run a container based on that image.   

Managing Kubernetes security risks with KSPM 

KSPM is not just another buzzword. Like GitOps, SRE, and many other new concepts, any organization that uses Kubernetes as their platform for service delivery can benefit from introducing KSPM into their technology landscape. Not only can it report when something is out of compliance, but it also has the ability to perform remediation on its own to ensure compliance. This saves time and money that can be invested in product enhancements and other activities to improve the customer experience instead.

Sign up for Orca Security’s free risk assessment to gain much-needed visibility and improve your Kubernetes and cloud security in your organization.