Kubernetes (also known as k8s) is more popular than ever, and many organizations have tens of clusters with tens (or even hundreds) of engineers accessing each cluster using tools like kubectl, lens and k9s. But ensuring zero trust access to your Kubernetes cluster is hard. How do you make sure that outsiders can’t get into your cluster? How do you ensure that the right insiders have the right permissions to access the right parts of your cluster? How do you ensure that when people do access your cluster (using kubectl, k9s, lens or any other such tool), you have good visibility and audit logging of what they did with this access? If you have these kubernetes security issues, BastionZero can help.
Problems that result in Kubernetes security issues.
Problem: Exposed k8s APIs. We know that many organizations are not correctly securing access to their clusters. How do we know? Well, in June 2022, a study by Cybel found almost one million Kubernetes APIs exposed on the public Internet. One million! And these aren’t all just toy clusters in somebody’s home network, these are real Kubernetes security issues at major companies. Anecdotally, I’ve spoken to multiple teams who sheepishly admitted that their production Kubernetes clusters do indeed have APIs that are exposed to the Internet. This is an antipattern. Why? Because adversaries can probe your Kubernetes APIs for weak credentials or known vulnerabilities, which creates needless risks for the security of your infrastructure. Best practice is to take these APIs off the public Internet, and close their ports, if possible.
Problem: Privilege creep. Also, it stands to reason that if there are that many clusters exposed on the public internet, then there’s very likely also a large fraction of these clusters that lack proper controls to ensure least-privilege access. Do these clusters have good guardrails in place to ensure that the right people (or service accounts) have access to the right namespaces in the cluster? Is access granted through long-lived credentials that are never revoked, and therefore could be stolen without anyone noticing and then used much later in an attack? Are there controls in place to understand who has access to which cluster, under which role or user? Because if there isn’t, once someone gets access to something, that access never gets taken away, resulting in a classic case of privilege creep. I’m framing this as a security problem, but it’s also a management problem: If you have admins spending too much time on granting, tracking and revoking access to Kubernetes, you’re wasting the time of a valuable engineer who could instead be focusing on tasks that bring more value to your business.
Problem: Poor audit logging. In many ways, kubectl (and similar tools like k9s, lens, etc) are “the new SSH,” because they allow engineers to read, write and modify infrastructure. As a result, many teams are struggling to satisfy compliance requirements or answer security questionnaires because they don’t have a good handle on who accessed what parts of their cluster and what they did with this access. Security and compliance demand that you have audit logs of each access. And it’s not enough to know that someone logged in as cluster-admin: You need to know who exactly logged in (Alice) and what she did when she logged in (kubectl delete cronjob some-important-cronjob).
How BastionZero provides zero trust Kubernetes access.
BastionZero’s Zero Trust Access Platform helps organizations manage developer access to k8s clusters, using policy-based access to eliminate the complexity around granting least-privilege access.
True zero trust Kubernetes access. With BastionZero, you can eliminate long-lived credentials and instead offer zero trust access to your Kubernetes API, where engineers have short-lived, just-in-time access to the cluster using SSO and an independent MFA. And unlike other zero trust solutions, you don’t need to trust the BastionZero service with privileged access or credentials to your cluster. By not storing your credentials, we avoid having BastionZero become an attractive target for adversaries (adversaries do love to attack overprivileged systems that store the credentials to everything) and we avoid BastionZero becoming a single point of compromise. We offer the truest form of zero trust, where you don’t have to trust anyone, not even us. (Learn more about our unique security model here!)
Get your Kubernetes API off the public Internet. With BastionZero, you can take your Kubernetes APIs off the public Internet. The BastionZero agent can be quickly and easily deployed (via Helm or YAML) as a container in your Kubernetes cluster. The agent then phones home to the BastionZero cloud service, which ensures that you don’t need VPNs, public IPs or open ports to access your Kubernetes API. Instead, the agent brokers connections between the user and the Kubernetes API, while ensuring that the BastionZero cloud service does not have privileged access to your cluster.
Centralized policy management and audit logging. BastionZero’s cloud service provides a unified management plane for setting policies about who has access to what cluster, when, and for how long. Our cloud service uses the Open Policy Agent (OPA) under the hood to allow you to set policies about who has access to what — so you can specify exactly what IdP users (or IdP groups) have access to what kube users or kube group on each one of your clusters, regardless of what VPC, cloud or on-prem environment they happen to live in. Provide just-in-time access and integrate with Slack to offer workflows for requesting access and approving access. Each access request is logged with the kubectl API call along with the time and the identity of the user executing the command. BastionZero can even introspect on any call to kubectl exec, and log all of the individual commands that the user performs once they log into the cluster, giving you full visibility into what your engineers are doing to your clusters.
Spend less time configuring access for your teams. With BastionZero, you can avoid the pain of setting up individual developers with the kubeConfig files they need to access the cluster. Instead, their local configurations are automatically generated in compliance with the centralized policies that you set up in the BastionZero cloud service. This means less time granting access, auditing access and answering troubleshooting tickets from your engineers.
Ready to give BastionZero a try?
BastionZero integrates with your SSO, works with your existing Kubernetes workflows and is easy to deploy via YAML or Helm. Try it out right now by creating an account on our free tier, drop an agent to your cluster, and see how easy and quick it is to access your Kubernetes API with least privilege, just-in-time access and audit logging. Moving your clusters to a zero trust security posture is much easier than you think.
