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

1. Sign up for an Akeyless account with administrative level permissions.

   This provides you with a 90 day free trial to Akeyless Vault Platform, with settings that are suitable for CipherTrust Manager integration.

   1. Navigate to https://<ciphertrust_manager_hostname>/akeyless-console/.

      The Akeyless Vault Platform interface is displayed.

   2. Click the Sign up link in the upper right.

   3. Enter an email address.

   4. Open the confirmation email and click Activate your account.

      The account credentials are displayed in a browser window.

   5. Capture the Access ID and Access Key. These are the Super-Admin credentials. There is an option to save these values to CSV, if desired. These are required for necessary Akeyless Gateway configuration.

   Note

   • After 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.

2. As a CipherTrust Manager Application Administrator, such as admin, rotate the CipherTrust Manager authentication key to an ECDSA key.

   Note

   The CipherTrust Manager 2.15 onward for fresh installations, the default token authentication key type is ES256. Therefore, key rotation is not required.

   Request

       ksctl tokens rotate-auth-key --type ecdsa --curve p256
   

   This key is used to sign and verify external JWTs.

3. Isolate the public key value and reformat for Akeyless console.

   In CipherTrust Manager, you can view the public key value with ksctl tokens list-auth-keys command. The public key value is displayed in a JSON attribute called public_key_jwk. Akeyless console needs this value in an array called keys.

   Akeyless Console Syntax

   {
     "keys": [
   <value of `public_key_jwk` attribute>
     ]
   }
   

   Example Reformatting

   In this example, the public_key_jwk attribute is obtained with ksctl, and then reformatted in a text editor.

   Obtain the public key value

   ksctl tokens list-auth-keys
   
   {
       "skip": 0,
       "limit": 10,
       "total": 1,
       "resources": [
           {
               "id": "7e99444d-f511-4a75-908f-f3cc90801e4e",
               "type": "ecdsa",
               "public_key_pem": "-----BEGIN PUBLIC KEY-----\nMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEb5y6sdqZpB5HcciwP/Fl0K4s3czQ\nFG6tZwmXLAJxGH44qsjYaDTGQE3WElM7UCLu5EGZeJhubXyqBYkfDXNb5w==\n-----END PUBLIC KEY-----\n",
               "public_key_jwk": {
                   "crv": "P-256",
                   "kty": "EC",
                   "x": "b5y6sdqZpB5HcciwP_Fl0K4s3czQFG6tZwmXLAJxGH4",
                   "y": "OKrI2Gg0xkBN1hJTO1Ai7uRBmXiYbm18qgWJHw1zW-c"
               },
               "createdAt": "2023-06-21T12:53:40.23849Z",
               "updatedAt": "2023-06-21T13:01:24.872168Z"
           }
       ]
   }
   

   Example reformatting

   {
     "keys": [
       {
         "crv": "P-256",
         "kty": "EC",
         "x": "b5y6sdqZpB5HcciwP_Fl0K4s3czQFG6tZwmXLAJxGH4",
         "y": "OKrI2Gg0xkBN1hJTO1Ai7uRBmXiYbm18qgWJHw1zW-c"
       }
     ]
   }
   

