Cluster Name

akeylessUserAuth:
  clusterName: 
  initialClusterDisplayName:

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.

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.

Encryption Key

To choose an exisitng Encryption Key to encrypt your Gateway configuration, you can provide the full path to your key using the following setting configProtectionKeyName.

By default, the Gateway configuration is encrypted with your account's default encryption key.

🚧

Note:

This key can be determined on cluster deployment only, and cannot be modified afterward.

Customer fragment

If your Encryption Key works with Zero Knowledge, provide a JSON containing your Customer Fragment:

akeylessUserAuth:
  configProtectionKeyName: /KeyName
customerFragments: |
  {
      "customer_fragments": [
          {
              "id": "cf-xyzxyzxyzxyzxyzxyz",
              "value": "xxxxxxxxxxxxxxxxxxxxxx"
          }
      ]
  }

TLS Configuration

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:

TLSConf:
  akeylessWebUI: true
  vaultProxy: true
  akeylessAPIServices:  true
  configurationManager: true
  #minimumTlsVersion can be one of the following <TLSv1/TLSv1.1/TLSv1.2/TLSv1.3> 
  minimumTlsVersion: "TLSv1.2"
   tlsCertificate: |-
     -----BEGIN CERTIFICATE-----
     -----END CERTIFICATE-----
   tlsPrivateKey: |-
     -----BEGIN RSA PRIVATE KEY-----
     -----END RSA PRIVATE KEY-----

Defaults Gateway Settings

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 defaultSamlAccessId or defaultOidcAccessId.

Set the default Encryption Key that will encrypt all items created on this Gateway using the setting defaultEncryptionKey with the full path to your Encryption Key in Akeyless.

Set the default location secrets created by this Gateway will be stored within your Akeyless account using defaultSecretLocation setting with a path to store your secrets.

🚧

Note

Make sure your Gateway default Authentication Method has read permission to access your Encryption key, as well as create permission on the desired location to save your secrets.

defaultsConf: {}
   defaultSamlAccessId: <SAML Access ID>
   defaultOidcAccessId: <OIDC Access ID>
   defaultEncryptionKey: </Path/to/Key>
   defaultSecretLocation: </Path/To/Save/Secrets>

Cache Configuration

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

enable the 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.

cachingConf:
  enabled: false
   cacheTTL: 60
  proActiveCaching:
    enabled: false  
     minimumFetchingTime: 5
     dumpInterval: 60

Working With K8s Secrets

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:

• admin-access-id
• admin-access-key
• allowed-access-ids
• customer-fragments
• akeyless-api-cert.crt
• akeyless-api-cert.key
• admin-certificate (base64)
• admin-certificate-key (base64)

🚧

Note:

Providing any of those settings using an existing K8s secret, make sure that the corresponding parameters are left empty in your values.yaml file.

existingSecret:
#  - admin-access-id,
#  - admin-access-key
#  - allowed-access-ids
#  - customer-fragments
#  - admin-certificate (base64)
#  - admin-certificate-key (base64)
  tlsExistingSecretName: 
  # - akeyless-api-cert.crt (base64)
  # - akeyless-api-cert.key (base64)

Restrict Gateway Access

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 AccessIDs

akeylessUserAuth:
  # adminAccessId is required field, supported types: access_key,password or cloud identity(aws_iam/azure_ad/gcp_gce)
  adminAccessId: 
  # list of allowed access-ids from your account that can login to the Configuration Managment WebUI
  allowedAccessIDs: []
  restrictServiceToAccessIds:

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.