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.

System Architecture

In Keeper's model, all your servers, CI/CD pipelines, developer environments and source code pull secrets from a secure API endpoint.

The client device retrieves encrypted ciphertext from the Keeper cloud and the secrets are decrypted locally on the device (not on the server). Each secret is encrypted with a 256-bit AES key, and then encrypted again by another AES-256 Application Key.

In addition to Zero-Knowledge encryption, every request to the server is additionally encrypted with an AES-256 Transmission Key on top of TLS to prevent MITM or replay attacks. This multi-layered cryptography is handled transparently using our client-side SDKs which are easy to integrate into any environment.

High Availability and Local Cache

Keeper's infrastructure serves requests for millions of users and tens of thousands of Enterprise customers every day.

Keeper Secrets Manager benefits from the existing Keeper platform architecture in addition to an optional offline caching mechanism in all Secrets Manager SDK endpoints.

Each client device platform provides an optional local caching components. If the Keeper endpoint is unavailable, the Client Device will pull the last requested Secrets from a local encrypted cache.

Encryption Model

More details about the security and encryption model are available here.

Secrets Manager Structure

In order to organize and maintain access to Secrets, Keeper Secrets Manager uses structures called Applications and Clients.

Read below about how each of these items function in Secrets Manager.

Secret

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

Any record or shared folder from the vault can be shared with an Application.

Application

Keeper Secrets Manager Applications are assigned to specific secrets or shared folders. The application is a container of permissions, client devices, audit trail, and history. An application can only decrypt the records assigned.

Keeper recommends implementing the principle of least privilege, ensuring client devices only have access to the records they need. Although the user of the Vault can have unlimited secrets, Keeper recommends sharing up to 500 records per application for optimal performance.

An example of an Application would be a Production Github Actions pipeline or Jenkins server.

Client Device

A Client device is any endpoint that needs to access secrets associated with an Application. This can be a physical device, virtual device, or cloud-based device. A client device can also be identified by any software application running in the cloud or CI/CD tool.

Each Client device has a unique key to read and access the secrets.

Clients adhere to the following:

• One Time Access Tokens used for initialization that expire after 24 hours

• IP Address lock (optional)

• Access expiration (optional)

An example of a Client Device would be a development machine, Terraform script or a Github Actions instance. At least one client device is required to access secrets that are associated with an Application. Multiple client devices can be associated with the same Application.

Configuration

A Secrets Manager "Configuration" is a set of tokens that includes encryption keys, client identifiers and destination server information used to authenticate and decrypt data from the Keeper Secrets Manager APIs.

Secrets Manager configurations are created from One Time Access Tokens and have a one to one relationship with client devices.

A configuration can be stored as a text file with JSON, or it can be encoded into a single line string.