Intro
Cloud security is a large initiative for many security teams, and the sheer volume of potential ways to err, given the shared responsibility model, is enough to understand why. But what if you have a Kubernetes environment? Is cloud security enough? After all, many cloud providers offer managed Kubernetes services. In this blog we will explain the fundamental requirements inherent in securing cloud environments versus Kubernetes. In the end, if you use cloud security in lieu of a Kubernetes-first approach to cloud native security, you are losing both time and accuracy.
What is "the cloud"?
The CNCF defines cloud computing this way:
Cloud computing offers compute resources like CPU, network, and disk capabilities on-demand over the internet, allowing users to access and use computing power in a remote physical location.
Of note in this definition: cloud computing separates out different components of infrastructure (CPU vs network vs storage, for example) and offers each “on-demand.” This enables consumers of cloud computing to design exactly the infrastructure they need both in terms of configuration and scale. Also important to note: “consumers of cloud computing” can be internal to the cloud provider (private cloud) or external (public cloud). What matters is not the business relationship but the modular, on-demand architecture.
What is Kubernetes, relative to the cloud?
Cloud computing provides an infrastructure layer to its consumers. There can be other layers above that infrastructure designed to provide a common set of services for applications; this kind of service-oriented, layered relationship is not unique to the cloud. A computer’s operating system sits on top of the infrastructure (the hardware) and provides a common set of services (ie, system libraries and APIs) which can be used to deliver applications to the user. The internet as we know, sitting on top of a worldwide fabric of optical connections, provides a common set of protocols that can be used by applications to deliver content and services anywhere in the world.
Where it pertains to the cloud (because sometimes Kubernetes is not run in the cloud) Kubernetes can be thought of as a layer above the cloud infrastructure that deploys services and manages the allocation of resources for the end-user applications you are building. By definition, it can reach into your entire application development process to deploy other parts of a platform, such as DevSecOps tooling, database services, or identity and access management services. It is the director of the processes that are invoked, the cloud services that are used and the apps you deploy. For example, Kubernetes can mount a public cloud provider storage system. The cloud controller manager in Kubernetes supports this, allowing the public cloud providers to integrate with Kubernetes.
Cloud versus Kubernetes architecture
At the cloud infrastructure layer, for example, you have (usually) linux hosts. These hosts are workload agnostic: they can be used for all kinds of computing purposes. As a result, they need to be hardened and monitored in a workload agnostic way (even if you plan to use them as Kubernetes nodes— security threats don’t respect your intended use). They are also virtually isolated, meaning your hardening and monitoring must be replicated individually across every virtual resource. From the point of view of cloud security, therefore you are relatively reactive to whatever is being dictated by the orchestrator.
On the other hand, at the Kubernetes layer, that isolation is abstracted out into a unified entity (aka “the cluster”) and workloads must conform to particular constraints (ie, being containerized). A Kubernetes cluster has plenty of complexities and moving parts, but it shares a unified control plane, a common API, and shared state across all its constituent pieces. These are the capabilities that direct processes, cloud services and other application elements. From the point of view of Kubernetes security, therefore, you are right at the inflection of the processes and application pieces that are being invoked or deployed.
A significant part of the cluster’s state is the applications deployed to it. Those applications are subject to their own layers of abstraction. Kubernetes distinguishes between low level objects (ie, pods and containers), which are then composed together into high level objects (services and deployments, for example) to present the application to end users as a single object.
These abstractions are explicitly designed to accommodate the DevSecOps lifecycle: workloads need to be updated frequently with new releases, deployed for high availability, and capable of handling failures. Higher level abstractions mask all of this to present a consistent, stable interface to other services on the cluster and to application end users.
Cloud security versus Kubernetes security; the container requirement
Let’s start at the beginning; the first key point to mention is that cloud security is not necessarily even relevant for a Kubernetes environment. You don’t have to have containers in order to require appropriate and hardened cloud service account configurations.
The application development lifecycle
The second major thing to notice about the two is where in the application lifecycle they take place. In the diagram of the application development lifecycle below, you will see that Cloud Security Posture Management (CSPM) lies squarely in the land of ‘Run’ whereas things dealing directly with Kubernetes, like Admission Controllers and Kubernetes Security Posture Management (KSPM) deal with the stage of ‘Deploy.’ This is a relatively obvious point, but still important, because this will impact how you understand priorities and how natural or easy it is to place context to help this process.
Just by itself, the placement along the application development lifecycle means that the cloud perspective will always give you an ‘after the fact’ view. The exploit has already been used, the attacker is already at work, the workload has already been running in the cloud.
In contrast, Kubernetes is at the inflection point between the build and runtime, so there is still a lot of opportunity for preventative controls; for example, admission controllers, which can stop a workload from running in the case of a Kubernetes misconfiguration.
What is missing from cloud security for Kubernetes
Under the hood, the main abstractions of Kubernetes, a unified entity (aka “the cluster”) and workloads that must conform to particular constraints (ie, being containerized), are mapping down to lower level objects, and ultimately the containers running as “real” processes on an individual host. You can see this by creating a graph of relationships spanning the cluster, as we have done with Automated Risk Triage. At the cloud layer you only see the low level running process on individual hosts. Conversely, at the higher level application layer (aka, container level) you only see the high level abstractions presented to other services and external entities. Only at the Kubernetes level can you see the full graph and make security decisions with a complete understanding of the relationships spanning the cluster. This is what it means to have a Kubernetes-first view of cloud native security.
Cloud infrastructure means modular, scalable, and on-demand infrastructure resources. Those resources are workload agnostic and virtually isolated, requiring security that must also be workload agnostic and deployed to each distinct resource. Cloud Security Posture Management will therefore focus on things like host hardening and EDR. For Cloud Security Posture Management, it’s not a huge issue to use polling intervals because configurations won’t be changing every five minutes, like the lifecycle of a container workload.
In contrast, platforms like Kubernetes (or ones built on/containing Kubernetes) move up a layer of abstraction and pull together cloud resources into a composite entity with a unified control plane, common API, and shared state. As a consequence, real-time Kubernetes Security Posture Management must focus on the security of that API and control plane, becoming part of a larger graph of relationships (in real time) of all the cluster's components and deployed workloads.
Based on what we’ve seen above, here are the basics of what you will be missing trying to secure your Kubernetes environment by using a cloud-centric approach:
- The between the higher-level application abstraction and the workload-agnostic, isolated processes on hosts
- Connection of application workloads to the orchestrator
- Connectivity between all the other Kubernetes components, and their associated risks
- A real-time view of how these relationships - and hence your overall risk - changes in accordance with the Kubernetes lifecycle
For an understanding of the specific difference between Cloud IAM and Kubernetes RBAC, which is another source of confusion around how to secure the broad set of Kubernetes components, read this blog.
Why KSPM also falls short
Even KSPM falls short here, in that it is only looking at configurations at the orchestrator level, and usually at polling intervals. To understand more about where KSPM falls short (though it is a critical component of securing Kubernetes), it's important to understand the value of Kubernetes-first cloud native security,
Which approach is most efficient?
Ultimately, the different layers reveal substantially different sets of security requirements. Infrastructure layer security needs to focus on the hardening and protecting of each cloud resource as distinct units in a workload agnostic way. Generally speaking, this is not a deterministic approach, it is relatively reactive and kicks in after deployment, and volume is the name of the game. CSPM will focus on things like hardening hosts and networks, as well as restricting access to particular infrastructure components.
Contrast this with a Kubernetes-first view of cloud native security, where your understanding of risk takes into account all the resources, viewing them as a composite entity organized on a graph. As mentioned above, Kubernetes security can also assume all its workloads are containerized, a constraint that may not be true at the cloud/infrastructure layer. As a result, this view will focus on things like API security, controlling access to the control plane, properly provisioning RBAC roles within the cluster, admissions control, container permissions, and real-time workload protection. It is a more deterministic, efficient way to view the world because from this perspective it is clear what is running at any given time; therefore what security risks make sense to prioritize.
Without a deterministic, connected view of Kubernetes you are essentially playing whack-a-mole with cloud service account configurations.
Conclusion
The major element that cloud security will not cover for a Kubernetes environment is the broad connectedness from the application down to the infrastructure. This lack of critical context means noise and inoperable findings. In contrast, creating real-time connections that span from the orchestrator to the application workloads and other Kubernetes components (including the cloud) can massively reduce the time to accurately your risk. In the end, the cloud is directed by Kubernetes, not the other way around.
To see how a Kubernetes-first approach to cloud native security can be used to prioritize risk and detect incidents in Kubernetes environments during the time it takes for your coffee break, join us for the live demo.
