- name: CLUSTER_URL
Each Gateway instance is uniquely identified by combining the Admin Access ID Authentication Method and the Cluster Name.
It means that changing the Admin Access ID or the Cluster Name of your Gateway instance will create an entirely new Gateway instance, and it will not retrieve the settings and data from the previous Gateway instance.
That’s why we recommend setting up a meaningful Cluster Name for your Gateway cluster from the very beginning. By default, your cluster name is defaultCluster.
To do that, you can set the
clusterName="meaningful-cluster-name" field as part of the Gateway deployment.
In addition, to set in advance the Cluster URL, you can set the
CLUSTER_URL under the
env section as an environment variable.
You can also provide a custom display name for the Gateway Instance using the
initialClusterDisplayName variable, which is arbitrary. This name can be changed in the Akeyless Console after the Gateway is installed.
To choose an existing Encryption Key to encrypt your Gateway configuration, you can provide the full path to your key using the following setting
By default, the Gateway configuration is encrypted with your account's default encryption key.
This key can be determined on cluster deployment only, and cannot be modified afterward.
You can also configure TLS settings using the Web interface of the Gateway Configuration Manager.
We strongly recommend using Akeyless Gateway with TLS to ensure all traffic is encrypted at transit.
Please note that when you're enabling TLS, you must provide a TLS certificate and a TLS Private Key.
To set the relevant service to use TLS and the minimum TLS version that will be used by default, set the following:
#minimumTlsVersion can be one of the following <TLSv1/TLSv1.1/TLSv1.2/TLSv1.3>
#excludeCipherSuites: Comma separated list of cipher suites to exclude (e.g. "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA")
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
You can also configure the default settings using the Gateway Configuration Manager UI:
Default SAML or OIDC
Access ID to be used for logging in to the Gateway Console using the authentication method
defaultOidcAccessId. To authenticate directly against your Gateway, you can add this
AKEYLESS_OIDC_GW_AUTH variable under the
Set the default location secrets created by this Gateway will be stored within your Akeyless account using the
defaultSecretLocation setting with a path to store your secrets.
Make sure your Gateway default Authentication Method has
readpermission to access your Encryption key, as well as
createpermission on the desired location to save your secrets.
- name: AKEYLESS_OIDC_GW_AUTH
defaultSamlAccessId: <SAML Access ID>
defaultOidcAccessId: <OIDC Access ID>
To work with CBA flow for users login, first set your users' DNS records with the cert authentication subdomain
auth-cert.akeyless.io to point to your Gateway IP address.
And set your deployment with the following parameters:
TLSConf section, enable the
enableSniProxy setting, and under the
defaultsConf section provide your Certificate auth method
## Default Certificate Access ID to be used for initial WebUI login
defaultCertificateAccessId: <Access ID>
You can enable caching of secrets and periodic backup of cached secrets, It is also possible to configure caching in the Gateway Configuration Manager after the Gateway is installed
cachingConf setting and set the
cacheTTL value in minutes to configure the TTL for a secret that should be kept in the cache.
To work with proactive caching set the
proActiveCaching to true and set the
minimumFetchingTime to config the Gateway to update secrets in the cache if they are older than the specified value with the
dumpInterval to set the time in minutes between the two consecutive backups.
To provide the settings of your Gateway deployment directly from your local k8s secrets store, you can set the following settings with the corresponding
K8s Secrets names:
Providing any of those settings using an existing K8s secret, make sure that the corresponding parameters are left empty in your
# - akeyless-api-cert.crt (base64)
# - akeyless-api-cert.key (base64)
To restrict access to Gateway services, you can specify exactly which
AccessIDs will be authorized and will be served by the Gateway. For example, if you want to achieve complete segregation using Zero-Knowledge Encryption across different teams or applications, you can also set their
AccessIDs to ensure only they will be able to get service from the Gateway that holds their Fragment. To set the list of users the Gateway services will serve, set the
restrictServiceToAccessIds setting with a comma-separated list of
# adminAccessId is required field, supported types: access_key,password or cloud identity(aws_iam/azure_ad/gcp_gce)
# Configure this list to add one or more allowed access to this GW, with the specified permissions and sub-claims.
In the above example, in addition to your Gateway admin lists, you are limiting the audience of users that your Gateway will serve. Other
AccessIDs will not be able to get service from your Gateway.
In some environments where an IP address must be whitelisted, to pull Akeyless official artifacts as part of your Gateway deployment, uncomment the
fixedArtifactRepository: "artifacts.site2.akeyless.io" setting in your chart:
Updated 2 months ago