What is Keeper Secrets Manager?

Keeper Secrets Manager (KSM) provides your DevOps, IT Security and software development teams with a fully cloud-based, Zero-Knowledge platform for managing all of your infrastructure secrets such as API keys, Database passwords, access keys, certificates and any type of confidential data.

Common use cases for Secrets Manager include:

• Removing hard-coded credentials from source code

• Replacing configuration file secrets

• Pulling secrets into CI/CD systems like Jenkins, GitHub Actions and More

• Protecting access to privileged passwords, API keys and other managed secrets

• Providing vault access to machines and applications

• Automatically rotating passwords, service account credentials and cloud identities

Features

• No hosted software or VMs to configure and manage (100% Cloud-based)

• Secure and user-friendly Web Vault and Browser Extensions for secrets management

• Automated password rotation across any target user or machine

• Powerful native Mobile and Desktop Applications for every device type and OS

• Admin Console for managing enforcement policies, users, teams and provisioning

• SAML 2.0 and Master Password user login methods

• Shared passwords and secrets among Teams and individual users

• Simple and fast deployment methods

• Developer-friendly SDKs for the most popular programming languages and environments

• Built for all users - not just DevOps!

• Advanced Reporting & Alerts for audit and compliance

• Integration with Slack and Microsoft Teams

• Dedicated 24/7 support

• SOC2, ISO27001 certified

• FIPS 140-2 validated

• FedRAMP Authorized and StateRAMP Authorized

Get Started

Video Overview

The basic steps of setting up Secrets Manager is in the video below.

Prerequisites

Keeper Business License

On your workstation:

• PIP version 21+ (Included in Python)

Getting Started

First, we need to follow a few steps to enable Secrets Manager for your Keeper account.

Enable Secrets Manager

To activate your trial of Keeper Secrets Manager, login to the Admin Console and click on "Secrets Manager".

Create a Role

Create a Keeper account role that will be used by Secrets Manager users. Keeper account roles can be created in the Admin Console.

Click "Add Role" to create a new role, give it a name like "Secrets Managers".

Enable Secrets Manager for the Role

Enable Application Access for roles in the Keeper Secrets Manager enforcement policies.

1. Select the Role

2. Open Enforcement Policies

3. Choose Keeper Secrets Manager tab

4. Enable Keeper Secrets Manager policy

Setup Secrets Manager

In this exercise you will setup Secrets, create an Application, and configure a Client in order to access your secrets using Keeper Secrets Manager.

Create a Secret

Secrets are stored as records in the Keeper Vault and are typically stored as attachments or fields in these records.

In the Keeper Web Vault or Desktop App user interface, create a Shared Folder and then add Secrets to the folder.

Create a shared folder

Click "Create New" and choose "Shared Folder"

Enter a name and click "Create" to create a new shared folder.

With the new shared folder selected, click the "Create New" button and select "Record" to create a new record inside the shared folder

Create a Secrets Manager Application

In the Keeper Vault, navigate to the Secrets Manager tab to see a list of Secrets Manager applications. Then click "Create Application"

Enter a name for the new Secrets Manager Application

Next choose the shared folder(s) to share with the new Application. The Application will only have access to the records in the selected folder(s).

You can choose to give the Application Read Only or Write access to the Vault records, and choose if the first Secrets Manager Client Device should be locked to the first IP address that accesses Secrets Manager. (More on Client Devices below)

Click "Generate Access Token" to create the Application and automatically create the first Secrets Manager Client Device.

Create a Secrets Manager Client Device

When a Secrets Manager Application is created in the Keeper Vault, a Secrets Manager Client Device is also created.

When a Client Device is created, a One-Time Access Token is generated and displayed. You will need this One-Time Access Token later in the guide. Copy or download the token to use later.

Create Additional Client Devices (optional)

Once the Secrets Manager Application is created, more Client Devices can be created for the Application.

View Secrets

Next we'll view the secrets from the Keeper Vault shared with Secrets Manager using the Secrets Manager CLI.

