Path Templating for Bulk User Access

📘

Deeper Dive

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

Sub-Claims

👍

Need any help?

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

What is Path Templating and why use it?

There are generally two ways of granting human user access to resources in Akeyless. The first is granting each individual employee their specific access to secrets, targets, and other resources.

The second option is to create a template for granting dynamic access to users based on their specific user attributes. This is called Path Templating. For example, if I have an account with a specific group of sub-claims, I may want to grant access to create or read secrets within a user's unique path. Path templating allows us to do this for everyone at once, rather than manually giving specific access to each individual user and role.

In this example, we will be demonstrating how the IT admin will be able to grant all backend team members and frontend team members read access to secrets in their personal folders. Moreover, we will give create access to secrets only to the backend team members within their personal folders.

How to set up Path Templating in Akeyless

Starting at this from the administrative side, we have Laura, the IT Admin, who already uses Okta in her organization as the identity provider. Looking at the Okta account, we can see Alex and Mary in the organization.

Each profile has specific attributes; in this case, we want to use the Group name, such as Backend_Dev_Team, and displayname, such as "alexg", as part of the path which determines how the person is granted access to their secrets.

Looking at our Akeyless account we currently have two different folders, one for the backend dev team and one for the frontend. The backend dev team path has a folder for Alex and the frontend path has a folder for Mary which mirrors the Okta setup. This ensures that their access is restricted to their specific paths. For instance, we can configure it so that Alex can see and read secrets in his path, but nothing else.

With the initial setup, we can see we have access roles set for both the backend and frontend teams with separate sub-claims.

To simplify this, we can use a single access role with path templating to give access to both. We start by creating a new role called dev-team.

We then associate our auth method, including the groups and displayname sub-claims. Then we add our rules.

By adding the groups and displayname templates in the Access Path section, we are dynamically enabling specific path access for all users logging in with that authentication method.

Next, we log in with Alex and his SAML authentication method and credentials. We can see he only has access to the Backend_Dev_Team path and inside only his folder with the secret.

We can also log in with the same authentication method, but this time with Mary’s credentials. We see she only has access to the Frontend_Dev_Team path and her folder inside.

Laura has also determined that she needs to give the backend team access to create new secrets. This can be done by going back to the access role and adding a new rule. This time, we are not using the full path as a template. Instead, we create the path with /Backend_Dev_Team/displayname. Therefore, only those within the Backend_Dev_Team path will have access to create secrets, and only in their path.

Going back to Mary's account, let's refresh the page and see if she can create a secret. We see that she still cannot.

However, when we log into Alex's account, we can see that he can successfully create a secret in his folder.

To recap, we learned how to use path templating to give different types of access permissions to multiple users at once from just one access role rather than creating separate access roles for each user or each group of users.

📘

Note about sub-claims

If your sub-claims for this Authentication Method are specific to the User (in this example displayName=alexg etc), you will have to also edit the sub-claim for new users that are added. If you only use a sub-claim for groups, or no sub-claim at all, you won't need to edit the sub-claim when a new user is added as it will fit the sub-claim requirements.