Role-Based & Attribute-Based Access Control

📘

Deeper Dive

For more in-depth information, check out our detailed documentation on the following topics:

Role-Based Access Control

👍

Need any help?

If something in this tutorial isn't working as expected, feel free to contact our support team via Slack.

Below is a text-only guide for users based on the above video

What is an Access Role?

Access roles give companies the ability to limit human or machine access rights, and Akeyless offers a very powerful and granular role-based access control system that follows least-privileged access principles.

You can associate authentication methods with access roles, and you can create as many roles as you want, each with its own set of permissions.

Additionally, with attribute-based access control you can set policies for authentication methods associated with a role to give specific groups or users within those groups authorization to use that role.

The sub-claims can be something like a group name, an email address, or some other identifier to limit access to a specific user or a number of users for the given authentication method. This adds an extra layer of granularity for true least-privileged access with Akeyless.

In the below example, we will walk through 3 layers of the organization:

1. Akeyless Admin: Give access to Akeyless to the Dev Team Lead
2. Dev Team Lead: Gives access to Dev Team members
3. Dev Team: Log in and use secrets to access their tools

Creating an Access Role with RBAC + ABAC via the UI for Dev Team Lead

Here, we are the Akeyless Admin for the corporate account. In the console, we can see our SAML authentication method which was already created in order to give our team access to Akeyless through our Identity Provider.

Now we need to create an access role for the Authentication Method in order to access secrets and other resources. Go to Access Roles in the left side menu, click “New.”

We will create this role for the backend team lead and click “Next.”

Now we’re going to associate the authentication method we want with this role, so we’ll choose the Backend Dev auth method and then we will add a sub-claim to ensure only the team lead can access resources.

📘

What are sub-claims?

For some of the Auth Methods, such as OIDC/SAML, you can restrict the authorizations of the associated role to these specific claims or attributes (ABAC). In other words, only clients whose tokens contain these sub-claims, in the case of JWT/OIDC, or attributes, in the case of SAML, will be allowed to access Akeyless resources based on the rules defined in the role.

We will add the email sub-claim and add the team lead’s email address. That means that anyone trying to log in using this authentication method without this specific email address will not have access to any actual resources in Akeyless. Click “Save” then “Next.”

Now we’re going to define the rules that give the authentication method the ability to do specific actions with specific types of resources. In this case, we’re going to give access to all the options including Items, Access Roles, Auth Methods, and Targets. And we will only grant that access within the backend folder inside this Akeyless account. This will in essence grant the team lead admin access, but only within the /backend folder and any sub-folders.

Logging Into Akeyless from the Team Lead View

Let’s log into the account now and see what access our team lead has. First we go to the console and choose the SAML option.

That brings us to Okta to sign in as that is the Identity Provider being used by the organization.

Once signed in we can see the team lead is only granted access items inside of the backend folder with no ability to see anything outside of that folder based on the rules we set earlier. The team lead has the ability to create and delete secrets inside that folder as well. However, the team lead will not have the ability to view or create secrets in the main folder of the organization one layer above.

Giving the Dev Team Access

Our team lead also has developers on the team that need access to Akeyless, but their access is going to be limited to being able to list and read the secrets only. So the team lead creates another Access Role for the backend devs.

They connect it to the same authentication method as before, but our sub-claim now points to a group within Okta called Backend_Dev_Group. That group includes Mary, one of the devs on the team. With this sub-claim, Mary and anyone else in that group can access Akeyless.

As before, the team lead chooses the rules for the team. In this case, we are only giving read and list capabilities for items inside the backendTeam folder which is a sub-folder of the backend folder.

Logging in as a Dev Team Member

Once that’s done, we can now grab the same authentication method ID and log into the console again, but this time as Mary.

Mary is redirected to Okta and logs in. We can see Mary has access to the backend folder, and the backendTeam folder within, and she can read secrets.

However, she cannot actually create a secret, even in this folder.

And that is how you can create strong role-based and attribute-based access controls within Akeyless to ensure all of your organization's users only have access to exactly the resources they need within Akeyless and nothing more.