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.
Read the rest of this article at the Mirantis blog.
