Step 3 - Initialize the CLI

VP-DV CLI initialization presents you with a series of prompts and options. If you are the initial administrator who setup the tenant, then you will have the required information from signing-up. If you are not the initial administrator, you will need the collect this information from that person:

  • tenant name
  • domain
  • local or federated user, and if federated, which authentication provider
  • credentials - username or access key, password, or secret key

Video Guide

Click to open the video in a new window

Procedure

  1. Begin setup with the dsv init command. This will start a workflow.

  2. Enter your tenant name.

    ? Please enter tenant name:
    				

    The tenant name was provided to the initial administrator by ## when you set up your account.

    You need only enter your tenant name, i.e., example not example.secretsvaultcloud.com, because the domain is set by region and that is covered in the next question.

  3. Select the domain.

    ? Please choose domain:  [Use arrows to move, type to filter]
    						> secretsvaultcloud.com
    						secretsvaultcloud.eu
    						secretsvaultcloud.com.au
    						secretsvaultcloud.ca
    				

    Your domain is based on the server location that was chosen during provisioning: US, EU, AU or CA.

  4. Choose a type of credentials and cache storage.

    ? Please select store type:  [Use arrows to move, type to filter]
    						> File store
    						None (no caching)
    						Pass (Linux only)
    						Windows Credential Manager (Windows only)
    				
    • Select File store to keep the credentials in files. If you select this, VP-DV prompts for the directory location.
    • Select None (no caching) to omit storing the credentials. With this option active,VP-DV requires authentication with every command.
    • Select Pass (Linux only) to use Linux pass for encrypted storage.
    • Select Windows Credential Manager (Windows only) to use Windows Credential Manager. to store credentials.
  5. Choose a cache strategy for secrets.

    ? Please enter cache strategy for secrets:  [Use arrows to move, type to filter]
    						> Never
    						Server then cache
    						Cache then server
    						Cache then server, but allow expired cache if server unreachable
    				

    The choice here depends on your organization's security, network connectivity, performance, and systems availability.

    Server refers to your VP-DV tenant and cache refers to storage on the local machine with the CLI installed.

    • Select Never to never cache secrets. Every secret read request requires an API call.
    • Select Server then cache to make an API call every time. If not accessible, then the cached secret is used.
    • Select Cache then server to use the cached secret unless it has expired, in which case an API call is made.
    • Select Cache then server, but... to make an API call if the cached secret has expired, but if the API call fails, then the expired cached Secret is used.
  6. Select an authentication type.

    ? Please enter auth type:  [Use arrows to move, type to filter]
    						> Password (local user)
    						Client Credential
    						Thycotic One (federated)
    						AWS IAM (federated)
    						Azure (federated)
    						GCP (federated)
    						OIDC (federated)
    						x509 Certificate
    				
    • Select Password (local user) to authenticate by username and password.

    • Select Client Credential to authenticate by Client ID and Client Secret.

    • Select ## (federated) to authenticate using ##'s access manager.

      The person who signed up for Verify Privilege DevOps Vault is the initial administrator and is automatically setup using ##. If this is you, then select this option. This enables you to reset the password if it is ever lost and/or setup up 2FA if desired. It is up to the customer to then decide if all other users are local or federated through one the available providers.

    • Select AWS IAM (federated) to authenticate as a trusted Identity Access Management Role or User. Refer to AWS Authentication.

    • Select Azure (federated) to authenticate as a trusted Azure Managed Service Identity (MSI). Refer to Azure Authentication.

    • Select GCP (federated) to authenticate as a trusted Google Service Account. Refer to GCP Authentication.

    • Select OIDC (federated) to authenticate through ## to an external IDP using the OIDC protocol. Refer to OIDC Authentication.

    • Select x509 Certificate to authenticate using certificates. Refer to Certificate Authentication.

  7. Complete the authentication.

After initialization was completed, type $ dsv auth to obtain and display your access token.

You can now use the CLI to create your first secret in the Verify Privilege DevOps Vault. Refer to Step 4 - Create a Secret.