Automatic Migration


Automatic migration allows to import static secrets into Akeyless from other secrets management platforms. This feature is available as part of the Akeyless Gateway.

Supported platforms

Currently, you can import static secrets from 4 platforms:

General configuration

The following options are available when importing secrets from other secrets management platforms:

  • Name. This is an arbitrary name for the migration object itself. Use something meaningful.
  • Target location. This is where the secrets are created in Akeyless. For example, when importing secrets from Kubernetes, it may be a good idea to put them all under /kubernetes path. Or, if there are multiple Kubernetes clusters, under /kubernetes/staging or similar. After the migration is complete, new secrets will be available under the specified path. If not provided, the secrets will be created in root / folder of your account.
  • Protect secrets with the following key. This is a required field that allows to choose which encryption key to use to protect the imported secrets. This is the property that allows you to use Zero Knowledge Encryption.


If there are existing secrets under Target location, their values will be replaced in case of conflict. This can happen if you run the same migration multiple times (e.g. every day), or if you leave Target location field blank, and a new secret has the same name as an existing one.


Before getting started, make sure that the platform where the secrets are stored is accessible over the network from the Akeyless Gateway server. Depending on the deployment, it might mean adding Akeyless Gateway IP address to a security group or a firewall.


Akeyless supports secrets migration from Kubernetes Secrets using Kubernetes API. 3 types of authentication are available:

  • Bearer token
  • Certificate
  • Password

For any Kubernetes authentication method, the following options are available:

  • Cluster URL endpoint - This is the URL of Kubernetes API server (including schema and port, for example
  • Cluster CA Certificate - Optional Certificate Authority data in case the server is accessed over HTTPS. This value can be found your ~/.kube/config file, under certificate-authority-data: property of the cluster with the existing secrets. There is no need to base64 decode this value. It should be used as-is. If no value is provided, an insecure connection is used, which is discouraged.
  • Namespace - Use this field to import secrets from a particular namespace only. By default, the secrets are imported from all namespaces.
  • Skip Control Plane Secrets - This option allows to avoid importing secrets from system namespaces (the ones that begin with kube-). If you are certain you need to import secrets from all namespaces, uncheck this option.


When choosing an authentication method to access your Kubernetes cluster, make sure that the credentials you provide have sufficient access to list and get secrets in the namespace(s) you selected.

Bearer token authentication
For servers that support Bearer Token authentication, use Token authentication method. Make sure that this token is not expired when used.

Certificate authentication
For servers that use client certificates for authentication, use Certificate authentication method when creating a new migration.

Password authentication
For servers that allow username/password authentication, use Password authentication method.

AWS Secrets Manager

To import secrets from AWS Secrets Manager, you need to provide access credentials of a user with sufficient permissions to get all secrets. The required configuration includes AWS Access Key ID, AWS Secret Access Key, and an AWS region.

Azure Key Vault

To import secrets from Azure Key Vault, you need to create an Azure AD app with a service principal. Access credentials, as well as the unique Key Vault name, must be provided in the configuration dialog.

Hashicorp Vault

To import secrets from Hashicorp Vault into Akeyless, you need to create a new access token, or use an existing one with sufficient permissions. You also need to provide a full URL of Vault API server.

For migration from Hashicorp Vault Enterprise, configuration of namespaces is available. Namespaces is a comma-separated list of namespaces which need to be imported into Akeyless Vault. For every provided namespace, all its child namespaces are imported as well.

Example: nmsp/subnmsp1/subnmsp2,nmsp/anothernmsp

Akeyless supports migration from kv storage engine of both version 1 and version 2. For v2 migrations, in case of multiple available versions, only the current version of a secret is imported.

Did this page help you?