Gating Access to Kubernetes API & Workloads with HashiCorp Boundary

In this post, we’ll look at the latest HashiCorp Boundary and Kubernetes integration and the access problems it solves. Kubernetes gives DevOps teams a platform to abstract container orchestration and manage the lifecycle of applications at scale in organizations of all sizes. HashiCorp has made a concerted effort to support and develop native integrations with Kubernetes across our projects.

HashiCorp Boundary is an open source project that enables practitioners and operators to securely access dynamic hosts and services with fine-grained authorization without requiring direct network access and was launched at HashiConf in 2020. In the four months since its public debut, the Boundary engineering team has been working hard to develop core maturity as well as ecosystem integrations.

»Kubernetes Access Model

Today, the access model for applications running on Kubernetes is a coarse-grained experience. Kubernetes users can fork a shell within a container using kubectl exec. This model solves access to the container, but once the user gains access they have a blank check to do as they wish inside that container. Other controls are necessary to safeguard the container runtime as well as other containers running on that Kubernetes cluster.

Securing containers is a multi-faceted process that often transverses the technology stack, it starts with host-level security, runs up the stack to container platform security, how the container runtime is forked, then gets into Linux primitives such as how users and groups are managed within the container image itself. It all goes without saying: container security is hard.

The extra controls needed around the container runtime itself are a byproduct of kubectl exec giving shell access to a container. Yes, there are many methods for accessing applications running inside a container on Kubernetes. None of these access models necessitate forking a shell as they rely on ingress controllers or other network abstractions for giving a user access to a TCP session. However, if you want to protect access with role or attribute-based access control (RBAC or ABAC), it can be a complicated process when you want to integrate these access models with existing solutions you may have such as a company directory.

»Gating Kubernetes with Boundary

This is where HashiCorp Boundary comes in. By running Boundary on Kubernetes, you can restrict network access for ingress to one point, the Boundary pod. This ingress point for users can proxy all necessary TCP sessions to any container on Kubernetes. This can be done with minimal operational overhead and next to no YAML engineering.

The outcome of this is an access model capable of seamless integration with a fully functional RBAC system. What is even more compelling is that this same tool can integrate with an underlying cloud platform to provide one tool to access the infrastructure for the underlying cluster, to the workloads running on top. Imagine being able to start a fully managed, RBAC-controlled SSH session to a VM underpinning your Kubernetes cluster, and then starting another session with the same tool to get access to the application running in a container on top of that cluster. That’s the power of HashiCorp Boundary on Kubernetes.

Gating access to services within your cluster with Boundary is only the beginning. In our latest 0.1.4 release, we have included a new boundary connect kube feature. This command forks kubectl under the hood to allow you to gate API calls to your Kubernetes cluster with Boundary. This allows you to use the same tool across your development and operations teams to administer Kubernetes and access workloads on top of it.

»What’s Next

These updates are very exciting for us, and as we look into the future road map we know that they are even more powerful as we develop dynamic host catalogs and session recording for the Kubernetes ecosystem.

The latest release wraps up the story for secure software-defined perimeter for Kubernetes, both the API and workloads on top. We built a new deployment example for Kubernetes in our reference architecture repo. You can use this as an example or for getting started with HashiCorp Boundary on Kubernetes.