If you’re running Kubernetes or OpenShift, you likely have cert-manager spun up to help you manage the load of installing, deploying and renewing the certificates within your clusters. And we have Jetstack, now Venafi, to thank for that. However, you’ll need to do more to bridges the gaps.
- How do you manage deployment of cert-manager instances when new releases come out?
- How do you view every identity issued from every instance in every cluster?
- And how do you manage all platforms on which your Kubernetes clusters could be running?
To answer those questions, we created TLS Protect for Kubernetes, a solution that fills in the gaps and provides singular control over any certificate, instance or cluster across any Kubernetes platform. Here’s how it works.
What gaps does basic cert-manager leave behind?
Cert-manager instances ensure certificates are updated – but what updates the instances? First, let’s review what cert-manager is meant to do:
- Automate certificate issuance and renewal, protecting Ingress with TLS
- Work with Public and private Certificate Authorities (Let’sEncrypt, HashiCorp Vault, Venafi and others)
- Secure pod-to-pod communication
- Provide certificates for web-facing and internal workloads
- Offer cloud-native protection with open-source add-ons for additional security
- Make sure certificates are valid and up to date:
While cert-manager is an effective, general-purpose certificate management controller for Kubernetes, it lacks higher-up oversight to ensure it is using the latest stable version. You can’t just set it and forget it – the instances themselves need to be updated upon every new release. And, when you might have clusters running on a multitude of Kubernetes platforms – in the cloud, through a CSP, or in a virtual environment running as OpenShift – how do you ensure the rollout effectively finds and reaches all instances? Do you even know where all instances are?
While powerful and effective at deploying and updating the certificates themselves, there are overall management functions cert-manager is not equipped to do:
- Cert-manger will not automatically update instances to the most recent version. This leaves your team to manually handle deployment of all cert-manger instances as new releases are made available – across whatever platform your Kubernetes clusters may reside.
- It does not give you visibility into every machine identity (certificate) issued by every instance in every cluster. If you want the full picture, you must hunt down the parts and piece them together.
- Even if you could get a configuration management database (CMDB) to do the hard work of discovering disparate security resources across your enterprise, the most it will do is provide the data in a report, leaving time-consuming analysis to your team.
Cert-manager is only half of the Kubernetes security puzzle. TLS Protect for Kubernetes now provides the other half.
How does TLS Protect for Kubernetes help?
If cert-manager provides Kubernetes the certificates it needs, TLS Protect for Kubernetes provides the certificate management. Venafi worked with experts from Jetstack to create a cloud-native solution that would provide control of X.509 configuration across Kubernetes and OpenShift clusters. No more deploying cert-manager instances across multiple platforms and losing track of them. No more being in the dark about which ones are running the most stable version, or manually investigating numerous instances to find the answer - or ignoring the question altogether.
With TLS Protect for Kubernetes, you’re able to see critical information like certificate origins, the CA that issued them, their compliance with your corporate policy, and why you may have failed a policy check. With this platform-agnostic solution, you can gain visibility of all deployed certificates in whatever cluster they may be, all from a single control panel. TLS Protect for Kubernetes provides the way to aggregate, audit and manage machine identities deployed within Kubernetes, and complements, enhances and contextualizes the work of cert-manager.
Use TLS Protect for Kubernetes to:
- Avoid certificate misconfigurations.
- Know if any cert-manager deployed in any cluster isn’t running the latest version and needs to be upgraded.
- Have immediate visibility into new clusters as they are onboarded into TLS Protect for Kubernetes (wherever it’s running) as they pop up on the dashboard.
In short, a full, live inventory of all cert-manager instances, whether they are running the latest stable version, and what machine identities they provision within your Kubernetes environment. Cert-manager is only as good as the visibility you have into your ecosystem because losing track of any machine identity puts your whole Kubernetes or OpenShift workload at risk.
- Open Source Makes Machine Identities on Kubernetes Accessible for All
- Google CAS Supports cert-manager and TLS Protect for Kubernetes for Cloud Native and Private PKI
- Pulumi Policy-as-Code for cert-manager Simplifies Machine Identity Management
- Open-Source Community: CNCF Sandbox Accepts Cert-Manager