How to Implement Scalable Access Controls with RBAC: Best Practices for Zero Trust Environments

In the arms race to secure environments, codifying permissions often becomes an afterthought in the wake of setting up a new access tool. I often speak with organizations that either don’t know who has permission to what, or have no permission definitions at all.

I once onboarded an enterprise level digital communications company that was losing productivity trying to keep track of who had access to their Kubernetes resources. For example, the team managing access would receive a request for access to a K8 resource, but there was very little structure in place to confidently ensure any of the following:

• Was the requested resource affiliated with the requesting team?
• Did the requesting person need temporary access?
• Could the temporary access be enforced without relying on human memory?
• Could that access be revoked in real time?

A combination of designing a scalable Access Control architecture, and using Teleport to construct and enforce that architecture resolved all of the pain points mentioned above. The team could then spend those saved engineering hours on improving their product rather than constantly cleaning up access.

Powerful access tooling is only part of the equation when it comes to safeguarding resources. Scalable access control architecture solves the permission problems of today and in the future. In this blog, we will discuss the value of a planned-out Role-based Access Control (RBAC) strategy, understanding the gaps your organization currently has, and how to get started on a scalable RBAC strategy.

In this blog, you will learn:

• The importance of a scalable Access Controls Architecture
• How to get started mapping your Organization’s Access Patterns
• Scoping permissions

The Critical Importance of RBAC Architecture for Secure Infrastructure

To start, if you can’t confidently answer who has access to what in your environment, you are going to find passing audits difficult. Perhaps your business isn’t beholden to compliance standards today, but the legislative landscape around cybersecurity is changing daily and you could find yourself scrambling to find a solution.

Security risks aren’t exclusive to businesses in strict compliance spaces. A well-defined RBAC strategy mitigates many of the security risks facing any modern business.

If you ask yourself a few questions about the permissions in your environment and aren’t able to answer them confidently, your environment might be exposed to significant risk. Consider asking the following questions:

1. Are you confident that off-boarded users no longer have access to your resources?
2. How long are credentials like SSH keys valid?
3. In the event of a compromise, are you able to contain the blast radius of the attack?

Outside of the liabilities present in an overly permissive environment or environments overly reliant on cumbersome permission management, there can also be significant overhead costs. To assess what these costs might be, consider asking the following questions:

1. How long does it take to onboard new users?
2. Are productive hours being lost to unwieldy access request workflows?
3. Can your RBAC architecture easily adapt to changing business needs?

By this point, the value of planning an RBAC strategy should be very clear. Now, let’s discuss how to create an RBAC architecture that works for you.

Creating Dynamic Access Policies at Scale

When architecting your organization’s Access Controls and the Policies that ultimately enforce them, scalability must be prioritized at every step. When creating your RBAC architecture you should solve for today and tomorrow.

Scalable policies should follow a simple rubric:

1. Define groups
2. Templatize permissions
3. Label resources

Define your organization’s groups

Having a clear picture of the various groups within your organization and their respective roles and responsibilities is the first step in defining policies that enable productivity without being overly permissive. You’ll start with a list of departments, teams, and titles and then define the minimum required access by group.

Grouping permissions is an effective strategy for ensuring scalability. Groups use predictable access patterns which can be used to inform your role creation. Using individual identities to create roles can result in permission bloat because the roles aren’t reusable. Identity-based permissions should be granted on an as-needed basis, which we will discuss later.

How do you define groups?

There is not one best way to define groups. However, we can ask ourselves some questions, and those answers will start surfacing trends. Consider the following:

1. Do you have a list of departments or business units?
2. Do those departments have teams?
3. Within those teams are there specific titles?

The answers to these questions create a rough outline of your organization’s permission groups. This information also informs Role definitions later on. With this information, you can begin defining permissions to resources based on the department, team, and title a user belongs to.

Templatizing Permissions in Roles

Creating access policies that scale with your organization means avoiding creating roles for individuals. Grouping and templatizing permissions with Role Templates ensures consistency, easier auditing, and a more secure permission strategy overall.

Why should you templatize permissions?

