Click to learn more about author Ross Moore.

Like any other technology that excels in its field, Kubernetes (aka K8s) has become what is perhaps the standard in container orchestration for a reason – its common framework provides advanced capabilities needed in a management platform, including (but far from limited to) high fault tolerance, auto-scaling, and automated deployment.

The focus of this post is a particular aspect of Kubernetes security: access control.

What does Kubernetes offer for access control? Its built-in methods are as follows:

1. Attribute-Based Access Control (ABAC)

• With the ABAC schema, the admin assigns an identity or subject the desired attributes (e.g., group, resource, namespace).
• Because of RBAC and other technologies, this is considered deprecated, even though it’s still available.

2. Node

• This is primarily used internally and is managed by components such as kubelets.

3. Webhooks

• Used for integrating with external services.

4. RBAC

• Role-Based Access Control

Here is the official authorization control documentation.

Let’s take some time to review the RBAC option.

What Is RBAC?

The RBAC model for security in general was introduced in 1992, and it has become the standard way for organizations to simplify assigning roles. Speaking in normal terms, RBAC is amazing. For those of us who have worked extensively with Active Directory, it’s phenomenal to set up a directory structure and assign roles, knowing that those placed there in the future will inherit the permissions of the parent group. I can’t imagine having to assign all of those roles, permissions, and relationships one a time. Thank you, Ferraiolo and Kuhn!

Back to K8s – ClusterRoles and Roles, which define what a user can do in a cluster or namespace, can be assigned to the subjects (users, groups, service accounts) by using RoleBindings and ClusterRoleBindings.

A couple of default ClusterRoles are system:basic-user and system:discovery, and a couple of default user-facing Roles are cluster-admin and view. Deny All is the default, and all of the permissions grant access – there are no “deny” permissions. You can view the defaults here. 

RBAC is not enabled by default, but can be enabled from the API server like so: 

kube-apiserver –authorization-mode=Example,RBAC –other-options –more-options

RBAC in Kubernetes offers a quick and powerful way to streamline the provisioning of permissions. 

What Are Some Areas to Improve in RBAC in Kubernetes?

With excelling technologies, the complexities can be overwhelming, even to knowledgeable professionals. RBAC in K8s is one such complexity. These kinds of complexities actually end up being good for the technology industry – they open the doors for other companies to innovate options to make up where the original technology is lacking. 

While the built-in methods that Kubernetes provides for permission offer a fairly granular approach – RBAC providing the best innate option – as with the typical RBAC model, any customization of Roles, et al. requires either 1) manual management, or 2) third-party tools.

With RBAC in general, there’s always some resource that has inherited all of those permissions, and there has to be at least one person who needs that folder, but who is not in the role. Then it becomes a manual issue. In Kubernetes, a developer needs access to much of the cluster, but not to a certain pod (remember: there is no deny permission). Kubernetes retains the same issue with RBAC – it does not have a built-in automated or easy-button tool for managing and maintaining the finer points of roles and permissions. 

K8s admins have to manually create Roles and permissions. This is fine as far as having the ability to create and administer. The issue is with keeping up with all the changes. The administrator is responsible for keeping tabs on the Roles, RoleBindings, ClusterRoles, ClusterRoleBindings, ServiceAccounts, et al. that have been customized. Over time, especially if one started with ABAC and the organization has been around a while, the “privilege creep” and outdated rules can be overwhelming.

With no centralized portal or dashboard to manage the proliferation of permissions, there’s a call for tools to help the admin.

How to Overcome the Obstacles

These situations aren’t reasons to shy away from Kubernetes. Rather, they are obstacles to overcome so that administrators have the tools necessary to make security happen.

What are some options for overcoming the permissions obstacles?

For those in Microsoft Azure, the admin can configure the Azure Kubernetes Service (AKS) to work with Azure AD to provide the auth token. The documentation is found here.

For those using Amazon Web Services (AWS), Amazon’s Elastic Kubernetes Service (EKS) provides authentication via its Identity and Access Management (IAM) service. Amazon’s documentation is found here.

Another option is the open-source policy engine known as Open Policy Agent (OPA – pronounced “oh-pa”). You can check it out here. 

Karen Bruner provides a great write-up on OPA, including detailed examples of syntax, here, so I won’t attempt to reinvent the wheel. But for those who are looking for a general-purpose policy enforcement tool for K8s that doesn’t require a subscription service, OPA is a good choice. (Karen’s article also gives a nod to another open-source policy engine, Kyverno, found on GitHub here.)

Handling RBAC in Kubernetes is not a matter of “don’t use RBAC.” Rather, it’s about RBAC “+.” Manually managing RBAC in K8s may be feasible on a small scale. Managing it at scale, however, requires improved tools to maintain K8s security. The old adage of “complexity is the enemy of security” remains pertinent to K8s. Like any other technology, advancement speeds up what is done manually. If the task was done well, it’s sped up. If it’s done poorly, that’s done faster.

Even the best technology doesn’t obviate the need to for diligence in maintaining security. K8s burgeoning popularity has paved the way for creating and adopting account controls that outstrip the manual, and even built-in, methods. Motivation leads to innovation (necessity is the mother of invention). Innovation leads to further creation (invention is the mother of necessity). Don’t give up on finding better ways to secure containers. The answer is out there – keep looking and trying.