Best Practices

In this article, we are going to map some of Akeyless best practices related to both performance and security.


Superuser - The user who signed up for Akeyless and owns the account.

RBAC - Akeyless Role Based Access Control.

CSP IAM - Cloud Service Provider Identity and access management.

Customer Fragment - Zero Knowledge Akeyless unique encryption patented technology.

SRA Bastion - Akeyless Secure Remote Access Bastion.

Akeyless Vault platform

  • Do not run as a superuser for general purposes. Akeyless superuser should generate a very strong and long password. The superuser should be used to set up the system initially, particularly for setting up the selected admin users which will be part of your admin role, those admin users will create the authentication methods so regular users would be able to authenticate.

  • Avoid API Key Authentication on production - Due to secret zero problem and management challenges, on production, Universal Identity should be used instead for on-premise environments, or any CSP IAM on cloud environments for workloads or automated services, as well SAML or OIDC for human access.

  • Authentication Methods - Shared authentication methods such as SAML, OIDC, LDAP, IAM, JWT, or K8s. should be used with sub-claims on role association, to avoid mistakes and overriding existing access roles.

  • Access Roles (RBAC) - In general, regular users do not have permission to change their own Access Role or Authentication method settings. Make sure your Access Roles are not granting regular users with permissions to view or to create neither Access Roles or Authentication methods. In addition, avoid creating multiple different Access Roles with a single path, instead, create an access role for multiple paths.

  • Audit & Analytics - On access roles, it's recommended to let your users view their own analytics and logs, rather than providing them wider permissions to view the entire audit logs and analytics of your account.


  • Storing item - Items location inside Akeyless Vault should not be saved on the default root path i.e. /. The recommended mode is to create those items under the relevant tree folders which describe the exact unit in your organization. This will enable easier and clearer tenants to manage.

  • SSH certificates - Should not be set with * on the principals field, this field should be utilized for special use cases where your users need special permissions. In addition, SSH certificates should be used with a list of allowed users who will be able to log in using those certificates.

  • Dynamic Secrets - Should be used and set while following the Principle Of List Privileges (PoLP). Each dynamic secret has its own permission profile, which will determine the level of access for your temporary users.
    For E.g. Databases Dynamic secret should be used with the minimum permissions for your users based on the creation statement, where you should limit the access to a specific database and table.

CREATE USER '{{name}}'@'%' IDENTIFIED WITH mysql_native_password BY '{{password}}' PASSWORD EXPIRE INTERVAL 30 DAY;GRANT SELECT ON <DATABASE NAME>.<TABLE_NAME> TO '{{name}}'@'%';
  • Rotated Secrets - Should be used as a break glass admin static credentials, which should rotate strong users' passwords automatically. Mostly for your super users, which their passwords should be rotated automatically.

  • Targets - In order to save time during Dynamic and Rotated secrets creation, as well as avoid using your privileged user credentials often, you can create Targets.
    Those items should not be shared with regular users, while those who need to use the Targets items, can have only 'list' permissions to use them.

Did this page help you?