• To reduce permission maintenance
• To scale permissions across many departments
• To ensure permission consistency
• To improve security through reducing complexity

Let's say you are creating roles for the Engineering department at your organization. Within this Engineering department there are two teams. Team A works on both production and test environments. Team B works exclusively on test environments. From this example, you can create two roles that serve the minimum requirements for both teams.

Role A: Grants any member of “Engineering - Team A” access to both production and test environments.

Role B: Grants any member of “Engineering - Team B” access to exclusively test environments.

Templatizing permissions creates predictable access patterns and creates a foundation for later iterations.

Label resources

A foundational Access Control Architecture depends on resources being properly labeled. This is what allows the mapping of permissions to resources without being overly permissive. Users get access to the resources defined in their respective roles, no more, no less.

This can be a challenging change for an organization that hasn’t previously enforced a standardized resource labeling policy. The outcome is worth the effort for a host of different reasons such as:

1. Predictable resource access patterns
2. Inventory and cost control
3. Scalable and agile access change management

Labeling Best Practices

Even if your organization has a resource labeling process in place, the best practices discussed here can improve your operational functions.

Google outlines key practices for labeling your infrastructure in their documentation, Best Practices for labels. These best practices include:

• Always label resources
  • If this is not a mandatory practice in your organization, it should be. Most compute hosting providers have methods of making labels a requirement.
• Standardize label naming conventions
• Automate labeling wherever possible
• Build in flexibility to allow for organizational changes
• Never label using Personally Identifiable Information (PII)

Defining Access through Labels

If a Role defines the “Who” and “How” of Access Patterns, Labels define the “What” and “Why”. Your label strategy should provide the necessary access context to map back to user roles.

If you are starting from scratch, using the organizational Groups you defined earlier in this blog can be a viable labeling scheme to start out.

Let's look at some real world examples.

Label Strategy Example

Premise: A company has a Group of U.S.-based engineers and a Group of Europe-based engineers who should only be able to access resources in their home region.

Label strategy: All resources should be labeled by their geographic region.

 # Key: Value
  Region: Europe
  Region: US

Completing your Access Strategy

At this point you’ve gone from no Access Strategy to having defined Groups, created scalable Roles, and enforced a resource labeling strategy. These all combine to create your overall Access Strategy.

Map Roles to Labels

It is common and often expected to see Groups and Labels align. Here we are going to start making those connections by mapping Roles, and more specifically Role permissions, to resources Labels.

This process is similar to putting a puzzle together. For that reason, let's create an Access Strategy using Groups, Roles, and Labels as the pieces.

Available Groups:

• APAC-employees
• US-employees
• Engineering
• gcp-db-admins
• kubernetes-admins

Available Resources:

• US located EC2 instances
• APAC located EKS clusters
• US located GCP Cloud PostgreSQL databases
• US located RDS PostgreSQL databases

Use the groups and resources to create a role that maps the correct groups to the correct resources through label mapping.

Puzzle: Create a role that grants US located database administrators access to US located GCP PostgreSQL databases.

Answer Template:

Role name: gcp-db-admins-us

Groups:
gcp-db-admins
US-employees

Labels:
Cloud: GCP
Type: postgres
Region: US 

Note: This is not formatted as a functional yaml example.

Conclusion

Access strategy is dynamic, and doesn’t always follow a singular path. Your organization’s structure, use cases, and security philosophy ultimately dictate the direction of your Access Strategy.

I hope this thought exercise has lifted the veil of the daunting complexity often associated with access strategy, and has sparked new ideas for how to begin mapping out an improved access strategy that reduces your organization’s exposure to risk.

TL;DR: The three main points to take away form this blog are:

• Starting somewhere with Access Design is better than not starting at all.
• Nothing is set in stone; Access Patterns can be changed.
• Inventorying answers most access questions.

If you are ready to dive into how Teleport can solve for many of the issues discussed in this blog, please continue on to the associated topics listed below:

• Kubernetes RBAC Tips
• RBAC with OpenSSH
• RBAC Best Practices
• How to Setup AWS SSO with Okta SAML