Your suggested change has been received. Thank you.

close

Suggest A Change

https://thales.na.market.dpondemand.io/docs/dpod/services/kmo….

Thales Logo

All

  • All
back

Secrets Management Administration

Create and Protect Akeyless Secrets

search

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

  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.

    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

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

  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.

        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/

  2. Download and install the latest Akeyless CLI.

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

    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>

    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

  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. As a CipherTrust Manager user with secrets management access, obtain an Akeyless access token.

    ksctl akeyless tokens create

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

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

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

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

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

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

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

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

On this page