4. Register the ECDSA signing key with Akeyless and create objects to authenticate CipherTrust Manager users to Akeyless console.

   1. Login with your Akeyless administrative account at https://<ciphertrust_manager_hostname>/akeyless-console/.

   2. Navigate to Users & Auth Methods > New > Oauth2.0/JWT.

      Note

      We recommend deleting the User-Admin role, as it is not needed. The new Oauth 2.0/JWT method controls Akeyless permissions for CipherTrust Manager users.

   3. Create an OAuth2.0/JWT authentication method. The following settings are required:

      • A Name must be provided.

      • Select the JSON or Gateway option.

        • For the JSON option, the JWKs JSON field must contain the ECDSA public key value. Copy and paste the keys array created in step 3.

        • For the Gateway option, in the Gateway field, select defaultCluster or configure the gateway in the Gateways section. In the JWKs URL field, enter the following:

          https://CM-IP/v1/auth/jwks.json
          

      • Set a value for Unique Identifier and it should be unique.

      You can optionally change the default JWT TTL (in minutes) from the default value. This controls the expiry time for an Akeyless token issued for CipherTrust Manager users.

   4. Click Save.

   5. Retain the Access ID value of this authentication method, as this is needed to edit the Akeyless configuration on CipherTrust Manager.

   6. Navigate to Access Roles.

      Note

      You must associate the new auth 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 Akeyless console to restrict secrets management to fewer CipherTrust Manager users, if desired.

   7. Click New to create a new role, provide a Name, and click Create Role.

   8. Select the tabs for Secrets & Keys, Access Roles, Auth Methods, and Targets, and click + Add to add rules. Add recursive rules to allow create, read, update, delete and list operations. Click Add.

      Caution

      Do not allow the 'Deny' operation. This overrides all other operations permissions, and breaks the CipherTrust Manager integration.

   9. Associate the new auth method to the new access role. Click + Associate, select the auth method name from the Auth Method dropdown. Click save.

5. Set the SSO access ID on CipherTrust Manager to the Akeyless access ID associated with the OAuth2.0/JWT authentication method created in step 4.

   1. Login to CipherTrust Manager GUI as an Application Administrator, such as admin.

   2. Navigate to Admin Settings > Akeyless Config.

   3. In the SSO Access ID field, enter the Access ID obtained in step 4.

   4. Click Save.

      Note

      Do not edit the Akeyless Connection field. This is automatically populated with the autogenerated Akeyless Gateway connection.

6. Restart the CipherTrust Manager services.

   1. Navigate to Admin Settings > Services.

   2. Click System Restart to restart all services and apply the Akeyless configuration change.

7. Once CipherTrust Manager GUI is available again, login as any user.

   Ensure that the Secrets Management tile is enabled.

   If you click the tile, single sign-on takes place silently as CipherTrust Manager issues a token for Akeyless to verify with the ECDSA signing key. You are logged into the Akeyless console.

8. Allow CipherTrust Manager users to use the CipherTrust Manager generated customer fragment to protect Akeyless secrets.

   1. Login to the Akeyless console https://<ciphertrust_manager_hostname>/akeyless-console/ as Super Administrator. Supply the Access ID and Access Key obtained in step 1.

   2. Navigate to Gateways and select the defaultCluster.

   3. In the Gateway URL (Configuration) field, enter the CipherTrust Manager URL preceded by https://. For example, enter https://ciphertrust.mycompany.com. Click the checkmark to confirm.

   4. Click the Access Permissions tab.

   5. Click New.

   6. Enter a meaningful Name, select the OAuth2.0/JWT authentication method created in step 4 for the Auth Method, and click Next.

      Note

      These steps set up permissions for all CipherTrust Manager users to use the customer fragment. You can adjust settings on both CipherTrust Manager UI and Akeyless console to restrict customer fragment usage to fewer CipherTrust Manager users, if desired.

   7. Select Custom Permissions Settings, enable Zero Knowledge Encryption, and click Finish.

CipherTrust Manager users can now manage secrets, including protecting them with the CipherTrust Manager generated customer fragment.

You can perform additional configuration if needed:

• Restrict secrets management or customer fragment access to certain users, if needed.

Configure a Default Encryption Key

This configuration can also be performed through the Akeyless CLI, if set up for Gateway Admin access is configured.

1. 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"
       ]
   }
   

2. Login as any user with secrets management permissions to the CipherTrust Manager UI, and click the Secrets Management tile to access the Akeyless console.

3. Create an encryption key associated with the customer fragment.

   1. Navigate to Secrets & Keys.

   2. Click New > Encryption Key > DFC.

   3. 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.

   4. Click Finish.

4. 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.

5. Select Defaults.

6. In the Default Encryption Key dropdown list, select the newly created encryption key.

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

