The Risks of not Knowing How Many Kubernetes Ingresses your Organization Has

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.

What risks am I facing by using containerization in the cloud?

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.

Are your Kubernetes ingresses secure?

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.

So, I’ll ask again. How many ingresses are in use within your organization?  How many different cloud-native applications have been deployed?  If you can’t answer these questions, then you do not have visibility into the risks these ingresses pose. And if you don’t understand the risks, you can’t implement solutions to prevent them.  

What if your developers are already using cert-manager to secure containers?

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.

How can Jetstack Secure improve the protection I already have?

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:

• Automate visibility and control of the X.509s that protect your ingresses across the ecosystem
• Avoid certificate misconfiguration within your clusters
• Proactively monitor entry points within your clusters and mitigate malware attempts
• Establish a full chain of trust infrastructure-wide by enforcing pod-level security
• Have the full benefits of the Venafi Trust Protection Platform (TPP) (along with the capabilities of a Jetstack certificate manager) to policy-govern certificates across Kubernetes and your entire infrastructure.

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

• Code Signing Risks and Containers: What You Need to Know
• Build It Now, Protect It Later Mentality Challenges the Security of Containers
• TLS Everywhere in Kubernetes: Not Just Entry and Exit