Path Templating for Bulk Permission Enforcement

📘

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?

Some organizations might have a user structure within their identity provider where access is given to secrets within specific paths based on some specific attribute such as a user's name and the group they are part of. This can be any structure, but we are using /group/user for this example.

For example, say you are the IT Admin and have users on different teams, such as the "Backend Dev Team" and "Frontend Dev Team", each with 10 engineers, and you want to enable read access to secrets specific to each of them that would show inside their Akeyless account. Instead of giving each user specific permissions to read secrets one by one in a manual fashion, you can give access to all those engineers with one simple permission policy that is used for each user within their group or team and delegates that permission based on variables.

Here is what giving each user permissions one by one would look. This would mean as we add users, we also have to add their permissions manually.

And here is what it looks like when you use Path Templating which gives each user the same permissions, but based on their /group/user template.

So now you see that regardless of what group or what user is added and when, they will get their access and permission automatically without the need to manually add that user's access.

Mirroring your Identity Provider within Akeyless

As noted, within your Identity Provider, the IT Admin might already have a nice structure. In our example that would mean "Backend Dev Team" and "Frontend Dev Team" groups with Alex and Mary inside the "Backend Dev Team" and Jeremy inside the "Frontend Dev Team".

The idea is that inside Akeyless, you simply mirror that structure and automatically give access to current and future users. For example, /Backend_Dev_Team inside the Identity Provider shows up inside Akeyless as /Backend_Dev_Team/.

And that would mean that we would give our engineers, Alex and Mary, mirroring paths as well. For example, /Backend_Dev_Team/alexg and /Backend_Dev_Team/maryb.

👍

Future Users

Within this structure, you don't need to know who your next user is. If you have a new user, you simply create a secret inside their path in Akeyless and that user will automatically be able to see the secret in their account according to the path template.

Setting Path Templating Rules

To set your Path Templating rules, simply go to the Access Role that your Authentication Method is associate with.

Click the "Add" button to give access to "Secrets & Keys" as follows. Keep in mind that this Path Template is based on what was set inside of the Identity Provider. That means the Identity Provider has a Group attribute called groups and a User attribute called displayName. The IT Admin will decide the Path Template for the organization.

👍

Access to other resources

You can use the same Path Templating shown here for "Access Roles", "Auth Methods", and "Target" as seen in the image above.

User Access

Once you set the Path Templating rules, users will simply be able to access their secrets and resources from their account based on the permissions given. In this case, the IT Admin gave Alex read access to only secrets & keys within his path, so that is what he will see in his account.

Note that Alex can only see the "Backend Dev Team" folder.

Within that, he can only see his own folder with his displayName.

And within his folder, he can see the secrets.

And the same applies to Mary and Jeremy. When they each log into their accounts, they will automatically see only the Group folder and User folder within it and any secrets inside that path.

More than that, if a new user, let's say Sara from the "Frontend Dev Team" is added to the organization, she could log into her account and see those folders for just her. And when a secret is created inside that path, she will see it and be able to read the value of it.

📘

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.