Kubernetes Access Doesn't Need to Be Complex

It’s a Catch-22: your developers love Kubernetes, but provisioning and managing access can take hours. You’re constantly scrambling to generate certificates, configure clusters, and assign them to run on the correct namespace. But you’re not alone.

Kubernetes is by far one of the most popular container orchestration systems. Nearly half of organizations report using Kubernetes for managing, scaling, and automating application deployment. But in a global survey, respondents ranked security as a top challenge with running Kubernetes.

Why Kubernetes Access Causes Headaches

Keeping track of issued certificates is difficult. When you’re building a cluster, you generate certificates and assign them to users. Then, you need to put those into KUBCONFIG files. If you lose them, you can generate new certificates, which is more complicated than a password reset. Administrators also must manage the certificate lifecycles: updating permissions, revoking access, dealing with expired certificates.

When you first build a Kubernetes cluster, you create an initial administrative user. “Out and Back” in newer versions of Kubernetes means that the administrator can go in and configure the users and the context, which is essentially the cluster.

Everything in the cluster lands in default unless the administrator specifically configures distinct namespaces for applications/containers to run.  By default, the containers will all run with default access – and everyone who has a certificate will be able to access all the containers, completely unfettered. This opens you up to everything from accidental errors to malicious tampering.

Kubernetes platforms have some tools that do this natively, but admins need to know exactly what to do in the system. The config file becomes a complex mess, and it’s tough to keep track of logins, reissue certificates, and access resources.

Is Your Kubernetes Cluster Healthy?

When you first onboard with a tool like StrongDM, you will want to know how your Kubernetes clusters are set up. The built-in health check will run a namespace test and let you know if you’ve been running everything in default. Then, you can set up namespaces with specific permissions. For example, you could set up cluster group roles for different namespaces.

Automation Simplifies Kubernetes Access

Setting up user roles is just one way to automate–and simplify–Kubernetes access. Manual access management can virtually be eliminated with StrongDM. Once system administrators assign roles, the users can log in and use their Kubernetes client as they usually would.

Essentially, if you’re using StrongDM, you don’t have to constantly provision and maintain certificates for Kubernetes access. Instead of creating generic roles, you can create group-based roles with user impersonation details.

One of the concerns for a lot of companies is being able to track who is making changes in each system. With StrongDM, you can set up user impersonation, which essentially allows Kubernetes to natively log the identity of the user that is interacting with a cluster versus the organization that user belongs to.  Suppose a company requires an audit log for something like SOC 2 compliance. In this case, an administrator can pull the native Kubernetes logs and discover which exact user was making changes since the user impersonation feature enhances native Kubernetes logs with visibility into who executed each command.

The bottom line is that provisioning and maintaining Kubernetes access doesn’t need to be a full-time job. Much of it can be automated with StrongDM, resulting in more productive system administrators and users who can access the necessary clusters for their jobs much faster.

How to Get Started

Want to learn how you can simplify Kubernetes access? Sign up for one of our no-B.S. demos here.