Sub-admins

Preface

Akeyless provides a powerful RBAC model. It allows to delegate a part of the account owner’s permissions to other users.

Akeyless Vault stores all objects (secrets, keys, roles, auth methods, etc.) in a virtual filesystem. It allows to organize everything based on the domain each item belongs to. For example, an organization may have Dev, Operations and Security departments, each having its own set of secrets, roles and auth methods.

In such situation, it would make sense to have a person responsible for every department. For example, 3 users (3 auth methods) can be designated to rule their own departments: /dev/director, /ops/lead and /security/ciso.

📘

The following screenshots use “List View” on “Access Roles” and “Auth Methods” pages.

To grant each one of these users full control over their department, 3 separate roles should be created, for example /dev/director, /ops/lead and /security/ciso.

📘

Names used above are the same for convenience. Any valid names can be used. It is easier though to manage roles, items and auth methods in such way.

Each role should be associated with the corresponding auth method to grant required permissions.

Each user’s power depends on a set of permissions granted to them. There are 3 permission categories:

  • Secrets and keys
  • Access Roles
  • Auth Methods

In case of our organization, it would make sense to grant every leader full access to their departments.

/dev/director can now do any operation inside /dev/* folders, such create new secrets, delete keys, update roles or setup new auth methods. They can even create new, limited users, that can only have a subset (but never a superset) of their own abilities.

If /dev/alpha/alpha-lead tries to create a new role /dev/alpha/intern with create permissions under /dev/alpha/*, they will fail: note that the original /dev/alpha/alpha-lead does not have create permissions. Such team leads can then create read-only users for CI systems, automation tools or users in their teams.

Logs and analytics

  • Each role can be granted “Audit Logs” and “Analytics” permissions. These capabilities are not limited by any path/department.
  • Any role with “Audit Logs” permission is able to view all audit logs with their own Access ID.
  • Any role with “Analytics” permission is able to view reports about their own Access ID.
  • Users granted admin permissions can view all logs and see all reports.

FAQ

Do I have to use the same folder structure for every category?
No, but we think it makes things easier. Otherwise it is harder to keep track of roles, auth methods and their permissions.

Can a limited user somehow escalate their permissions?
No. Even if a user is granted “create role” permissions, they cannot create a role with capabilities that they themselves don’t have.

Do I have to create “Deny” permission if I don’t want a user access to some path?
No. By default, a role has no permissions, and is not able to do anything. Any permission must be explicit. “Deny” permissions are good for cases where a user has access under a particular path (/dev/ci/*), but is forbidden from seeing a specific item or sub-path (/dev/ci/jenkins).

Can I only grant role management permissions to human users?
No. Any client (human or machine) can be granted any permission. It is possible to automate role/user management with a limited scope.

Can a user have different permissions under “Roles” than under “Secrets and Keys”?
Yes! It is possible to grant different levels of access to different parts of Akeyless Vault. A user can be able to create and delete secrets, but it doesn’t mean that they can do the same for auth methods.


Did this page help you?