Access Roles & RBAC
Akeyless RBAC follows the least privilege principle to limit access rights for machines/human users to the bare minimum of permissions they need to perform their work.
We associate specific clients with a certain Authentication Method to an Access Role to increase operational flexibility. The user can define any number of roles with permissions per each role.
Access Roles can be configured to grant permissions on Secrets & Encryption Keys, Targets, Authentication methods and Access Roles, you can also control user access to audit logs, analytics, Gateways settings and Secure Remote Access information.
To set permission for a user to work with any item in the Platform, an appropriate Access Role must be assigned to the Authentication Method that represents this user. By default, users don't have any permissions in Akeyless unless explicitly granted.
To Associate an Authentication Methods with a role from the Akeyless Command Line Interface (CLI) run the following commands to create an API Key:
akeyless create-auth-method --name client1
Create a new access role:
akeyless create-role --name role1
Set all the authentication methods associated with a role to access all Secrets & Encryption Keys under /path/to/folder/ with read, create, and update permissions:
akeyless set-role-rule --role-name role1 --path "/path/to/folder/*" --capability read --capability create --capability update
To set the role with access for additional items type like Targets, Authentication Method, or Access Roles, you can simply set the rule-type
inside the command:
akeyless set-role-rule --role-name role1 --path "/path/to/folder/*" --rule-type target-rule --capability read --capability create --capability update
akeyless set-role-rule --role-name role1 --path "/path/to/folder/*" --rule-type auth-method-rule --capability read --capability create --capability update
akeyless set-role-rule --role-name role1 --path "/path/to/folder/*" --rule-type role-rule --capability read --capability create --capability update
Despite the fact that users do not have access to items unless granted explicitly, to protect sensitive items from access, you can deny all the authentication methods associated with a role to access the relevant item, for example /path/to/folder/topSecret:
akeyless set-role-rule --role-name role1 --path /path/to/folder/topSecret --capability deny
Add client1 to the role1, so client1 will be able to access all items under /path/to/folder/ apart from /path/to/folder/topSecret:
akeyless assoc-role-am --role-name role1 --am-name client1
For example, using Akeyless Console, you can configure an access role of "Jenkins environment" with API-key auth method ("Client1"), setting specific permissions per different paths.

Permission Types
Akeyless has six main permission types, that can be assigned to specific items, folders, or entire accounts.
The built-in admin role has full access to all parts of the accounts.
Note:
It is considered a best practice not to use an API key as the authentication method associated with your Admin role. We highly recommend you select one of the other available Authentication Methods.
The existing permissions are as follows:
- List: Allows a user to list the items available under an authorized path.
- Read: Allows a user to read the items available in an authorized path.
- Create: Allows a user to create new secrets and items in an authorized path.
- Update: Allows a user to update existing secrets and items in an authorized path.
- Delete: Allows a user to delete existing secrets and items in an authorized path.
- Deny: Allows a user to deny any permission to other users in their authorized path.
Permission Hierarchy
Some Akeyless permissions include others in them. For example,
list
is included under all other permissions, anddeny
has a complete override over any other permission.
Access Roles Syntax
In general, you can set an Access Role to a specific item only:
In this example we will create a role that grants read
permission to mysecret
, which is located under /foo
folder:
akeyless set-role-rule --role-name role1 --path "/foo/mysecret" --capability read
To provide access to all secrets with a well-defined prefix:
In this example we will create a role that grants read
permission to all secrets that start with devops-
prefix, which are located under /foo
folder:
akeyless set-role-rule --role-name role1 --path "/foo/devops-*" --capability read
In addition, a +
can be used to denote any number of characters bounded within a single path segment:
akeyless set-role-rule --role-name role1 --path "foo/+/+/bar/*" --capability read
This Access Role will permit reading secrets under those folders path:
foo/any/folder/bar/*
, foo/other/folder/bar/*
, etc.
Multiple rules
If you wish to apply multiple rules to your role in one command, you can use a JSON
file using -f
or --file
parameter to the command, that will lead to a JSON file in the following way:
akeyless set-role-rule --role-name role1 --file-rules path/to/file.json
The JSON file structure should be as follows:
{
"secret/foo": [{
"rule-type": "item-rule",
"capabilities": "[read, list]",
"ttl": "30"
},
{
"rule-type": "role-rule",
"capabilities": "[read, list]"
}
],
"secret/bar": [{
"rule-type": "target-rule",
"capabilities": "[delete, list]"
}]
}
Where the relevant Akeyless paths, e.g secret/foo
and secret/bar
correlate with the --path
parameter, the rule type with the rule-type
key, and the capabilities with the capabilities
key that you would attach to a single rule command as described above.
View As
To verify the settings of your Access Roles, you can use the Impersonate As feature inside the Akeyless Console. Admins can validate and explore what kind of access they grant to clients.
Click on your account logo on the top right corner of your console, and select Impersonate As.
On the dialog, choose from the drop-down menu and existing Authentication Methods. Where needed, provide the relevant Sub-Claims as well to validate the level of access the relevant audience have.
Updated 2 months ago