Install the Secrets Manager CLI

Installing using binary release

When launching the CLI in Windows or macOS, via the UI, the CLI will run in a shell mode. The ksm command is still available via the command line.

The Linux binary is just an executable and should be moved to a directory in the PATH.

Installing KSM using pip3 and Python3

If you prefer to install using pip3 and Python3, use the commands below:

If pip3 is not installed on your system, make sure to install Python3. For example, using yum:

Connect Keeper Secrets Manager CLI to the Secrets Manager Application

Initialize the CLI using the One-Time Access Token obtained above.

Access Your Secrets

To retrieve a list of all secrets, use the ksm secret list command:

The CLI should show a list of secrets shared with the Secrets Manager Application.

Finishing Up

Next steps:

• Schedule time with the Secrets Manager team to discuss your use case

Setup Using Keeper Commander CLI

If preferred, Secrets Manager can be setup using Keeper's command line tool Commander instead of the Keeper Vault. Follow these steps to setup Secrets Manager using Keeper Commander.

Enable Secrets Manager for a Role

In some cases, Commander is needed to enable Secrets Manager for a Keeper role. To do this, use the following command:

Create a Secret

Secrets are stored as records in the Keeper Vault and are typically stored as attachments or fields in these records.

Run Keeper Commander by typing keeper shell then login with your Keeper email:

After logging in:

• Create a Secret

• Create a Shared Folder

• Move the secret into the Shared Folder.

Example commands are shown below:

Create a Secrets Manager Application

Secrets are shared to Applications as records or shared folders. Applications maintain client devices, permissions, audit trail, and history.

In the example below, replace XXX with the Shared Folder UID or Record UID from your vault.

Create a Secrets Manager Client Device

A Client Device is any endpoint that needs to access secrets associated with an Application. This can be a physical, virtual, or cloud-based device.

Create a client device to generate a One Time Access Token, which is used to initialize a device.

Continue Quick Start Guide

Overview

Information about how Keeper Secrets Manager works.

Common Functionality

Additional details about aspects of Keeper Secrets Manager which are used across many integrations and SDKs.

Additional Resources

Information about other Keeper systems that impact Secrets Manager users.

Overview

Keeper Secrets Manager is a Zero Knowledge platform. Encryption and decryption of secrets takes place locally on the Client Device running the ksm application, CI/CD plugins or the developer SDK.

Client Device Configuration File

The local configuration file (e.g. keeper.ini) for the ksm application contains the following format:

This file should be protected on your local filesystem. It contains keys can authenticate with the Keeper API and decrypt secrets that have been explicitly associated with the Application and Client Device.

Configuration File Fields

Authentication and Encryption

The Client Device only authenticates with the hashed One Time Access Token one time. The client signs the payload and registers a Client Device Public Key with the server on the first authentication. After the first authentication, subsequent requests are signed with the Client Device Private Key.

API requests to the Keeper Cloud are sent with a Client Device Identifier and a request body that is signed with the Client Device Private Key. The server checks the ECDSA signature of the request for the given Client Device Identifier using the Client Public Key of the device.

The Client Device decrypts the ciphertext response from the server with the Application Private Key, which decrypts the Record Keys and Shared Folder Keys. The Shared Folder Keys decrypt the Record Keys, and the Record Keys decrypt the individual Record secrets.

Protecting Access through IP Lockdown

By default, when creating a Client Device profile, IP lockdown is enabled.

For example:

The client which initializes using this token will be locked on IP. To disable IP lockdown, an additional parameter must be specified, for example:

It is recommended to allow IP lockdown, unless you are deploying to an environment which has a dynamic WAN IP.

Additional Information

Keeper utilizes best-in-class security with a Zero-Knowledge security architecture and Zero-Trust framework. Technical documentation about Keeper's Zero-Knowledge encryption model can be found at the links below:

Keeper is SOC 2 Type 2, ISO27001 certified. Customers may request access to our certification reports and technical architecture documentation under mutual NDA.

Vulnerability Disclosure Program