Please Note:

Create and Protect Akeyless Secrets

Once Akeyless Gateway is configured, CipherTrust Manager users with secret management permissions can immediately start creating secrets and using the CipherTrust Manager customer fragment to protect Akeyless secrets.

Contact the Akeyless Administrator to allow permissions to access secret management or the customer fragment if needed.

Consult Akeyless documentation on management of different secret types. We support the following secret types:

Encryption Key
Static Secret
Rotated Secret
Dynamic Secret
SSH Cert Issuer
PKI Cert Issuer
Certificate

A CipherTrust Manager user must create an encryption key using the the CipherTrust Manager-generated customer fragment for PKI Cert Issuer or SSH Cert Issuer, as in Keyless SSH Configuration. This encryption key signs all new certificates, and ensures that certificates are protected as part of the CipherTrust Manager root-of-trust hierarchy.

Note

CipherTrust Manager users generally do not need to create a new encryption key for other secret types. Static secrets, rotated secrets, dynamic secrets, and certificates are protected by the default encryption key, which uses the CipherTrust Manager customer fragment.

Create and Manage Akeyless Secrets in the Akeyless Console UI

Once Akeyless Gateway is configured, CipherTrust Manager users with permissions can click the Secrets Management tile to access the Akeyless Console UI and begin managing secrets.

Create and Manage Akeyless Secrets with Akeyless CLI

You can use the Akeyless CLI on a client computer to manage secrets through the Akeyless Gateway.

The authentication varies based on whether you desire secrets management activities to be associated with a CipherTrust Manager user.

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.

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

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

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/
Download and install the latest Akeyless CLI.
Configure and test the authentication for the user running Akeyless commands. The steps depend on whether the CLI will be accessed by a CipherTrust Manager user or another authenticated entity.
CipherTrust Manager User
1. As the CipherTrust Manager user who will create secrets, issue an Akeyless token to access the CLI.
  ksctl akeyless tokens create
  Note
  Do not create a profile. Authentication takes place with a CipherTrust Manager-issued token on each command. By default, the Akeyless token expires in 60 minutes. This expiry time is set during initial configuration.
2. List all available secrets to test the CLI connection.
  akeyless list-items --token <akeyless_token>
Other User
1. Create a profile when prompted using the desired authentication method's Access ID and Access Key.
2. List all available secrets to test the CLI connection.
  akeyless list-items

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.

Example Secrets Command

Consult Akeyless CLI documentation for detailed information on secrets operations.

This example command creates a static secret with the default encryption key.

akeyless create secret --token <akeyless_token> --name mysecret --value 123

Example Keyless SSH Configuration

Akeyless allows you to sign and distribute ephemeral certificates to authenticate SSH clients to remote servers.

A CipherTrust Manager user creates an RSA2048 encryption key using the the CipherTrust Manager-generated customer fragment. This encryption key signs all new SSH certificates, and ensures that certificates are protected as part of the CipherTrust Manager root-of-trust hierarchy.

In this example procedure, a CipherTrust Manager secrets user creates an authentication method for SSH users, who then connect through the CipherTrust Manager gateway. The SSH users are not associated with CipherTrust Manager users.

Configure Authentication to Akeyless Console for SSH Users

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

As a CipherTrust Manager user with secrets management access, obtain an Akeyless access token.
```
ksctl akeyless tokens create
```

Create an RSA2048 encryption key in the Akeyless CLI using this customer fragment id.

akeyless create-key --token <akeyless_token> --name <key_name> --alg RSA2048 --customer-frg-id <customer_fragment_id>

Create an SSH certificate issuer which uses the encryption key as the signer key. You must provide a list of SSH users allowed to fetch certificates, and a certificate time to live in seconds.
Tip
Specify the allowed_users with an asterisk * to allow any SSH user to fetch certificates.
Syntax
```
akeyless create-ssh-cert-issuer --token <akeyless_token> --name <name_for_SSH_cert_issuer> --signer-key-name <encryption_key_id> --allowed-users <list_of_allowed_users> --ttl <time_to_live_in_seconds>
```

Retrieve the public key for the RSA signer key. Extract only the SSH-formatted key and save it to a file.

akeyless get-rsa-public --token <akeyless_token> --name <signer_key_name> --json --jq-expression '.ssh' > akeyless-ca.pub

On the SSH remote server, add this public key file to a directory accessible by the SSH service.
For example, on Ubuntu Linux, add the akeyless-ca.pub public key file to the /etc/ssh directory.

On the SSH remote server, update the SSH service to trust the public key.

Ubuntu Linux example

echo "TrustedUserCAKeys /etc/ssh/akeyless-ca.pub" >> /etc/ssh/sshd_config
echo "PubkeyAcceptedKeyTypes=+ssh-rsa,ssh-rsa-cert-v01@openssh.com" >> /etc/ssh/sshd_config
systemctl restart sshd

Create Akeyless objects to authenticate SSH users.
1. Create an API auth method to authenticate SSH users. Provide a name. Retain the Access ID and Access Key displayed in the response.
  Caution
  You cannot retrieve the Access Key value later. It is only displayed when the auth method is created.
  Note
  You can optionally specify an authentication expiry time in minutes with the jwt-ttl option. If you do not include this value, SSH user access expires after 60 minutes, as is default.
  Syntax
```
akeyless create-auth-method --token <akeyless_token> --name "<some_name>" [--jwt-ttl <expiry_time_in_minutes>]
```
2. Create an Access Role for SSH users.
```
akeyless create-role --token <akeyless_token> --name "<some_name>"
```
3. Set a rule to allow SSH users access to create, read, and list secrets. A secrets folder is required. To give access to all folders, specify */.
```
akeyless set-role-rule --token <akeyless_token> --role-name "<role_name>" --path <secrets_folder_path> --rule-type=item-rule --capability read --capability list --capability create
```
4. Associate the access role with the auth method.
```
akeyless assoc-role-am --token <akeyless_token> --role-name "<role_name>" --am-name "<auth_method_name>"
```
As the Super-Admin, grant the new auth method 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 Akeyless Gateway URL preceded by https://. For example, enter https://<ciphertrust_manager_hostname>/akeyless. Click the checkmark to confirm.
4. Click the ellipsis (...) button on the right and select Manage Gateway.
5. Select Access Permissions and click Add.
6. Click New.
7. Enter a meaningful Name, select the desired authentication method for the Auth Method, and click Next.
8. Select Custom Permissions Settings, enable Zero Knowledge Encryption, and click Finish.
Install the Akeyless CLI on the SSH client computer. Set up a profile using the Access Key and Access ID of the authentication method created for SSH users.

SSH Authentication

After SSH user authentication to Akeyless Console is configured, SSH users use a local public key pair to get an ephemeral certificate from the issuer, and then sign into the remote server specifying their private keys.

For example:

akeyless get-ssh-certificate --cert-username <SSH_user_name> --cert-issuer-name <name_of_SSH_cert_issuer> --public-key-file-path <path_to_local_public_key>

SSH certificate file successfully created at: .ssh/id_rsa-cert.pub

ssh user@1.1.1.1 -i ./.ssh/id_rsa