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.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/
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.
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.
List all available secrets to test the CLI connection.
akeyless list-items --token <akeyless_token>
Create a profile when prompted using the desired authentication method's Access ID and Access Key.
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.
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>]
Create an Access Role for SSH users.
akeyless create-role --token <akeyless_token> --name "<some_name>"
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
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.
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 Access Permissions tab.
Note
Akeyless gateway version 4.15 onward, replace Steps 3-4 with the below steps:
In the Gateway URL (Configuration) field, enter the Akeyless Gateway URL preceded by
https://
. Example,https://<ciphertrust_manager_hostname>/akeyless
.Click the ellipsis (...) button on the right and select Manage Gateway.
Select Access Permissions and click Add.
The rest of the steps will remain the same.
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.
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