Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Security and encryption model of the Keeper Router
Keeper Router ("Router") is a cloud service hosted in Keeper's cloud environment which facilitates communications between the Keeper backend API, end-user applications (Web Vault, Desktop App, etc.), and Keeper Gateways installed in the user’s environment. The Router is responsible for communications that perform resource discovery, password rotation, timed access and privileged connection management.
In traditional or legacy privileged access products, the customer is responsible for installing on-prem software which is difficult to manage and configure in a cloud environment. In Keeper's model, a hosted service (called a Gateway) is installed into the customer's environment which establishes an outbound secure connection to the Keeper Router, enabling bi-directional communication to the Keeper cloud without any network configuration. Keeper Router makes cloud access to on-prem infrastructure easy and secure by utilizing WebSockets for the inbound requests.
With Keeper, WebSockets are established between the end-user device (e.g. Web Vault) and the Keeper Router using the user's current session token. The session token is verified by the Keeper Router to authenticate the session. All encrypted payloads sent to the Keeper Router are wrapped by a 256-bit AES transmission key in addition to TLS, to protect against MITM attacks. The transmission key is generated on the end-user device and transferred to the server using ECIES encryption via the Router's public EC key.
When a user on their Web Vault or Desktop App triggers a password rotation, discovery job or remote connection, the message flow is the following:
Upon installation of the Gateway, it authenticates with the Keeper Cloud using a 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 sent to the Keeper Router and signed with the Client Device Private Key.
The Gateway establishes an authenticated WebSocket connection using the Client Device Private Key and ECDSA signature.
The Vault sends a message to the Keeper Router with a command to execute (rotation, tunnel, discovery, connection) and authenticates the command using the user's active session token.
The Vault only transmits command and control messages, for example: Rotate UID XXX
. No secret information is communicated between Vault and Router. The Router authenticates the command using the session token of the record's rotation configuration to validate the user's request.
The Router relays the command to the destination gateway through the existing WebSocket connection.
The Gateway retrieves secrets, admin credentials, record details and other private data by using Keeper Secrets Manager APIs. 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.
The Gateway uses Keeper Secrets Manager "update" commands to update the user's vault with any password or discovery job updates.
After a rotation or discovery job is complete, the Gateway informs the Router that the job is complete. ARAM event logs are triggered by the Router.
The Keeper Router architecture is Zero Knowledge, and Keeper's infrastructure never has the ability to access or decrypt any of the customer's stored vault data.
The Router consists of two logical deployments that work together - the Head and the Workers.
The Router is hosted in Keeper’s AWS cloud environment, isolated to each of the global regions (US, EU, CA, AUS, JP, and US Gov).
The Head is not exposed to the internet, and performs the following functions:
Synchronization of global state between Workers
Inter-worker communication
Scheduling of events (e.g. rotation, discovery and connection requests)
The Workers connect to the Head via WebSocket and also use REST API calls to retrieve information. The Workers perform the following functions:
Communication with Gateways
Communication with Keeper end-user applications
Communication with Keeper backend API
Communication with Head
Workers are scaled and load balanced in each Keeper environment. Access to the Keeper Router is established through a common URL pattern in each region:
US: https://connect.keepersecurity.com
EU: https://connect.keepersecurity.eu
AU: https://connect.keepersecurity.com.au
CA: https://connect.keepersecurity.ca
JP: https://connect.keepersecurity.jp
US GOV: https://connect.keepersecurity.us
The end-user device will always communicate through the same Router instance. When the end-user vault connects to the Router system, a communication exchange is performed to ensure that the vault is communicating to the desired gateway. Once the Gateway communication is established, a Cookie is stored locally on the user's browser which expires automatically in 7 days. This Cookie is only used to establish a sticky session with the target Router instance, and does not contain any secret information.
Each Gateway device is associated with a unique UID. The Gateway UID is stored within an encrypted “PAM Configuration” record in the administrator's vault. This way, the Keeper vault record knows which Gateway must be used to perform the requested rotation, discovery or connection features.
Security and encryption model of the Keeper Gateway service
The Keeper Gateway is a service that is installed on-premise in order to execute rotation, discovery and connection tasks. The Keeper Gateway communicates outbound to the Keeper Router using WebSockets and Keeper Secrets Manager zero-knowledge protocols.
The Keeper Gateway authenticates first to the Keeper Router using the One Time Access Token provided upon installation of the Gateway service on the target machine. After the first authentication, subsequent API calls to the Router authenticate using a Client Device Identifier (which is the HMAC_SHA512 hash of the One Time Access Token).
For accessing and decrypting vault records, the Keeper Gateway uses standard Keeper Secrets Manager APIs which perform client-side encryption and decryption of data. The security model of Keeper Secrets Manager ensures least privilege and zero knowledge by allocating only specific folders and records that can be decrypted by the service. 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.
Like any other Secrets Manager device, access can also be restricted based on IP address in addition to the encryption and signing process.
Rotations can be performed on-demand or on a schedule. When an on-demand rotation, connection or discovery job is triggered by a user in the Web Vault or Desktop App, the Keeper Router uses the active WebSocket connection to the appropriate Gateway to receive instructions. The messages do not contain any secret information or encrypted ciphertext. All messages sent through the WebSocket contain only the command type (e.g. "rotate") and the affected Record UID ("UID") which is not a secret value.
For scheduled rotations, the same mechanism is used. Rotation schedules are tracked in the Router, and at the appropriate intervals rotation instructions are pushed to the Gateway. When the Gateway receives a rotation task, it uses the local KSM configuration to fetch the secrets associated with the provided Record UIDs and decrypts the record information locally. These secrets are in turn used to perform the rotation, discovery or connection.
When the Gateway service is installed, the local KSM configuration is protected by permissions on the local file system. By default, the configuration will be stored in the home directory (.keeper
folder) of the user that installed the Gateway.
The Docker installation method passes in the configuration through an environment variable in the Docker Compose file.
If Gateway is started as a user:
Config file: ~/.keeper/gateway-config.json
Logs folder: ~/.keeper/log
If Gateway is running as a service:
User: keeper-gateway-service
Config file: /etc/keeper-gateway/gateway-config.json
Logs folder: /var/log/keeper-gateway
If the Gateway is started via Command Line
Logs location: C:\Users\[USER NAME]\.keeper\logs\
Config File location: C:\Users\[USER NAME]\.keeper\gateway-config.json
If Gateway is started as a Windows Service
Logs location: C:\ProgramData\KeeperGateway\
Config File location: C:\ProgramData\KeeperGatewayPrivate\
Note: This folder can only be accessed by the user who installed the Gateway Service.
Access to the KSM configuration file allows a user to retrieve any associated secrets from Keeper. To prevent unauthorized access, this configuration file is only readable by the installing user and administrative accounts. On a Windows server, the Windows System account is used to run the service by default, and also has access to the KSM configuration.
In AWS environments, the configuration can be protected with the AWS KMS.
Caching is used for discovery but not for rotation. Every time a secret is rotated, the Gateway retrieves associated records in real time using the Keeper Secrets Manager APIs.
The Gateway includes a virtual command shell. When the Gateway is run as a stand-alone application, the user is dropped into the shell. When the Gateway is run as a service, the shell is not accessible.
An SSH service is bundled with the Gateway to provide advanced debug access to the shell. The SSH service is not running by default, and there is no way to access the shell while it is disabled. When the Gateway service is started, an optional argument can be supplied to enable the SSH service component. When the SSH service is enabled, by default there are no accounts that can connect to it. A system administrator must create a key pair with an account to utilize SSH.
The Gateway shell does not provide commands to interact directly with secrets.
Keeper Commander can also be used to access the Gateway for troubleshooting. This leverages the connection between the Gateway and the Router, and the associated security mechanisms. For example, Commander can send a command to the Router to retrieve a list of running tasks on the Gateway. These commands can be used with any Gateway in the same enterprise as the Commander user.
Any secrets that are retrieved during rotation are automatically scrubbed from log messages produced by the Gateway. This includes accidental logging, such as stack traces.
Keeper Gateway supports the ability to execute admin-generated scripts in PowerShell and Bash for performing customized behaviors after a successful rotation has taken place. The script is provided to the Gateway through a file attachment in the corresponding Keeper record. Post-Rotation scripts are categorized differently from general file attachments, and only the record owner has the ability to attach post-rotation scripts on the corresponding record.
The script is decrypted by the Gateway and then executed on the Gateway. Connections to secondary devices, for the purpose of restarting services, etc., must be orchestrated within the post-rotation script.
Obviously, the script which is uploaded to the Keeper record and executed on the gateway must be protected from malicious abuse. Keeper Administrators need to ensure that least privilege is assigned to the Keeper record.
When Post-Rotation scripts are run, stdout and stderr output from the script are written to disk in logs. Secrets are also automatically scrubbed from this output. Record UIDs can be logged in this way for diagnostic purposes. The Post-Rotation script can be written with any arbitrary code, however the Keeper Gateway provides the script with minimal information required to perform standard use cases through the command-line parameters. This includes the following parameters:
PAM Rotation Record UID (contains environment settings)
Resource Record UID (contains target resource data)
Account Record UID (the record that was rotated)
Old Password (from Account Record)
New Password (from Account Record)
Username (from Account Record)
After the command is executed, Keeper Gateway clears the command line history on Linux and Windows instances.
If a Post-Rotation script requires access to other secrets beyond those passed in automatically, users are strongly encouraged to use the Keeper Secrets Manager SDKs or the Secrets Manager CLI tool.
Security and encryption model of Connections and Tunnels
KeeperPAM provides the capability to establish cloud and on-prem privileged sessions, create tunnels, establish direct infrastructure access and secure remote database access.
A Connection is a visual remote session using the web browser. Interaction between the user and the target device is with a web browser window or within the Keeper Desktop application.
A Tunnel is a TCP/IP connection that is established between the local vault client through the Keeper Gateway to the target endpoint. The user can utilize any native application for communicating with the target endpoint, such as the command-line terminal, GUI application or database management application.
When the user establishes a connection or tunnel:
The Vault Client application communicates to the Keeper Router infrastructure to initiate a WebRTC connection that is protected by a ECDH symmetric key that is stored inside the relevant Keeper record.
The Keeper Gateway communicates with the Keeper Router through outbound-only WebSockets. This is described in detail in the Gateway Security section.
The Keeper Gateway utilizes Keeper Secrets Manager APIs to retrieve the necessary secrets from the vault, including the ECDH symmetric key.
For Connections, the Vault Client (using the Apache Guacamole protocol) passes data through the WebRTC connection to the Keeper Gateway that then uses Guacd to connect to the destination found in the Keeper record.
For Tunneling features (port forwarding), a local port is opened up on the local device running Keeper Desktop software. Data sent to the local port is transmitted through the WebRTC connection to the Keeper Gateway and subsequently forwarded to the target endpoint defined in the Keeper record.
Session recordings of connections are protected by an AES-256 encryption key ("recording key") which is generated on the Keeper Gateway on every session. The recording key is additionally wrapped by a HKDF-derived AES-256 resource key.
Features included with the PAM License
In order to enable and use KeeperPAM, the following are required:
Privileged Access Manager Add-On
A minimum of 5 seats
A Keeper Enterprise License must be purchased prior to purchasing the Privileged Access Manager (PAM) add-on.
If you are not a Keeper customer or do not have the required license, you can start a free enterprise license trial. The enterprise trial will also include the Privileged Access Manager Add-on.
With the purchase of the Privileged Access Manager Add On, the following features are included:
Every feature included with the Keeper Enterprise License
Secrets Manager - Unlimited API Calls
Password Rotation
Connections
Tunnels
Remote Browser Isolation
Session Recordings and Playback
Discovery
Keeper Connection Manager (Self-Hosted)
PAM Audit and Reporting
KeeperPAM is a cloud-native privileged access solution that requires only a lightweight gateway installation, while Keeper Connection Manager (KCM) is a fully self-hosted solution. For more information, visit this page.
The KeeperPAM license includes all the features of the Keeper Enterprise License along with the advanced PAM Features. The number of licenses for the enterprise license and the KeeperPAM license is based on:
Enterprise License
Number of Users using the Enterprise Features
Privileged Access Manager Add On
Number of Users using the Enterprise Features AND PAM Features
For example, if an organization has 100 users and needs PAM functionality for only 10 of them, they would purchase:
90 Keeper Enterprise Licenses for users who only need the enterprise features.
10 Privileged Access Manager Add-Ons, which include both Enterprise and PAM features.
Features available with the KeeperPAM Add-On are listed here.
For existing customers, the following existing Add-ons can be updated to the Privileged Access Manager Add-On:
Keeper Secrets Manager Add-On
Keeper Connection Manager Add-On
Both the Keeper Secrets Manager and Keeper Connection Manager Add On are included as part of the Privileged Access Manager Add-On.
Upgrading to the Privileged Access Manager Add-On from the Keeper Secrets Manager Add-On will give you:
Access to new KeeperPAM Features
Unlimited API Calls
Upgrading to the Privileged Access Manager Add-On from the Keeper Connection Manager Add-On will give you new KeeperPAM Features which includes accessing both the cloud and self-hosted KCM.
To purchase, upgrade, or if you have any questions, contact your Keeper account manager or use our online form.
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Instructions for installing and configuring the Auto Updater for the Keeper Gateway.
Automatic updates of the Keeper Gateway can be enabled on Linux and Windows installations through Keeper's Auto Updater feature. The Auto Updater makes periodic checks to update your Keeper Gateway to the latest version.
By default, the Auto Updater is disabled when installing the Keeper Gateway
We recommend enabling the Auto Updater to ensure you receive the most recent security and functionality enhancements. The Auto Updater verifies all Keeper Gateway downloads by checking the GPG signature of hash value, which are then utilized to checksum each file.
Ensure that you have administrative privileges on the system.
Version 1.4.0 or later of Keeper Gateway is required.
On Docker based installations, the best way to update the container is running the below commands from a cron job or your CI/CD tools.
As an example, create a file called update_gateway.sh
that contains:
Replace /path/to/your/docker-compose-directory
with the directory containing your docker-compose.yml
.
The set -e
ensures the script exits if any command fails.
Make the script executable:
Edit the crontab:
Add a line to schedule the script. For example, to run it every day at 3 AM:
Execute the following command to download and run the KeeperPAM Preview installer with auto update enabled.
The --autoupdate
parameter activates the auto updater in addition to the Keeper Gateway.
Activate the Auto Updater on an existing installation by executing the following Keeper Gateway command:
Verify Installation (Optional)
Verify that the Auto Updater has been installed successfully by executing the following Keeper Gateway command:
Download and run the latest version of the Gateway installer.
During installation, check the box "Enable automatic updates".
This setup option will create a new Task Scheduler task for updating the Gateway.
Existing Gateway
Open a command prompt as Administrator.
Install Auto Updater with the following Keeper Gateway command:
Verify Installation (Optional)
Open a command prompt as Administrator.
Verify that Auto Updater has been installed successfully by executing the following Keeper Gateway command:
Ensure that you have administrative privileges on the system.
Version 1.4.0 or later of Keeper Gateway is required.
Check the Auto Updater status by executing the following Keeper Gateway command:
Open a command prompt as Administrator
Check the Auto Updater status by executing the following Keeper Gateway command:
Edit the crontab that runs Auto Updater.
Here is an example of the default crontab entry that checks for updates every hour:
The first part 0 * * * *
is the crontab expression which will cause execution to occur every hour at 0 minutes.
The second part is the update command keeper-gateway-update
The option --trust
causes explicit trust of the Keeper Gateway GPG public key for verification of downloaded install files.
Configure the update frequency and other settings with the following steps:
Run taskschd.msc
to open Windows Task Scheduler.
In the left pane double-click on Task Scheduler Library -> Keeper -> Gateway -> AutoUpdate to show the Auto Updater Task.
In the upper middle pane double-click on the AutoUpdate Task with the name of the current version and click on the Triggers menu tab.
Click Edit...
to change when the Auto Updater checks for a new update to install. The default is to "Repeat task every 1 hour indefinitely" as shown below.
Ensure that you have administrative privileges on the system.
Version 1.4.0 or later of Keeper Gateway is required.
Remove Auto Updater by executing the following Keeper Gateway command:
Remove Auto Updater with the following steps:
Open a command prompt as Administrator.
Remove Auto Updater with the following Keeper Gateway command:
To assist with diagnosing issues or monitoring the status of updates, the Gateway Auto Updater generates two types of logs. These logs are subject to rotation policies to avoid overuse of disk space.
Log Location
All log files for Linux are located in /var/log/keeper-gateway
Log Files
Update Logs:
Any logs generated during an update will be timestamped and stored as update_YYYY-MM-DD_HH-MM-SS.log
.
Last Update Check:
The file last-update-check.log
contains information regarding the most recent check for updates.
The log files for the Gateway Auto Updater are located in \ProgramData\KeeperGateway\install
Log Files
Update Logs:
Any logs generated during an update will be timestamped and stored as YYYY-MM-DD_HH-MM-SS.log
Last Update Check:
The file last-update-check.log
contains information regarding the most recent check for updates.
Advanced Keeper Gateway Configurations
This section will cover additional configurations to modify the Keeper Gateway's default behavior.
The following are supported configurations for the Keeper Gateway:
Loading...
Loading...
Loading...
Loading...
Loading...
Setting up your Local environment to work with KeeperPAM
The PAM Configuration contains critical information on your local infrastructure, settings and associated Keeper Gateway. This guide provides step-by-step instructions for configuring the PAM Configuration in your local environment, enabling the Keeper Gateway to manage all resources within it and allowing users to utilize KeeperPAM features on those resources.
Prior to proceeding with this guide, make sure to install and configure your Keeper Gateway.
To create a new PAM Configuration:
Login to the Keeper Vault
Select Secrets Manager and the "PAM Configurations" tab
Click on "New Configuration"
The following tables provides more details on each configurable fields in the PAM Configuration record for the local environment:
Title (Required)
Name of PAM configuration record
Ex: Local Configuration
Environment (Required)
Your infrastructure's environment
For this guide, select "Local"
Gateway (Required)
The configured gateway
Application Folder (Required)
The shared folder where the PAM Configuration data will be stored
Best practice is to create a folder with limited access to admins. See Security Note (1) below
PAM Settings (Required)
List of Zero-Trust KeeperPAM features that should be enabled
Default Rotation Schedule
Specify frequency of Rotation
Ex: Daily
Port Mapping
Define alternative default ports
For Discovery, the following fields are required, otherwise they are optional:
Network ID
Unique ID for the network
This is for the user's reference
Ex: My Network
Network CIDR
Subnet of the IP address
The "PAM Features Allowed" and "Session Recording Types Allowed" sections in the PAM Configuration allow owners to enable or disable KeeperPAM features for resources managed through the PAM configuration:
Rotation
If enabled, allow rotations on privileged user users managed by this PAM configuration
Connections
If enabled, allow connections on resources managed by this PAM configuration
Remote Browser Isolation (RBI)
If enabled, allow RBI sessions on resources managed by this PAM configuration
Tunneling
If enabled, allow tunnels on resources managed by this PAM configuration
Graphical Session Recording
If enabled, visual playback sessions will be recorded for all connections and RBI sessions
Text Session Recording (TypeScript)
If enabled, text input and output logs will be logged for all connections and RBI sessions
After creating the PAM configuration, visit the following pages to:
Configure Rotation
Configure Connections
Configure RBI
Configure Tunnels
Configure Discovery
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
KeeperPAM is a modern, cloud-based Privileged Access Manager
KeeperPAM is a next-gen privileged access management solution that secures and manages access to critical resources, including servers, web apps, databases and workloads.
KeeperPAM consolidates enterprise password management, secrets management, connection management, zero-trust network access, remote browser isolation and an cloud-based access control plane in one unified product.
To learn more about KeeperPAM or sign up for a trial:
KeeperPAM is a cloud-native privileged access solution that requires only a lightweight gateway installation, while Keeper Connection Manager (KCM) is a fully self-hosted solution.
KeeperPAM works through outbound-only connections with zero-knowledge encryption, eliminating the need for inbound firewall rules or direct line-of-sight to resources. In contrast, KCM is fully hosted by the customer with control over the authentication, database, web server, reverse proxy and session recordings.
In summary, KeeperPAM is designed for organizations embracing cloud transformation and zero-trust security, while KCM serves specialized use cases requiring full infrastructure control, such as classified environments or those with specific compliance requirements like PIV/CAC authentication.
Several new and exciting capabilities of KeeperPAM are now available in Preview:
Zero-trust connections launched from the Vault
Tunnels established from the Desktop App for ZTNA
Sharing connections without exposing credentials
Sharing tunnels on a time-limited basis
Built-in SSH Agent for use with and without tunneling
Launching remote browser isolation sessions
Session recording and playback
File transfer with drag-and-drop
Splitting credentials between PAM Resources and PAM Users
Discovery of resources
All new Keeper Gateway setup wizard
Docker-based deployment of the Keeper Gateway
Role-based enforcement policies covering PAM use cases
Event reporting of all PAM activity with SIEM integration
Unified with the Keeper Vault: Keeper PAM features integrates directly with the Keeper Vault, offering a centralized, secure platform for managing credentials, connections, and privileged access.
Zero-Knowledge Security: Built on a zero-knowledge architecture, KeeperPAM ensures that only the end user can access their data, with no visibility or access for Keeper itself.
Agentless Deployment: With a simplified setup process, KeeperPAM requires only the deployment of a single gateway in each target environment, using agentless protocols to manage infrastructure.
Credential-less Sharing: Users can securely share access to connections without exposing passwords, enhancing both security and usability
Before jumping into the KeeperPAM advanced capabilities, we require that you first set up your Keeper Enterprise or Keeper MSP license and set up your basic environment.
Check out the Keeper Enterprise documentation
Deploy the Keeper Vault to your employees
If you are an existing customer, your customer success team can activate KeeperPAM in your account.
For technical questions during the Preview period, you can also email pam@keepersecurity.com which routes to our engineers.
This documentation is broken out into 3 sections:
Additional documentation on the Keeper platform can be found here:
Learn about the new KeeperPAM Preview
Launch the Quick Start: Sandbox
Deep dive into the Getting Started guide for KeeperPAM
Technical details on the KeeperPAM platform architecture
KeeperPAM is a Zero-Knowledge platform, ensuring that encryption and decryption of secrets, connections, and tunnels occur locally on the end user's device through the Keeper Vault application. Access to resources in the vault is restricted to users with explicitly assigned permissions, enabling them to establish sessions or tunnels securely.
Keeper's zero-trust connection technology further enhances security by providing restricted and monitored access to target systems without direct connectivity, while never exposing underlying credentials or secrets.
This security content will cover the key areas of KeeperPAM:
Getting Started with KeeperPAM fundamentals
Setting up a basic Remote Browser Isolation record for protecting web-based applications
KeeperPAM remote browser records ensure safe access to internal and cloud apps via a protected browser inside the vault. This browser is shown from the Keeper Gateway to the Keeper Vault, isolating the session for zero-trust access.
This quick guide extends the sandbox that you created in the Quick Start Wizard to add a remote browser isolation resource in the vault.
Below are screenshots of the Remote Browser Isolation setup from start to finish.
Quickly and easily get started with a pre-configured PAM setup in your vault
To learn some KeeperPAM basics, we have created a wizard that is integrated into the Vault Preview. If you select the Docker install method, this wizard will create all the necessary vault records, configurations and a customized Docker Compose file for quickly standing up a sandbox environment.
Login to the Keeper Vault Preview version. If the policies are active, you'll see a Secrets Manager tab on the left side.
Click on Create New > Gateway
Enter a name for the project, such as "My Infrastructure Demo"
Select Docker for the gateway
Select "Create with example records"
Click Next
After the wizard is finished, immediately download the provided docker-compose.yml
and docker-seccomp.json
files.
Set up a Linux VM in any target environment which supports Docker, such as an Amazon Linux 2 instance or similar.
If necessary, Install Docker per the Docker installation instructions.
Transfer the 2 files from Step 2 to any Linux instance.
Run "docker-compose up" from the folder where the files are saved.
The wizard will create the following in your vault:
A folder containing Resources and Users in separate shared folders
A MySQL database
A Linux machine with VNC connection to the desktop UI
A Linux machine with SSH connection using an SSH Key
A Linux machine with SSH connection using a password
A Linux machine with RDP connection to the desktop UI
A Remote Browser Isolation session to bing.com
A Secrets Manager Application and PAM Configuration with all PAM features enabled
A Keeper Gateway ready to initialize
Below are screenshots of the Quick Start Wizard from start to finish.
Accessing the new KeeperPAM platform in Preview
The KeeperPAM Preview offers customers early access to test and prepare for the upcoming official launch. During the preview period, we are releasing weekly updates that include bug fixes, performance improvements, and new features.
Preview features are accessed using the links below.
Mac (.dmg) - Download
Mac (.pkg) - Download
Windows (.appx) - Download
Windows (.msix) - Download
Windows (.msi) - Download
Linux (.rpm) - Download
Linux (.deb) - Download
Note: the Desktop App preview does not auto-update. On Windows computers, a new version of the preview version requires a full uninstall and re-install of Keeper. This does not affect stored data.
GOV: Not available for preview, use commercial environment
Follow the below steps to start using the new KeeperPAM Preview.
If you are not a Keeper customer or do not have the required license, you can start a free trial from our website.
From the Admin Console Preview, ensure that your Keeper Secrets Manager subscription is active. If you have never started a trial of Secrets Manager, you can click on Start Free Trial from the "Secrets Manager" tab.
From the Admin Console Preview, enable the corresponding PAM Enforcement Policies.
Login to the Admin Console Preview for your region.
Under Admin > Roles, create a new role for PAM or modify an existing role
Go to Enforcement Policies and open the "Privileged Access Manager" section.
Enable all the PAM enforcement policies to use the new features.
Assign yourself or your test user account to this role.
This assumes you are an existing customer with Keeper Secrets Manager and you have a Gateway already deployed for testing. The Preview version of the Keeper Gateway is required to support the new features. Depending on the operating system, features available will differ.
Download the new installer preview version: 64-bit Installer (preferred) or 32-bit Installer
You'll be asked to confirm uninstalling the previous Gateway, this is OK
Ensure the "Enter one-time access token" selection is NOT selected
To update an existing Gateway on Linux:
Use the basic docker-compose.yml
file as shown below:
If you are replacing an existing Gateway, you can pull the old base64 configuration string from /etc/keeper-gateway/gateway-config.json
on Linux or C:\ProgramData\KeeperGateway\config\gateway-config.json
on Windows.
Download the file called docker-seccomp.json
and place it in the same folder as your Docker Compose file.
If you have never set up a Keeper Gateway, please follow the step by step guide in the Getting Started section of this documentation. A new Quick Start Wizard is available to instantly create a sandbox for testing out a few of the connection types.
PAM Features differ between Linux, Docker and Windows versions of the Keeper Gateway.
For a full range of features, use the Docker installation method, or Linux installation method on Rocky Linux or RHEL8.
We recommend setting up a Keeper Gateway using the new Quick Start Sandbox. This provides a customized Docker Compose file that provides an instant sandbox for testing.
Please email us at pam@keepersecurity.com with your feedback and we'll assist you with any questions or 1:1 configuration help.
Keeper Password Rotation architecture diagram and data flow
The KeeperPAM infrastructure and security model ensures zero-knowledge encryption between the end-user's device and the target infrastructure. Keeper's servers have no ability to decrypt or intercept the underlying sessions.
The Keeper Gateway is a service which is installed into the customer's environment and communicates outbound to Keeper services. The Gateway performs the rotation, discovery and connections to assets on the network. The Gateway receives commands from the Keeper Router, then uses Keeper Secrets Manager APIs to authenticate, communicate and decrypt data from the Keeper cloud.
The Keeper Router is infrastructure in Keeper's cloud that manages connections between Keeper and Rotation Gateways. The Cloud Router provides real-time messaging and communication between the Keeper Vault, customer gateway and Keeper backend services.
The Keeper Relay is infrastructure in Keeper's cloud that is responsible for establishing encrypted WebRTC connections between the end-user vault interface and the customer-hosted Keeper Gateway service.
Keeper's Backend API is the endpoint which all Keeper client applications communicate with. Client applications encrypt data locally and transmit encrypted ciphertext to the API in a Protocol Buffer format.
Keeper hosted infrastructure that manages timing and logistics around scheduled rotation of credentials across the target infrastructure.
The Management console used to set and enforce policies across all Keeper components.
The end-user interface for managing the vault, rotating passwords, running discovery jobs, creating connections and managing tunnels.
Keeper user performs action (rotation, connection, tunneling, discovery) from the Vault interface, Admin Console, Commander CLI or other endpoint application.
Keeper Gateway establishes an outbound WebSocket connection to the Keeper Router, receives the requests to perform the action.
The Vault Client application establishes a WebRTC connection to the customer's hosted Keeper Gateway.
The Keeper Gateway pulls the necessary secrets from the vault using Keeper Secrets Manager APIs.
The Keeper Gateway performs the action on the target infrastructure (such as rotating a credential) and updates the relevant Keeper vault records.
The Keeper Gateway runs any required privilege automation scripts on the Gateway or target machines using native protocols and APIs.
Client devices securely retrieve the updated record using Keeper Secrets Manager APIs.
Vault end-users receive push notifications indicating that new data is available for syncing.
The vault performs encrypted syncing to the Keeper cloud to retrieve the latest record content.
Keeper's Advanced Reporting & Alerts module logs all events and triggers alerts.
Security and encryption model of the Keeper Vault
Keeper's platform is built with End-to-End Encryption (E2EE) across all devices and endpoints.
Data stored in the platform is encrypted locally and encrypted in transit between the user's devices
Information exchanged between Keeper users is encrypted from vault-to-vault
Data at rest is encrypted with multiple layers, starting with AES-256 encryption at the record level
Data in transit is encrypted with TLS and additional layers of transmission encryption which protects against access MITM, service providers and untrusted networks.
A full and detailed disclosure of all encryption related to data at rest, data in transit, cloud architecture and certifications can be found on the Keeper Enterprise Encryption Model page.
A video covering this model is below.
Keeper’s allows MSPs and their Managed Companies (MCs) to allocate Keeper licenses to their users and pay only for used licenses at the beginning of the following month.
KeeperPAM will be a that MSPs can add or remove at any time for their Managed Companies.
Secrets Manager Applications with KeeperPAM
A Secrets Manager Application allows a machine or device to communicate with the Keeper vault, retrieve assigned records and decrypt the data.
Folders are shared to the application, similar to how users are folders are shared to users. This gives the application the capability of accessing and decrypting the records in the folder.
From the Keeper Vault, go to Secrets Manager and click on Create Application.
The Application Name typically represents the use case or environment where it is being used
The Folder selected is where the application is assigned. An application can be added to any number of shared folders.
Record permissions give the application either read-only or read/write access to the folder. This is an additional restriction on top of the existing shared folder permissions.
Click on Generate Access Token to create the first access token, representing the first device
If you don't plan to set up a device yet, the first access token can be discarded
When creating an application, a one-time access token for the first Device is provided. This one-time access token is supplied to the 3rd party system, Keeper Secrets Manager SDK, Keeper Secrets Manager CLI or other device which needs to access information from the vault.
After creating the application, it is managed from the Secrets Manager screen. You can then assign additional devices or Keeper Gateways.
Applications can be added to new or existing Shared Folders.
Edit the Shared Folder to assign the application.
By assigning the Application to shared folders, the application's devices can send Keeper Secrets Manager API requests to the Keeper vault to access and manage the records assigned. There are many use cases where a device can use Keeper Secrets Manager APIs to communicate with the Keeper vault. Below are a few examples.
Keeper Gateways are created and associated to an application. To create a new Gateway, open the application and click on the "Gateways" tab. Select "Provision Gateway" to create a Gateway.
Alternatively, Keeper provides a wizard that creates several components at once, and automatically links everything together. From the main vault screen, select "Create New" then "Gateway".
The "Project Name" is used to create a PAM Configuration, Gateway, Application and optionally a set of example folders and records.
KeeperPAM migration of records to new linked format
As part of the KeeperPAM product launch, newly created resources in the Keeper Vault—such as PAM Machines, PAM Directories, and PAM Databases—will no longer support embedding credentials directly within the resource. Instead, KeeperPAM now utilizes Record Linking, where the credential record is securely linked to the resource. This approach ensures a clear separation of encryption and permissions between the resource and its associated credentials.
With Record Linking, resources can be shared with users without exposing the underlying credentials, enhancing both security and access control.
For customers currently using Keeper Secrets Manager with rotation capabilities, if a credential is embedded directly in a resource, a new section will appear when editing the record. This section will display the message:
"We moved your rotating credentials down below. Please convert these credentials into a PAM User record type."
This update guides users to transition their rotating credentials into the more secure PAM User record type for enhanced security and proper separation of credentials from resources.
By clicking "Convert Now", you'll be asked to confirm the change and the credentials will be separated from the resource and placed in the same folder.
Click "Next" to finish the conversion. After this is completed, a new record in the same folder will contain the linked credential.
Once the resource has been split, PAM capabilities including connections, tunnels and rotations can be enabled.
Keeper Secrets Manager Devices with KeeperPAM
A Device can be any machine, application or endpoint that has the ability to communicate with the Keeper platform, authenticate and decrypt data that has been provisioned.
Applications have any number of devices associated. Each device has a unique identifier so that it can be tightly controlled and managed. Devices authenticate and decrypt data using a API and encryption model as defined in the Keeper Secrets Manager Security & Encryption model page.
See the Security & Encryption Model of a Device
A device can be created through the Applications section of the vault user interface or through the Keeper Commander CLI.
From the Vault user interface, go to Secrets Manager and select the Application. Then select the Devices tab and click "Add Device".
A Keeper device can be initialized through either a One-Time Access Token or a pre-built configuration file in either base64 or JSON format.
The One-Time Access Token is an encryption key used by a device for only one authentication to the cloud. After that, a local configuration is created with all of the necessary keys for subsequent authentications and decryption of the resulting vault ciphertext. The Keeper Secrets Manager SDKs and many out of the box integrations utilize this method.