Configure Secrets Management
Some configuration is needed to set up the Akeyless Gateway before you can manage secrets.
Prerequisites
Install the ksctl CLI on a remote workstation to issue these commands.
Ensure that there is public network connectivity to Akeyless SaaS Core Services.
Configure Akeyless Gateway
In the CipherTrust Manager application, as an application administrator such as
admin
, rotate the authentication key to an ECDSA key.Sign in to Akeyless account using the Access ID and Access Key obtained from step 1.
Navigate to Users & Auth Methods > New > Oauth2.0/JWT.
Note
It is recommended to delete the User-Admin role, as it is not required. The new Oauth 2.0/JWT method controls Akeyless permissions for the CipherTrust Manager users.
Provide a name for the authentication method. Example, test-am.
(Optional) Change default value of JWT TTL (in minutes) as required. It controls the expiry time for the Akeyless token issued for the CipherTrust Manager users.
Click Next.
Configure the authentication method either using the JSON or Gateway option.
Select the JSON tab.
Enter the Public key JWKS in the JWKs JSON field. See GET Public key JWKS to learn how to get public key JWKS.
Example
{ "keys": [ { "crv": "P-256", "kty": "EC", "x": "b5y6sdqZpB5HcciwP_Fl0K4s3czQFG6tZwmXLAJxGH4", "y": "OKrI2Gg0xkBN1hJTO1Ai7uRBmXiYbm18qgWJHw1zW-c" } ] }
Enter the value for Unique Identifier. For example, "sub".
Note
Ensure that the CN of the web interface server certificate is added in DNS Hosts with the IP address of 172.30.0.203 in the CipherTrust Manager application. See Configuring DNS Hosts.
Select the Gateway tab.
From the Gateway drop-down list, select defaultCluster or any other gateway configured for connecting to the CipherTrust Manager application.
Enter the URL in the JWKs URL field.
The URL depends on the web interface certificate configuration done in CipherTrust Manager.
- If the web server certificate is changed, use
https://CN:8443/v1/auth/jwks.json
as URL, where CN is the CN of the server certificate. - If no changes were done in the web server certificate, use the default URL
https://web.ciphertrustmanager.local:8443/v1/auth/jwks.json
.
- If the web server certificate is changed, use
(Optional) Upload the CA certificate in the Certificate field.
Note
The CA authority that signed the web interface server certificate must be trusted by Akeyless Gateway. By default, the default root CA of CipherTrust Manager is trusted by Akeyless Gateway.
If your web interface server certificate is self-signed or signed by an external CA, then you need to upload the certificate to Akeyless Gateway.
For more details, see Akeyless Online Documentation.
Enter the value for Unique Identifier.
Click Finish.
Note the Access ID of the authentication method. This will be required to configure Akeyless connection in CipherTrust Manager.
Associate the authentication method created above to an existing Access Role or create a new Access Role. See Akeyless Access Role.
Note
You must associate the new authentication method to at least one Access Role, to determine the Akeyless console permissions of CipherTrust Manager users. These steps set up permissions for all CipherTrust Manager users to manage secrets. You can adjust settings on both CipherTrust Manager UI and the Akeyless console to restrict secrets management to fewer CipherTrust Manager users, if desired.
See Akeyless Online Documentation for more information on Akeyless Access Roles.
In the CipherTrust Manager application, set SSO Access ID to access ID of the Oauth 2.0/JWT authentication method created above. See Set SSO Access ID.
Manage customer fragments.
Initially, by default, CipherTrust Manager generates a customer fragment that is used to create protection keys on Akeyless Gateway. Apart from this default customer fragment, you can also create new customer fragments.
Below is a sample to create a customer fragment:
{"name": "test CF", "description": "User generated Customer Fragment"}
Caution
Creating or deleting a customer fragment triggers an Akeyless Gateway restart across all the nodes of a cluster.
Restart CipherTrust Manager services.
Navigate to Admin Settings > Services.
Click System Restart to restart all services and apply Akeyless configuration changes.
Once the CipherTrust Manager GUI is available again, log in as any user. Ensure that the Secrets Management tile is enabled.
If you click the tile, single sign-on takes place silently. CipherTrust Manager issues a token for Akeyless to verify with the ECDSA signing key and you are logged into the Akeyless console.
(Optional) Configure Akeyless Gateway for using CipherTrust Manager generated customer fragment to protect Akeyless secrets. See Configure Akeyless Gateway for Using CM Customer Fragment.
Create Akeyless account
This procedure provides you with a 90 day free trial to use the Akeyless Vault Platform, with settings that are suitable for CipherTrust Manager integration.
Navigate to
https://<ciphertrust_manager_hostname>/akeyless-console/
.The Akeyless Vault Platform interface is displayed.
Sign up using your email ID. You will receive a confirmation email to activate your account.
Open the confirmation email and click Activate your account.
The account credentials are displayed in a browser window.
Note down the Access ID and Access Key. These are the Super-Admin credentials. You can also save these credentials to a CSV file. These credentials will be used for future sign in.
Note
After a successful sign up, a new connection is created in the Connection Manager prefixed
autogenerated-akeyless-connection
.The connection ID is updated in the Akeyless configs API as the
gateway_connection_id
.This connection is created using the Gateway-Admin credentials. These credentials are fetched in the background while the user signs up and are used to create a connection.
Rotate Authentication Key
To rotate the CipherTrust Manager authentication key to an ECDSA key, run the following command as CipherTrust Manager Application Administrator, such as admin
. This key is used to sign and verify external JWTs.
ksctl tokens rotate-auth-key --type ecdsa --curve p256
Note
CipherTrust Manager version 2.15 onwards, for fresh installations, the default token authentication key type is ES256
. Therefore, key rotation is not required.
GET Public Key JWKS
To get public key JWKS:
ksctl tokens list-jwks
Response
{
"keys": [
{
"crv": "P-256",
"kty": "EC",
"x": "b5y6sdqZpB5HcciwP_Fl0K4s3czQFG6tZwmXLAJxGH4",
"y": "OKrI2Gg0xkBN1hJTO1Ai7uRBmXiYbm18qgWJHw1zW-c"
}
]
}
Akeyless Access Roles
To associate an authentication method with an existing Access Role:
Under Access Roles, select the desired role name.
In the right pane, click Associate.
From the Auth Method* drop-down list, select the Oauth 2.0/JWT authentication method created by you.
Click Save.
To create a new Access Role:
Under Access Roles, click New.
Provide a Name for the Access Role and click Next.
Click Associate to associate an authentication method with this Access Role. Use the Oauth 2.0/JWT authentication method created by you.
Click Next.
Click Add to add rules for Items, Access Roles, Auth Methods, and Targets. Add recursive rules to allow create, read, update, delete, and list operations.
Caution
Do not allow 'Deny' operation. This overrides all other operations permissions, and breaks the CipherTrust Manager integration.
Click Next.
For more details, refer to Akeyless Online Documentation.
Set SSO Access ID
To set the SSO access ID in CipherTrust Manager to access ID of authentication method created by you in Akeyless:
Log in to CipherTrust Manager GUI as an application administrator.
Navigate to Admin Settings > Akeyless Config.
In the SSO Access ID field, enter the Access ID of the authentication method created by you.
Click Save.
Warning
Do not edit the Akeyless Connection field. This is automatically populated with the autogenerated Akeyless Gateway connection.
Configure Akeyless Gateway for Using CipherTrust Manager Customer Fragment
To allow CipherTrust Manager users to use the CipherTrust Manager generated customer fragment for protecting Akeyless secrets:
Select Gateways > defaultCluster in the Akeyless console.
In the Gateway URL (Configuration) field, enter the CipherTrust Manager URL preceded by
https://
. Example,https://ciphertrust.mycompany.com
.Select the Access Permissions tab and click Add.
Provide a meaningful name in the Name field.
From the Auth Method* drop-down list, select the OAuth2.0/JWT authentication method created by you.
Click Next.
In Permission Settings, select the Admin (default) or Custom option.
Note
The Admin option grants permissions to all CipherTrust Manager users for using the customer fragment.
You can adjust permission settings to restrict customer fragment usage to fewer CipherTrust Manager users using both CipherTrust Manager UI and the Akeyless console. To do this with the Akeyless console, select the Custom option and enable Zero Knowledge Encryption.
Click Finish.
CipherTrust Manager users can now manage secrets, including protecting them with the CipherTrust Manager generated customer fragment.
Caution
To ensure static secrets, dynamic secrets, rotated secrets, and certificates are protected in the CipherTrust Manager root of trust hierarchy, we strongly recommend configuring a default protection key using the CipherTrust Manager generated customer fragment before beginning to create secrets.
To perform additional configuration, see Restrict secrets management or customer fragment access to certain users.
Configure a Default Encryption Key
Note
This configuration can also be performed through the Akeyless CLI, if set up for Gateway Admin access.
As a CipherTrust Manager Application Administrator, such as
admin
, obtain the CipherTrust Manager customer fragment by viewing the Akeyless configuration on CipherTrust Manager.ksctl akeyless config get
Retain the
customer_fragment_ids
value in the response.Example Response:
{ "gateway_connection_id": "aaeea264-e713-4075-b455-54e33a1a4518", "sso_access_id": "p-lx4mgbad23is", "customer_fragment_ids": [ "bbb34a30-7ca4-4717-a802-956b677f2a3d" ] }
Login as any user with secrets management permissions to the CipherTrust Manager UI, and click the Secrets Management tile to access the Akeyless console.
Create an encryption key associated with the customer fragment.
Navigate to Secrets & Keys.
Click New > Encryption Key > DFC.
Configure the following settings:
Provide a Name for the encryption key.
In the Type dropdown, select AES256GCM.
In the Customer Fragment dropdown, select the ID of the CipherTrust Manager Generated Fragment, obtained in step 1.
Click Finish.
Navigate to the Akeyless Gateway Configuration Manager, located at
https://<ciphertrust_manager_hostname>/akeyless
, as Super Administrator. Supply the Access ID and Access Key obtained in step 1.Select Defaults.
In the Default Encryption Key dropdown list, select the newly created encryption key.
Click Save Changes.
Control Which CipherTrust Manager Users Have Secrets Management and Customer Fragment Access
By default, any CipherTrust Manager user has access to Akeyless secrets management and can protect keys with the CipherTrust Manager generated customer fragment. If you want only a subset of users to access secrets this can be controlled with CipherTrust Manager groups, CipherTrust Manager domains and Akeyless Access Roles. If you want only a subset of users to use the CipherTrust Manager generated customer fragment, this can be controlled with CipherTrust Manager groups, CipherTrust Manager domains, and Akeyless Access Permissions.
Limit Secrets Management Access to a Group
Login to CipherTrust Manager as a user in the
Users Admins
oradmin
group.Create a group for secrets management.
Associate desired users to that group.
Login with your Akeyless administrative account at
https://<ciphertrust_manager_hostname>/akeyless-console/
.Navigate to Access Roles. Select the Access Role you initially created, or create a new one with rules to allow create, read, update, delete and list operations for Secrets & Keys.
Edit the associated Method in the first table. Add a Sub Claim corresponding to the CipherTrust Manager group,
cust.groups=<ciphertrust_manager_group_name>
. Click the checkmark to save.
Limit Customer Fragment Access to a Group
Note
This configuration can also be performed through the Akeyless CLI, if set up for Gateway Admin access.
Login to CipherTrust Manager as a user in the
Users Admins
oradmin
group.Create a group for secrets management.
Associate desired users to that group.
Login with your Akeyless administrative account at
https://<ciphertrust_manager_hostname>/akeyless-console/
.Navigate to Gateways and click the Access Permissions tab.
In the relevant Access Permission actions column, select Edit.
Note
This access permission was created as part of initial Gateway configuration and should display as Custom Permissions.
In the Allowed Users tab, add in a Claim corresponding to the CipherTrust Manager group,
cust.groups=<ciphertrust_manager_group_name>
. Click Save to confirm.
Limit Secrets Management Access to a Domain
Login to CipherTrust Manager as a user in the
Domain Admins
oradmin
group.Create a new domain or identify an existing domain for secrets management. Copy the ID of that domain.
Note
You can only use the domain ID for Akeyless Access Role configuration. You cannot use the domain name.
Add desired users to that domain.
Login with your Akeyless administrative account at
https://<ciphertrust_manager_hostname>/akeyless-console/
.Navigate to Access Roles. Select the Access Role you initially created, or create a new one with rules to allow create, read, update, delete and list operations for Secrets & Keys.
Edit the associated Method in the first table. Add a Sub Claim corresponding to the CipherTrust Manager domain,
cust.domain_id=<domain_id_value>
. Click the checkmark to save.
Limit Customer Fragment Access to a Domain
Note
This configuration can also be performed through the Akeyless CLI, if set up for Gateway Admin access.
Login to CipherTrust Manager as a user in the
Domain Admins
oradmin
group.Create a new domain or identify an existing domain for secrets management. Copy the ID of that domain.
Note
You can only use the domain ID for Akeyless Access Role configuration. You cannot use the domain name.
Add desired users to that domain.
Login with your Akeyless administrative account at
https://<ciphertrust_manager_hostname>/akeyless-console/
.Navigate to Gateways and click the Access Permissions tab.
In the relevant Access Permission actions column, select Edit.
Note
This access permission was created as part of initial Gateway configuration and should display as Custom Permissions.
In the Allowed Users tab, add in a Claim corresponding to the CipherTrust Manager domain,
domain_id=<domain_id_value>
. Click Save to confirm.
Allow Other Users Access to the Customer Fragment
In some cases, applications or users require access to the CipherTrust Manager customer fragment, without also requiring CipherTrust Manager user credentials. In these cases an application only needs to manage Akeyless secrets with Zero-Knowledge encryption, but doesn't need to access any other CipherTrust Manager functionality.
Prerequisites
A dedicated API key authentication method.
An Access Role associated to the authentication method, with Secrets & Keys rules to allow create, read, update, delete, and list operations.
Allow Access to the Customer Fragment
Login to the Akeyless console
https://<ciphertrust_manager_hostname>/akeyless-console/
with the Gateway-Admin account. Supply the Gateway Admin Access ID and Access Key.Navigate to Gateways and select the defaultCluster.
In the Gateway URL (Configuration) field, enter the CipherTrust Manager URL preceded by
https://
. For example, enterhttps://ciphertrust.mycompany.com
. Click the checkmark to confirm.Click the Access Permissions tab.
Click New.
Enter a meaningful Name, select the desired authentication method for the Auth Method, and click Next.
Select Custom Permissions Settings, enable Zero Knowledge Encryption, and click Finish.
View CipherTrust Manager Generated Customer Fragment
The CipherTrust Manager generated customer fragment ID is visible in both the CipherTrust Manager CLI and the Akeyless Gateway Configuration Manager.
As a CipherTrust Manager Application Administrator, such as admin
, view the Akeyless configuration on CipherTrust Manager.
ksctl akeyless config get
Retain the customer_fragment_ids
value in the response.
Example Response:
{
"gateway_connection_id": "aaeea264-e713-4075-b455-54e33a1a4518",
"sso_access_id": "p-lx4mgbad23is",
"customer_fragment_ids": [
"bbb34a30-7ca4-4717-a802-956b677f2a3d"
]
}
Note
Make sure to enable the
secrets-manager
service (Admin Settings > Services) before working on customer fragments. One customer fragment is created by default when you enable thesecrets-manager
service.Creating or deleting a customer fragment triggers a gateway restart across all nodes of a cluster.
Log on to the CipherTrust Manager GUI as an Application Administrator.
Navigate to Admin Settings > Akeyless Config.
Go to CUSTOMER FRAGMENTS expandable list. Click Create Customer Fragment.
Enter Customer Fragment Name and Description (optional).
Click Save. The customer fragment will be created as shown below.
Log on to the CipherTrust Manager GUI as an Application Administrator.
Navigate to Admin Settings > Akeyless Config.
Go to CUSTOMER FRAGMENTS expandable list. It displays the list of customer fragments as shown below.
Log on to the CipherTrust Manager GUI as an Application Administrator.
Navigate to Admin Settings > Akeyless Config.
Go to CUSTOMER FRAGMENTS expandable list. Select the desired customer fragment.
Click the ellipsis on the right side of a customer fragment and click Delete as shown below.
Note
From CipherTrust Manager 2.14 release onward, the generation of fragments is not allowed. The downloaded material for the customer fragments will be empty. The UI will still have the option to generate and download the customer fragments, but this functionality will not be supported.
Obtain Gateway-Admin Credentials
Obtain the Gateway-Admin credentials using the following steps:
Navigate to Users & Auth Methods and click the pre-created Gateway-Admin auth method.
Click Reset Access Key.
Type
Gateway-Admin
and click Reset Access Key to confirm.Save the Access ID and Access Key credentials, which are returned. These credentials might be required for future Gateway configuration tasks.
Caution
Resetting the Access Key to obtain the Gateway-Admin credentials will make the Akeyless connection created during initial configuration invalid. The connection needs to be updated with the new Access Key followed by services restart for the Akeyless Gateway to continue working.
Configuring Akeyless CLI Access for the Gateway Admin
Gateway Admins can use the Akeyless CLI on a client computer to do follow-on configuration of the Akeyless Gateway, such as adding a default protection key that uses the CipherTrust Manager-generated customer fragment.
The required steps depend on the CipherTrust Manager web interface certificate.
In a production configuration, the CipherTrust Manager web interface certificate would be signed by an certificate authority (CA) external to the CipherTrust Manager. As well, a hostname consistent with the web interface certificate would be allocated for the CipherTrust Manager in your organization's DNS server. For these setups, you can proceed directly to steps for all web interface configurations.
By default, a local CipherTrust Manager CA issues the web interface's server certificate, and the certificate values are not suitable to register a hostname in a DNS server. This interface configuration is recommended for testing purposes only. For these setups, there are additional steps needed to install the Akeyless CLI.
Steps for Default Test Web Server Certificate Configuration
As a CipherTrust Manager user in the
admin
group, download the web interface certificate chain for the web interface to a file.ksctl interfaces certificate get --name web --icertfile web-ciphertrustmanager-local.pem
Set an environment variable
AKEYLESS_TRUSTED_TLS_CERTIFICATE_FILE
to define the downloaded certificate file as trusted for the Akeyless CLI connection.set AKEYLESS_TRUSTED_TLS_CERTIFICATE_FILE=<path_to_certificate_chain_file>
Example:
set AKEYLESS_TRUSTED_TLS_CERTIFICATE_FILE=web-ciphertrustmanager-local.pem
export AKEYLESS_TRUSTED_TLS_CERTIFICATE_FILE=<path_to_certificate_chain_file>
Example:
export AKEYLESS_TRUSTED_TLS_CERTIFICATE_FILE=web-ciphertrustmanager-local.pem
Resolve the hostname to the subject alternative name on the local operating system.
Add an entry to
C:\Windows\System32\drivers\etc\hosts
file with the CipherTrust Manager IP address and the subject alternative name.Example
172.31.21.55 web.ciphertrustmanager.local
Syntax
cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 <ciphertrust_IP_address> <certificate_subject_alternative_name>
Example
cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 172.31.21.55 web.ciphertrustmanager.local
Proceed to steps for all web interface configurations.
Steps for All Web Interface Configurations
Set an environment variable
AKEYLESS_GATEWAY_URL
to define the CipherTrust Manager Akeyless Gateway URL in relation to the server certificate. The variable depends on whether the client is hosted on Windows or Linux. You require the Subject Alternative Name in the web interface server certificate. For the default web interface configuration, this value isweb.ciphertrustmanager.local
.Caution
Always include the trailing slash in the environment variable.
set AKEYLESS_GATEWAY_URL=https://<subject_alternative_name>/akeyless-api/
Default web interface server certificate:
set AKEYLESS_GATEWAY_URL=https://web.ciphertrustmanager.local/akeyless-api/
export AKEYLESS_GATEWAY_URL=https://<subject_alternative_name>/akeyless-api/
Default web interface server certificate:
export AKEYLESS_GATEWAY_URL=https://web.ciphertrustmanager.local/akeyless-api/
Create a profile when prompted using the Gateway Admin's Access ID and Access Key.
Tip
If you use a CA specific to your organization to sign the web interface certificate, and the Akeyless CLI doesn't connect to the gateway, this could indicate that the CA is at a nonstandard location that the Akeyless CLI can't find. Try setting the AKEYLESS_TRUSTED_TLS_CERTIFICATE_FILE
environment variable as the path to your organization CA.
Akeyless Browser Extension
The akeyless browser extension is a secrets management tool that allows you to create and view secrets on the go.
The akeyless browser extension can be used to create and view static secrets. The static secrets are key/value pairs
that you create and update manually, such as passwords and API tokens. Any text-based items can be stored within their original format, including config files, JSON, YAML, and so on.
It also allows you to view the rotated and dynamic secrets. The rotated secrets enable you to protect the credentials for privileged-user accounts such as an Administrator account on a Windows server, a root account on a Linux server, or an Admin account on a network device, by resetting its password, whereas, the dynamic secrets are generated every time they are accessed, using permissions you've defined in advance. In this way, users can access a resource for a temporary period with a defined set of permissions.
The extension can be installed in the browser such as Firefox, Google Chrome, and Microsoft Edge. When you log in to akeyless with valid credentials, you can access and utilize secrets from that account.
Note
The password management functionality is disabled for the Thales infrastructure. If a user tries to store the passwords using the extension, it throws an error.
The extension is not supported with the credentials created in the single-tenant environment.
Secrets that are protected by a customer fragment can't be viewed inside the extension.
For more details, click here.
Akeyless Single Tenant Infrastructure
Single-tenancy is an architecture in which a single instance of a software application and supporting infrastructure serves one customer.
The default akeyless gateway always points to the vault.akeyless.io
URL. The following parameters have been introduced for the users having single tenant infrastructure to perform the akeyless cloud operations:
For new sign ups when CSM is not configured
akeyless_signup_url
- Sets the endpoint value of your specific single-tenant akeyless infrastructure to the "akeyless_signup_url" field and generate the credentials. If this field is left blank, the account is created on the default "https://vault.akeyless.io" endpoint. This parameter is considered only when the gateway_connection_id
is not set.
Example Request
ksctl akeyless config modify --akeyless-signup-url <akeyless-infrastructure-url>
Response
{
"akeyless_signup_url": <akeyless-infrastructure-url>,
"customer_fragment_ids": [
"36871b61-a57a-45be-b464-ec3f349f4d63"
]
}
Log on to the CipherTrust Manager GUI as an Application Administrator.
Navigate to Admin Settings > Akeyless Config.
Enter the endpoint value of your specific single-tenant akeyless infrastructure in the Akeyless Signup URL field. If this field is left blank, the default "https://vault.akeyless.io" endpoint is used for sign ups. This parameter is considered only when the
gateway_connection_id
is not set. After the signup is complete and the Gateway Connection is set, the Akeyless gateway starts using theakeyless_url
field of this connection for performing all its other cloud operations.Click Update.
Reconfigure existing CSM configuration to use single tenant infrastructure
akeyless_url
- Sets the URL of the akeyless server in the "akeyless_url" field of the connection set as gateway connection. This will be used by the gateway to perform all its cloud operations. This parameter can be used in scenarios when a dedicated single tenant akeyless infrastructure is deployed. If this field is left blank, the default "https://vault.akeyless.io" endpoint is used internally by the gateway.
Example Request
ksctl connectionmgmt akeyless create --name test-connection --akeyless-key-id p-36zh053am --akeyless-key 0q4Lsh2iUHARpSaMvIeYaEgMuj6o2TN1RM --akeyless-url <akeyless-infrastructure-url>
Response
{
"id": "51ee0d98-165b-438f-9e1c-4444e5e5e01a",
"uri": "kylo:kylo:connectionmgmt:connections:test-connection-51ee0d98-165b-438f-9e1c-4444e5e5e01a",
"account": "kylo:kylo:admin:accounts:kylo",
"createdAt": "2023-11-01T10:18:29.79939315Z",
"updatedAt": "2023-11-01T10:18:29.798182064Z",
"service": "akeyless",
"category": "cloud",
"last_connection_ok": null,
"last_connection_at": "0001-01-01T00:00:00Z",
"name": "test-connection",
"access_key_id": "p-36zh053am",
"akeyless_url": "<akeyless-infrastructure-url>"
}
Log on to the CipherTrust Manager GUI as an Application Administrator.
Navigate to Access Management > Connections.
On the Connections screen, Add Connection.
Select category as Cloud and Akeyless Gateway as cloud type.
Click Next.
Add connection name and description. Click Next.
Enter the following values:
Access Key ID - Enter the ID of a key used for accessing the Akeyless server.
Access Key - Enter the key used for accessing the Akeyless server.
Akeyless URL - Enter the URL of the akeyless server as gateway connection. This will be used by the gateway to perform all its cloud operations. This parameter can be used in scenarios when a dedicated single tenant akeyless infrastructure is deployed. If this field is left blank, the default "https://vault.akeyless.io" endpoint is used internally by the gateway.
Click Test Credentials to check whether the connection is configured correctly. If the test is successful, the status is OK else the status is Fail.
Click Next to move to the Add Products screen of the Add Connection wizard.
The connection will be created.
Note
While connecting to Akeyless from the CipherTrust Manager, you may encounter the "502 Bad Gateway" error in the following scenarios:
After restarting the CipherTrust Manager or akeyless gateway
After updating the Akeyless signup URL or the configured gateway connection in the gateway configuration endpoint
To establish a connection, first check your internet connection and try again after some time.
Mapping CipherTrust Manager Domains to Akeyless Resources
On CipherTrust Manager, a domain is a logical division that isolates users and resources. Resources such as keys are private to their specific domain and cannot be accessed across domains.
Before proceeding to the next steps, we recommend you to get familiar with the following terms:
Access Roles - limit access rights for users. It is a way to grant specific permissions to users on secrets, encryption keys, targets, authentication methods, and so on. Access roles are very similar to the groups in the CipherTrust Manager.
Directory Structure - provides logical separation of akeyless resources. The concept of directory structure is logically similar to the domains in the CipherTrust Manager.
Sub Claims - for some of the authentication methods such as JWT/OIDC, and LDAP that contain attribute-based access control (ABAC), also known as policy-based access control, as part of the given signed token, you can restrict the authorizations of the associated role to these specific claims or attributes. In other words, only clients whose token contains these sub claims (in the case of JWT/OIDC) or attributes (in the case of SAML) will be allowed to access the rules defined in the role.
For more details, refer to Akeyless documentation.
Tip
In this section, the terms directory and domain will be used interchangeably.
Akeyless allows you to create separate access roles for different domains and for the associated users of that domain. While creating access roles, you can add these access roles to different directory structures to achieve a logical separation.
To create access roles, perform the following steps:
Note
Only the Super Administrator can create Access Roles.
On the CipherTrust Manager
Log on to the CipherTrust Manager GUI as an Application Administrator.
Configure the Single sign-on (SSO) flow. Refer to Configure Akeyless Gateway for details.
On Akeyless Console
Navigate to Access Roles. Click New to create an access role.
On the Create Role screen, add Name, Location, and Description. The Location field is used to create a directory structure. If you don't provide any directory name in Location, the role will be created in the root directory.
Create directories as required, one for each domain.
Now, separate directories are created for each domain and domain-users can only access the particular set of permissions that are defined within those directories. This allows creation of distinct permission sets for the specific users associated with that domain.
To create a permission set for a particular directory, perform the following steps:
Navigate to the domain directory and select the access role created inside it as created in the above steps.
Click Associate to configure an authentication method and sub claims. This step creates an association between the access role and the authentication method. Each user authenticating through this authentication method will be assigned permission set of this access role if the sub claim condition satisfies.
On the Associate Auth Method screen, select Auth Method from the drop-down list that allows SSO login and add Sub Claims corresponding to the CipherTrust Manager domains or groups.
For domain
Syntax
cust.domain_id = <ciphertrust_manager_domain_ID>
Example
cust.domain_id = 53c5aa3b-1e75-4684-b644-512e483fe883
Similarly, you can add a Sub Claim corresponding to the CipherTrust Manager group:
Syntax
cust.groups = <ciphertrust_manager_group_name>
Example
cust.groups = Key Admins
You can get domain id and group information from the CipherTrust Manager.
Click Add to add rules for Secrets & Keys. You must add at least one set of permissions to make this work.
Now the permission set is created for domain users inside the akeyless directory.
Let's see some of the use cases.
Use case 1
If you want to define an access role for users who are members of a particular domain and a group.
You can add multiple sub claims in the single associated auth-method.
Syntax
cust.domain_id = <ciphertrust_manager_domain_ID>
cust.groups = <ciphertrust_manager_group_name>
Example
To generate domain specific key permissions, let's create a domain say "domain-1" and associate it with "Key Admins" groups.
cust.groups = Key Admins
cust.domain_id = <domain id of the domain-1>
Use case 2
Multiple domains can also be linked to a single access role. As a result, a single access role can handle a set of permissions for many domains, and all users in each domain can access akeyless resources.
To add multiple attributes of the same type such as cust.domain_id
or cust.groups
in a single access role association, you can perform multiple associations (using Associate button) as shown below:
Association 1
cust.domain_id = <ciphertrust_manager_domain_ID>
Association 2
cust.domain_id = <ciphertrust_manager_domain_ID>
Association 3
cust.domain_id = <ciphertrust_manager_domain_ID>
Association 4
cust.domain_id = <ciphertrust_manager_domain_ID>
Managing Multiple Customer Fragments
The previous section describes how the CipherTrust Manager domains are mapped to the Akeyless directories using the appropriate sub-claims. This allows separation of resources but all the protection keys (used to encrypt secrets) could only use a single CipherTrust Manager generated customer fragment created during the system startup.
To attain a granular control, users can now create multiple customer fragments and multiple protection keys can be created using these fragments. These fragments will be accessible in the Akeyless Gateway.
Note
The customer fragments in the CipherTrust Manager are not domain scoped and can be created/managed only in the root domain. A user should belong to the admin group in the root domain to perform the customer fragment operations.
Prerequisites
Akeyless Gateway is configured. Refer to Configure Akeyless Gateway for details.
CipherTrust Manager domains are mapped to the Akeyless resources. Refer to Mapping CipherTrust Manager Domains to Akeyless Resources for details.
Providing Customer Fragment Access to CipherTrust Manager Admin
To provide customer fragment access to the CipherTrust Manager admin:
Sign in to the Akeyless console as the Super Admin or Gateway Admin.
Navigate to the Gateways tab and select default gateway.
Go to the Access Permissions tab and click Add.
Add a name to the access permission and select SSO as the Auth Method. The CipherTrust Manager uses this method for authentication.
Add the sub-claims:
cust.groups = admin
andcust.domain_id = 00000000-0000-0000-0000-000000000000
.In the Permissions Settings section, select Zero Knowledge Encryption. This will grant the CipherTrust Manager administrator (in the root domain) access to use all the customer fragments.
Limiting DFC Key Access to Directories
Assume a scenario with two CipherTrust Manager domains dom1
and dom2
with all the mappings in place with Akeyless directories and access roles.
Create two customer fragments for each of these domains. Name these customer fragments as
dom1 CF
anddom2 CF
.Refer to Step 6 (Manage customer fragments) of the Configure Akeyless Gateway section for details.
The Akeyless configurations should be auto-updated and start showing IDs of the above created fragments in the
customer_fragment_ids
parameter. Also, the fragments should be visible in the Zero Knowledge Encryption section on the Akeyless Gateway.Sign in as the CipherTrust Manager administrator (in the root domain) and click CSM tile.
On the Secrets and Keys section in the Akeyless console, click New > Encryption Key > DFC.
Add a relevant name, description, and type
AES256
for the DFC key.Set the location of the key as
/dom1
.Select customer fragment
dom1 CF
from the drop-down list.Repeat the above steps for creating a DFC key in
dom2
.
Now sign in to the CipherTrust Manager as a user in dom1
who has access to the Akeyless resources in the dom1
directory and perform the following steps:
Click CSM tile on the products page.
Create a new secret. While selecting the protection key for this secret, the DFC key created in the previous steps can be viewed. Note that only the key created in the
dom1
directory will be visible.Repeat the above steps for user in
dom2
.
This way the resources created in any of the domains (dom1
and dom2
) can only be decrypted by assigned DFC keys, which would be using their own unique customer fragment.