No more moats: Hardening cloud native security
A recent SlashData report with the Cloud Native Computing Foundation found a 67% year-over-year increase in Kubernetes adoption–but it’s clear that security practices aren’t keeping pace. For example, organizations such as Tesla have experienced cryptojacking attacks on their Kubernetes clusters because of misconfigured components. In June 2022, security analysts estimated that more than 900,000 Kubernetes clusters are improperly exposed to the open Internet, creating an unnecessary attack vector and opportunity for data leakage.Kubernetes enables organizations to achieve High Availability and resilience, but at the cost of complexity that can lead to serious vulnerabilities if a team doesn’t have experience standing up a cluster.
Beyond the inherent complexity, cloud native computing requires a dramatic change in thinking about security. A cloud native environment is fundamentally different from traditional data centers, in that it is usually distributed and designed to run many containerized workloads. The castle-and-moat thinking that predominated in classical data center security—treating the network perimeter as a moat and the network as a secure stronghold—simply doesn't cut it anymore (if it ever did).
In fact, operating with those metaphors is apt to put your systems at risk, even in a traditional data center. Fortunately, cloud native security means we must act as if there is no perimeter, proceeding with a presumption of “zero trust.” That means monitoring and validating everything within your system–not only users and devices, but software components, including the dependencies of dependencies within every containerized microservice. A minimum viable cloud native security strategy means creating a secure software supply chain.
That may sound daunting, but there is good news. Kubernetes is a highly resource-aware and extensible system, and the Kubernetes ecosystem includes a range of components to support a secure software supply chain and other security measures. This can help you incorporate four key elements of Kubernetes security:
Private container registries (and scanning)
RBAC and secure CI/CD
Software Bill of Materials (SBOM)
Disaster recovery measures
Private container registries (and scanning)
In Kubernetes, workloads are based on container images. Additionally, software is often built on the foundations of existing container images for common components like programming languages or web frameworks.
In other words, container images are essential building blocks. But like any other element in your system, they can’t be trusted. Original container images should be signed and verified. Existing container images should never be drawn from public registries like Docker Hub, which are vulnerable to tampering and malware–one discovery firm found over 4 million Docker Hub images with vulnerabilities open to exploitation.
Instead, organizations should rely on private container registries with robust image signing and registry scanning capabilities. A private registry enables you to use Role-Based Access Control (RBAC) to determine who can use and update container images. It helps you to validate the software that flows out of the registry–and if you have a good registry scanner, you can run regular scans against a CVE database to ensure that there are no known vulnerabilities lurking in your images.
There are a number of options for private registries available. Harbor is an open source private registry option in the CNCF ecosystem, while Mirantis Secure Registry provides a supported option for enterprises, with RBAC and registry scanning.
RBAC and secure CI/CD
Role-based Access Control (RBAC) applies to more than your private container registry. It should be enforced across a Kubernetes cluster. Fortunately, Kubernetes makes that relatively easy, enabling you to define specific roles using the principle of least privilege—meaning any user should have only as much system privilege as they require for their function. Kubernetes namespaces give you a way to enforce separation based on team or other variables, while still permitting controlled access to shared resources.
Of course, workflows are a bigger issue than individual users and the resources to which they have access. It is a good idea to implement policy-as-code to enforce security policies as part of a security-conscious CI/CD process. There are a number of powerful tools to help you manage workflows with Kubernetes, but it’s important that you evaluate them for security concerns. For example, Argo is a popular suite of open source tools in the CNCF ecosystem that help to automate, observe, and manage deployment, but it poses serious security considerations that users need to evaluate carefully, implementing mitigations or workarounds as appropriate.
A thoughtful approach to CI/CD can both avoid vulnerabilities and help to harden security. Tools such as Mirantis Secure Registry can support workflow automation with features such as automatic image promotion based on security validation, reducing the opportunity for human error.
Software Bill of Materials (SBOM)
In order to effectively pursue a zero trust security posture, you need to know exactly what you’re not trusting—that is, you need a full and up-to-date picture of every component in your system. That way, you can:
Monitor and validate those components,
Know that they are present on your system if they are found to contain a vulnerability
Remediate the component efficiently when problems occur
A Software Bill of Materials (SBOM, often pronounced “S-bomb”) is no more or less than a complete, up-to-date, itemized list of every discrete software component on your system. That’s a simple concept, but it can be complicated to put into practice—it needs top-to-bottom insight into everything on your system, and it needs to be continuously updated to reflect the state of your cluster.
This difficulty means that many organizations are behind in establishing comprehensive SBOMS, despite the simplicity of the concept and their obvious utility. The Open Source Security Foundation identifies SBOMs as one of the ten pillars of their Open Source Security Mobilization Plan and notes that they are insufficiently generated and consumed today.
Fortunately, there are tools available to ease the process, with more being developed all the time. Syft is an open source command-line tool for generating an SBOM from container images, reflecting the image’s entire dependency chain and filesystem. Syft forms part of the basis for Codenotary’s Kubernetes SBOM Operator, which is available as part of the free and open source Community Attestation Service.
Disaster recovery measures
A modern security posture means not relying on a moat, but assuming that your castle (or castles) will be breached. It’s essential to be prepared–not just for mitigating issues in individual components, but for the eventuality that your entire system may be compromised or lost, whether due to natural disaster or ransomware attacks.
When properly configured, Kubernetes boasts a high degree of resilience, but this can lead some organizations to a sense of false security. Cluster configuration data and persistent data from stateful applications often remain vulnerable, and you can’t trust that it will simply be okay. Disaster recovery solutions tailored to Kubernetes are an important step to mitigate risk, so that if and when an issue arises, you’re prepared to mitigate it.
Tools such as TrilioVault for Kubernetes help to protect cluster metadata, Helm data, and application data in persistent volumes, working across a variety of storage solutions and clouds.
Conclusion
As organizations transition to cloud native environments, they need security strategies specifically tailored to those environments. Mitigating risk and using open source tools like Kubernetes effectively means understanding, intimately, how cloud native technologies work, how they can be compromised, and how they must be properly configured. While the approaches and components in this article aren’t enough on their own to ensure ironclad Kubernetes security, they are the baseline you should expect from any cloud native security strategy moving forward.