1. Login to CipherTrust Manager as a user in the Users Admins or admin group.

2. Create a group for secrets management.

3. Associate desired users to that group.

4. Login with your Akeyless administrative account at https://<ciphertrust_manager_hostname>/akeyless-console/.

5. 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.

6. 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

This configuration can also be performed through the Akeyless CLI, if set up for Gateway Admin access is configured.

1. Login to CipherTrust Manager as a user in the Users Admins or admin group.

2. Create a group for secrets management.

3. Associate desired users to that group.

4. Login with your Akeyless administrative account at https://<ciphertrust_manager_hostname>/akeyless-console/.

5. Navigate to Gateways and click the Access Permissions tab.

6. 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.

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

1. Login to CipherTrust Manager as a user in the Domain Admins or admin group.

2. 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.

3. Add desired users to that domain.

4. Login with your Akeyless administrative account at https://<ciphertrust_manager_hostname>/akeyless-console/.

5. 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.

6. 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

This configuration can also be performed through the Akeyless CLI, if set up for Gateway Admin access is configured.

1. Login to CipherTrust Manager as a user in the Domain Admins or admin group.

2. 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.

3. Add desired users to that domain.

4. Login with your Akeyless administrative account at https://<ciphertrust_manager_hostname>/akeyless-console/.

5. Navigate to Gateways and click the Access Permissions tab.

6. 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.

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

1. 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.

2. Navigate to Gateways and select the defaultCluster.

3. In the Gateway URL (Configuration) field, enter the CipherTrust Manager URL preceded by https://. For example, enter https://ciphertrust.mycompany.com. Click the checkmark to confirm.

4. Click the Access Permissions tab.

5. Click New.

6. Enter a meaningful Name, select the desired authentication method for the Auth Method, and click Next.

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

Viewing in CipherTrust Manager CLI

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"
    ]
}

Obtain Gateway-Admin Credentials

Obtain the Gateway-Admin credentials using the following steps:

1. Navigate to Users & Auth Methods and click the pre-created Gateway-Admin auth method.

2. Click Reset Access Key.

3. Type Gateway-Admin and click Reset Access Key to confirm.

4. 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

1. 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
   

2. Set an environment variable AKEYLESS_TRUSTED_TLS_CERTIFICATE_FILE to define the downloaded certificate file as trusted for the Akeyless CLI connection.

   Windows

   set AKEYLESS_TRUSTED_TLS_CERTIFICATE_FILE=<path_to_certificate_chain_file>
   

   Example:

   set AKEYLESS_TRUSTED_TLS_CERTIFICATE_FILE=web-ciphertrustmanager-local.pem
   

   Linux

   export AKEYLESS_TRUSTED_TLS_CERTIFICATE_FILE=<path_to_certificate_chain_file>
   

   Example:

   export AKEYLESS_TRUSTED_TLS_CERTIFICATE_FILE=web-ciphertrustmanager-local.pem
   

3. Resolve the hostname to the subject alternative name on the local operating system.

   Windows

   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

   Linux

   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

1. 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 is web.ciphertrustmanager.local.

   Caution

   Always include the trailing slash in the environment variable.

   Windows

       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/
   

   Linux

       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/
   

2. Download and install the latest Akeyless CLI.

3. Create a profile when prompted using the Gateway Admin's Access ID and Access Key.

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.

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 - Set 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"

    ]

}

Reconfigure existing CSM configuration to use single tenant infrastructure

akeyless_url - Set 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>"
}

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.

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:

On the CipherTrust Manager

1. Log on to the CipherTrust Manager GUI as an Application Administrator.

2. Configure the Single sign-on (SSO) flow. Refer to Configure Akeyless Gateway for details.

On Akeyless Console

1. Navigate to Access Roles. Click New to create an access role.

2. 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.

3. 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:

1. Navigate to the domain directory and select the access role created inside it as created in the above steps.

2. 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.

3. 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.

4. 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>