Unlocking the full potential of Kubernetes can often feel like navigating a complex maze, especially when it comes to managing shell access to your resources. Traditional methods, like relying solely on Kubernetes RBAC, fall short in providing the granularity needed for precise access control. Say you wanted to define fine-grained access controls for who can access shells in which pods based on labels, Kubernetes RBAC alone is not enough. In order to do this with Kubernetes alone, you’d have to leverage Kubernetes Admission Controllers and write (and run) your own software in order to allow/deny Kubernetes API requests. This task quickly evolves from challenging to daunting.
With Border0, granting fine-grained access to resources is a piece of cake! You simply deploy a connector with the right permissions inside or outside of your cluster, and create a “kubectl exec” socket with the namespace/selectors allowlist you need!
Border0 is even more useful when the required access is short-lived. For example, say you wish to give access to only one contractor only for the next two weeks. You can attach a policy to your “kubectl exec” socket such that only specific identities can access the resource and only under specific conditions.
The Border0 integration with Kubernetes offers your employees or users a seamless, passwordless experience using their everyday SSO credentials while simplifying your administrator’s daunting task of provisioning access. Border0 not only simplifies access, but also enhances security, visibility, and control.
In this blog, we’ll showcase how easy it is to set up Border0 for Kubernetes.
Running a Border0 Connector in Your Kubernetes Environment
Border0 maintains a public Docker image which you can use in a Kubernetes Deployment to easily drop a connector in your Kubernetes environment.
Border0 also offers an example Kubernetes yaml file to leverage the public Docker image in a Kubernetes Deployment, along with the creation of a fine-grained Kubernetes RBAC ClusterRole and Kubernetes ServiceAccount for the connector to have permissions following the principle of least privilege. You can find this example here.
To get started:
- (1) Navigate to the “Connectors” tab in the Border0 admin portal and create a new connector
- (2) Create a new token for your new connector connector
- (3) Download the sample Kubernetes yaml file from the Border0 examples repository
- (4) Replace the stubs in the example file with the token you created in step (2)
- (5) Apply the yaml file with `kubectl apply -f connector.yaml`
After a few seconds, you should see your connector become online in the Border0 admin portal. You now have a connector capable of exposing any pods in the cluster behind Border0 sockets!
Creating a Border0 Socket for Your Kubernetes Resources
Sockets are Border0’s abstraction for services. They can also be thought of as a unit of access. When it comes to Kubernetes sockets, the scope of a socket can be either the entire cluster, one or more namespaces, and, optionally, pods that match one or more selectors in each namespace. How narrow or wide you go with your socket depends on your organization’s specific needs.
Assume you don’t need fine-grained access (e.g., you have a small team where everyone has shared ownership of everything). You would only need one socket for the entire cluster.
However, let’s imagine a scenario where you want folks in one engineering team to have access to pods with the labels “app=api” and, simultaneously, a different engineering team to have access to pods with “app=webapp.” In this case, you would create two Border0 sockets, each with its namespace/selectors filters and a distinct Border0 policy granting access only to the right folks.
Border0 Policies, Zero Trust, and No Need for VPNs
Border0 policies are simpler and, at the same time, more flexible than other policy languages out there. You define access in terms of “who can access what, when, and from where”, defining users, IP addresses, countries, and time ranges in which access should be granted.
YYour employees (or users) are authenticated with their everyday SSO credentials, eliminating the need for passwords prone to theft or loss. Our solution also eliminates the need for legacy VPN technology entirely! The Border0 connector uses an outbound connection to our globally distributed proxy servers, which means the connector can operate in a private network behind NAT.
Border0 provides state-of-the-art identity-aware access to all of your admin servers, including SSH servers, HTTP servers, database servers, generic TCP servers, and a variety of lightweight wrappers on top of many popular services, including AWS EC2, ECS, RDS, EKS, and equivalent services in other cloud providers.
Wrap-Up
In this blog post, we looked at how we can manage various levels of access to resources in Kubernetes leveraging the Border0 connector and the new “kubectl exec” sockets. Our customers often tell us how easy it was for them to onboard their hybrid environments, Kubernetes and otherwise, across multiple cloud providers and on-premise deployments. We hope this blog has showcased how simple it is to put your servers behind Border0.
Why settle for the outdated confines of conventional access management? Step into the enhanced adaptability and governance that Border0's policies offer and leverage the transformation in access management. Take the opportunity to explore the advantages of Border0 firsthand by registering for our free, full-featured community edition today.