There are few companies today not already using containerization and microservices. With this convenience, however, comes a tradeoff—how do you make sure every point of entry into your Kubernetes or OpenShift cluster is secure? And what happens if they aren’t? I’ll cover those questions and more, telling you how you can protect not only your machine identities in the cloud and on-premises—all from a single control plane.
But first, can you answer this basic question: how many ingresses does your organization use throughout all of your Kubernetes deployments? If you can’t answer that, then your company is at significant risk of an outage or a breach.
As companies rush to implement containerization in the cloud, the efficiencies provided may not be correctly accompanied by proper security measures. Some consequences of migrating with improper or incomplete machine identity management practices are severe. Attackers can gain access to the cloud at any vulnerable endpoint and pivot laterally through the network from there. This risk can be severe, given the number of services, connected devices, virtual machines, executables, containers that your organization relies on in the cloud.
The high number of endpoints that have their bearings in the cloud naturally increases the attack surface and makes it a more lucrative target. Just last year, the 2021 Verizon Data Breach Investigations Report (DBIR) stated that cloud breaches had surpassed on-premise breaches for the first time. It is not surprising, given that the cloud is not only increasing in scope but in popularity. According to a report by Flexera, over 50% of organizations moved to cloud-hosted workloads in 2020 alone, and 93% of those had a hybrid strategy—meaning they still had to oversee management of on-premise machine identities. Adding to cloud complexity, Forrester reported container adoption by developers increasing to 42% in 2021.
Given the rising trend and the reliability, efficiency, and productivity of cloud containers, we can be sure we will only see more of these in our environments in the future. Therefore, it becomes imperative to become an expert at how to secure them.
What is ingress, and why should we protect it? ISACA defines ingress as “network communications coming in.” It is any single point of entry into your deployed applications, and protecting the ingress protects the application itself.
Machine identities, including the digital keys and certificates used within your Kubernetes cluster, protect Kubernetes ingresses. If a certificate expires, you experience an outage. If a machine identity is compromised, you could allow an attacker into your container to pivot to other areas of your network. If a certificate is not secured with a trusted CA, it can leave your entire cluster open to potential theft and permissions abuse.
There’s a lot that can go wrong by leaving the doors to your ecosystem unguarded. And those same efficiencies that make Kubernetes run so well can be exploited to create efficient malware attacks with maximum damage.
That is good news. The wildly popular open-source cert-manager is used to help manage X.509 certificates within Kubernetes clusters. With over half a billion downloads in 2021 alone, it is the de facto standard for helping cloud teams manage the TLS certificates used for ingresses. But did you know that the company that developed cert-manager is now a part of Venafi? In 2020, Venafi acquired Jetstack, the inventors of cert-manager. Later that year, we donated cert-manager to CNCF but continue to be the primary contributors.
By using cert-manager, organizations not only have the visibility that is needed on ingresses but also can help reduce the risks of unprotected ingresses or those that use certificates that are configured incorrectly.
But this is only part of the problem that needs to be solved to truly secure ingresses. While a single cert-manager instance within a Kubernetes cluster can provide visibility and protection for that cluster, an organization does not have enterprise-wide visibility across multiple Kubernetes clusters.
Furthermore, organizations are not able to enforce the use of specific cert-manager versions or ensure consistent configurations across these deployments. Nor are they able to ensure that the versions of cert-manager used are commercially supported (beyond community support) and comply with regulations, like FIPS.
Thus, while cert-manager is perfectly suited for development environments, more is needed when the Kubernetes application is deployed to production.
From a production-ready, enterprise perspective, Venafi’s Jetstack Secure is designed to take security of ingresses to the next level. Jetstack Secure is delivered with a signed, FIPS compliant build of cert-manager of known version. Through integrations with common enterprise security platforms like the Venafi Trust Protection platform, Jetstack Secure ensures that corporate machine identity security policy is complied with, even within a Kubernetes deployment. And this is done without slowing down DevOps and cloud native teams.
Venafi Jetstack Secure takes over all responsibilities of guarding your ingresses within the Kubernetes cluster. By working in tandem with the Venafi Trust Protection Platform to provide a central control point for all machine identities across both classic (traditional IT infrastructure) and cloud native environments. It combines the certificate management services of cert-manager with the visibility, automation, and intelligence of the Venafi platform, and gives you increased awareness into the status of the machine identities that defend your ingresses: in and out of the cloud.
Venafi Jetstack Secure combines cloud-native machine identity security with automated PKI to protect your X.509 certificates across Kubernetes and OpenShift clusters. It allows you to:
Misconfiguration is one of the most common problems facing Kubernetes today and can render ingress insecure. With the Jetstack Secure extending the Venafi platform, you can have full visibility into the configuration status of all X.509s across your Kubernetes and OpenShift clusters, and all on a single control panel. Containerization and virtualization are state-of-the-industry technologies and require state-of-the-industry cybersecurity solutions. We cannot protect the next generation with the last one.
Related Posts
The risks of securing cloud-native with traditional security measu
Read More