Architecture Diagram

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.

Components

Keeper Gateway

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.

Keeper Router

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.

Keeper Relay

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 Backend API

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.

Scheduler

Keeper hosted infrastructure that manages timing and logistics around scheduled rotation of credentials across the target infrastructure.

Admin Console and Control Plane

The Management console used to set and enforce policies across all Keeper components.

Client Applications

The end-user interface for managing the vault, rotating passwords, running discovery jobs, creating connections and managing tunnels.

Data Flow

1. Keeper user performs action (rotation, connection, tunneling, discovery) from the Vault interface, Admin Console, Commander CLI or other endpoint application.

2. Keeper Gateway establishes an outbound WebSocket connection to the Keeper Router, receives the requests to perform the action.

3. The Vault Client application establishes a WebRTC connection to the customer's hosted Keeper Gateway.

4. The Keeper Gateway pulls the necessary secrets from the vault using Keeper Secrets Manager APIs.

5. The Keeper Gateway performs the action on the target infrastructure (such as rotating a credential) and updates the relevant Keeper vault records.

6. The Keeper Gateway runs any required privilege automation scripts on the Gateway or target machines using native protocols and APIs.

7. Client devices securely retrieve the updated record using Keeper Secrets Manager APIs.

8. Vault end-users receive push notifications indicating that new data is available for syncing.

9. The vault performs encrypted syncing to the Keeper cloud to retrieve the latest record content.

10. Keeper's Advanced Reporting & Alerts module logs all events and triggers alerts.

Overview

Role-based Access Controls (RBAC) provide your organization the ability to define enforcements based on a user's job responsibility as well as provide delegated administrative functions. Prior to proceeding with this guide, familiarize yourself with roles and enforcement policies.

Enable PAM Policies

From the Admin Console, enable the corresponding PAM Enforcement Policies.

• Login to the Keeper Admin Console 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.

Privileged Access Manager Policies

Secrets Manager

ALLOW_SECRETS_MANAGER

Keeper Gateway

ALLOW_PAM_GATEWAY

Keeper Rotation

ALLOW_CONFIGURE_ROTATION_SETTINGS

ALLOW_ROTATE_CREDENTIALS

Keeper Connection Manager (KCM)

ALLOW_CONFIGURE_PAM_CLOUD_CONNECTION_SETTINGS

ALLOW_LAUNCH_PAM_ON_CLOUD_CONNECTION

ALLOW_VIEW_KCM_RECORDINGS

Keeper Tunnels

ALLOW_CONFIGURE_PAM_TUNNELING_SETTINGS

ALLOW_LAUNCH_PAM_TUNNELS

Remote Browser Isolation (RBI)

ALLOW_CONFIGURE_RBI

ALLOW_LAUNCH_RBI

ALLOW_VIEW_RBI_RECORDINGS

Discovery

ALLOW_PAM_DISCOVERY

Legacy Policies

These policies are not required moving forward, but they exist for support of legacy features.

ALLOW_PAM_ROTATION

Commander CLI

The Keeper Commander CLI enterprise-role command can be used to set these policies through automation. The list of policies related to PAM functionality is listed below.

enterprise-role ROLE_ID --enforcement "ALLOW_SECRETS_MANAGER:True"
enterprise-role ROLE_ID --enforcement "ALLOW_PAM_ROTATION:True"
enterprise-role ROLE_ID --enforcement "ALLOW_PAM_DISCOVERY:True"
enterprise-role ROLE_ID --enforcement "ALLOW_PAM_GATEWAY:True"
enterprise-role ROLE_ID --enforcement "ALLOW_CONFIGURE_ROTATION_SETTINGS:True"
enterprise-role ROLE_ID --enforcement "ALLOW_ROTATE_CREDENTIALS:True"
enterprise-role ROLE_ID --enforcement "ALLOW_CONFIGURE_PAM_CLOUD_CONNECTION_SETTINGS:True"
enterprise-role ROLE_ID --enforcement "ALLOW_LAUNCH_PAM_ON_CLOUD_CONNECTION:True"
enterprise-role ROLE_ID --enforcement "ALLOW_CONFIGURE_PAM_TUNNELING_SETTINGS:True"
enterprise-role ROLE_ID --enforcement "ALLOW_LAUNCH_PAM_TUNNELS:True"
enterprise-role ROLE_ID --enforcement "ALLOW_LAUNCH_RBI:True"
enterprise-role ROLE_ID --enforcement "ALLOW_CONFIGURE_RBI:True"
enterprise-role ROLE_ID --enforcement "ALLOW_VIEW_KCM_RECORDINGS:True"
enterprise-role ROLE_ID --enforcement "ALLOW_VIEW_RBI_RECORDINGS:True"

Overview

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:

• Architecture Diagram

• Vault Security

• Router Security

• Gateway Security

• Connection and Tunnel Security

Quick Start Wizard

To learn some KeeperPAM basics, we have created a wizard that is integrated into the Vault. 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 in less than 3 minutes.

Records Created

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

Quick Start Video

We've created a helpful Keeper 101 video to set up your sandbox environment:

Screenshots

Below are screenshots of the Quick Start Wizard from start to finish.

The Basics

• Architecture

• Licensing

• Enforcement policies

• Vault structure

• Record Linking

• Applications

• Devices

• Gateways

• PAM Configuration

• PAM Resources

• PAM Users

• Sharing and Access Control

KeeperPAM Features

• Password Rotation

• Connections

• Tunnels

• Remote Browser Isolation (RBI)

• Session Recording & Playback

• SSH Agent

• Discovery

• On-Prem Connection Manager

Secrets Manager Features

• Secrets Manager CLI

• Developer SDKs

• Integrations

Commander CLI Features

• Import and Export

• Reporting

• Enterprise Management

• Record Management

• Sharing

• KeeperPAM Commands

• Secrets Management Commands

• MSP Management Commands

• Miscellaneous Commands

Enterprise Password Manager

• Enterprise Admin Guide

Setup Steps

Follow the below steps to start using KeeperPAM.

services:
      keeper-gateway:
        platform: linux/amd64
        image: keeper/gateway:latest
        shm_size: 2g
        security_opt:
          - "seccomp:docker-seccomp.json"
        environment:
          ACCEPT_EULA: Y
          GATEWAY_CONFIG: XXXXXXXXXXXX

curl -fsSL https://keepersecurity.com/pam/install | sudo bash -s --

Notes

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

Feedback

Please email us at pam@keepersecurity.com with your feedback and we'll quickly assist you with any questions.

Overview

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 a cloud-based access control plane in one unified product.

To learn more about KeeperPAM or sign up for a trial:

About this Documentation

This documentation is broken out into 3 sections:

Additional documentation on the Keeper platform can be found here:

KeeperPAM vs. Keeper Connection Manager

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.

Customers who purchase KeeperPAM may use either the cloud version (described in this documentation) or the self-hosted connection manager as part of the license.

Features

KeeperPAM provides the following capabilities:

• 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

Contact the Keeper Team

If you are an existing customer, your customer success team can activate KeeperPAM in your account.

For technical questions, you can also email pam@keepersecurity.com.

Next Steps

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 .

A video covering this model is below.

KeeperPAM Licensing Requirements

In order to enable and use KeeperPAM, the following are required:

• or License

• • A minimum of 5 seats

A Keeper Business or Keeper Enterprise License is required to purchase the KeeperPAM add-on.

Trial License

If you are not a Keeper customer or do not have the required license, you can start a free . The enterprise trial will also include the Privileged Access Manager Add-on.

Features Included with KeeperPAM

With the purchase of the Privileged Access Manager add-on, the following features are included:

• 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

What is the difference between KeeperPAM and Keeper Connection Manager (Self-Hosted)?

KeeperPAM License Model

The KeeperPAM add-on license includes all the advanced PAM Features. The number of licenses for the enterprise license and the KeeperPAM license is based on:

Example

For example, if an organization has 100 Enterprise users and needs PAM functionality for only 10 of them, they would purchase:

• 100 Keeper Enterprise Licenses for users who only need the enterprise features.

• 10 Privileged Access Manager Add-Ons, to cover the 10 users that need PAM functionality.

MSPs

Existing Customers - Updating KSM/KCM Add-Ons

For existing customers, the following existing Add-ons can be upgraded 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-Ons are included as part of the Privileged Access Manager Add-On.

Upgrading from Keeper Secrets 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 from Keeper Connection Manager Add-On

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.

Ready to Upgrade?

Overview

KeeperPAM provides the capability to establish cloud and on-prem privileged sessions, create tunnels, establish direct infrastructure access and secure remote database access.

What is a Connection?

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.

What is a Tunnel?

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.

Connection and tunnel security

When the user establishes a connection or tunnel:

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

2. The Keeper Gateway communicates with the Keeper Router through outbound-only WebSockets. This is described in detail in the section.

3. The Keeper Gateway utilizes Keeper Secrets Manager APIs to retrieve the necessary secrets from the vault, including the ECDH symmetric key.

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

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

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

What is the Keeper Gateway?

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 .

Authentication of the Gateway

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

How does a Gateway fetch instructions?

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.

How is the local KSM Configuration secured?

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.

Docker Install

The passes in the configuration through an environment variable in the Docker Compose file.

Linux Install

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

Windows Install

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.

Data Caching

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 Shell

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.

Commander Remote Troubleshooting

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.

Secrets and Logging

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.

Post-Rotation Scripts

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.

Overview

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.

How does Keeper Router work?

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

Keeper Router Architecture

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.

Overview

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.

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.

Auto Updater Installation

Prerequisites

• Ensure that you have administrative privileges on the system.

• Version 1.4.0 or later of Keeper Gateway is required.

Docker

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:

#!/bin/bash
set -e  # Exit immediately if a command fails

# Navigate to the directory containing your docker-compose.yml file
cd /path/to/your/docker-compose-directory

# Pull the latest image and update the Gateway container
docker compose pull
docker compose up -d keeper-gateway

Make the script executable:

chmod +x update_gateway.sh

Edit the crontab:

crontab -e

Add a line to schedule the script. For example, to run it every day at 3 AM:

0 3 * * * /path/to/update_gateway.sh >> /var/log/update_gateway.log 2>&1

Linux

New Gateway

Execute the following command to download and run the KeeperPAM installer with auto update enabled.

The --autoupdate parameter activates the auto updater in addition to the Keeper Gateway.

curl -fsSL https://keepersecurity.com/pam/install | \
  sudo bash -s -- --autoupdate

Existing Keeper Gateway

Activate the Auto Updater on an existing installation by executing the following Keeper Gateway command:

sudo keeper-gateway autoupdate enable

Verify Installation (Optional)

Verify that the Auto Updater has been installed successfully by executing the following Keeper Gateway command:

sudo keeper-gateway autoupdate status

Windows

New Gateway

• 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:

keeper-gateway autoupdate enable

Verify Installation (Optional)

• Open a command prompt as Administrator.

• Verify that Auto Updater has been installed successfully by executing the following Keeper Gateway command:

keeper-gateway autoupdate status

Auto Updater Status

Prerequisites

• Ensure that you have administrative privileges on the system.

• Version 1.4.0 or later of Keeper Gateway is required.

Status on Linux

Check the Auto Updater status by executing the following Keeper Gateway command:

sudo keeper-gateway autoupdate status

Status on Windows

• Open a command prompt as Administrator

• Check the Auto Updater status by executing the following Keeper Gateway command:

keeper-gateway autoupdate status

Auto Updater Configuration

Configuration on Linux

Edit the crontab that runs Auto Updater.

sudo crontab -e

Here is an example of the default crontab entry that checks for updates every hour:

0 * * * * /usr/local/bin/keeper-gateway-update --trust

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

Configuration on Windows

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.

Auto Updater Removal

Prerequisites

• Ensure that you have administrative privileges on the system.

• Version 1.4.0 or later of Keeper Gateway is required.

Removal on Linux

Remove Auto Updater by executing the following Keeper Gateway command:

sudo keeper-gateway autoupdate disable

Removal on Windows

Remove Auto Updater with the following steps:

• Open a command prompt as Administrator.

• Remove Auto Updater with the following Keeper Gateway command:

keeper-gateway autoupdate disable

Troubleshooting

Check the status of the Auto Update

keeper-gateway autoupdate status

Logging in the Gateway Auto Updater

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.

Linux

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.

Windows

Log Location

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.

Overview

KeeperPAM supports integration with your SIEM provider to provide real-time event logging and monitoring of all privileged access management activity. In the Keeper Admin Console, alerts can also be configured based on any event.

For more information on activating SIEM integration from the Keeper Enterprise guide:

• See

Features

• Push over 200 different event types to any connected SIEM provider

• Send alerts to email, SMS, Webhook, Slack or Microsoft Teams on any event trigger

• Run custom reports from the Keeper Admin Console or Keeper Commander CLI

KeeperPAM Events

Events related to KeeperPAM include:

• Starting and stopping sessions, tunnels, remote browser isolation

• Gateway lifecycle (online, offline, added/removed)

• Connection lifecycle (creation, editing and deleting PAM resources)

Recommended Alerts

As a KeeperPAM administrator, it is useful to receive alerts related to Gateway actions, such as when a Gateway goes offline (in case of server outage or system restart).

From the Admin Console, go to Reporting & Alerts > Alerts > select Event Types and set the recipient information.

Event alert details will include the name and UID of the affected Keeper gateway.

Email alerts contain event information

Overview

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.

Conversion

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.

Overview

In a customer's environment, the Keeper Vault is deployed to all users within the organization across all devices. The Vault is accessible through any web browser, and also available as a native desktop application for Windows, macOS and Linux. Accessing the Keeper vault is the foundation of the KeeperPAM platform, since the vault is deployed to all users, enforces MFA, SSO and implements a zero-knowledge encryption model.

When the Role-based Enforcement Policies are activated from the Keeper Admin Console, those designated users can work with KeeperPAM functionality directly with the vault.

• Accessing the KeeperPAM Console and Vault

• Activating Enforcement Policies

Records, Record Types and Resources

In Keeper, a record can be a password, file, passkey, or any number of possible record type templates. A record is always encrypted locally on the user's device with a record-level encryption key. All information held within a record is encrypted in the vault.

When working with Secrets Management and Privileged Access Management functionality, records can also represent Applications, Machines, Directories, Databases, Domain Controllers, Users and other infrastructure being managed.

Like any password record, these new record types can also be placed into private or shared folders, managed directly in the vault and controlled through policy enforcements.

Folders and Shared Folders

In the vault, records are placed into folders and shared folders. A typical and recommended setup looks something like this:

• Private Folder

  • Shared Folder containing Resources

  • Shared Folder containing User accounts

The reason that we recommend splitting up Resources and User accounts is based on least privilege. In this configuration, the resources can be provisioned to a user without sharing access to the underlying credentials. The user accounts are in a separate folder and can remain private in this vault or shared to other privileged users as required.

A resource such as a Linux machine can be seen inside the resource folder below. The Administrative Credentials used for connecting to that resource are linked, but not directly embedded in the resource. This way, you can provide access to the resource without sharing the credential.

In this example, the linked Administrative Credential lives in the Users folder with separate permissions and folder privileges.

At the Shared Folder level, both human users and applications can be assigned with access rights. This allows least privilege enforcement across employees and machines.

The fastest way to understand the relationship between records, folders, applications and configurations is using the Quick Start Wizard. This wizard instantly creates a sandbox environment where you can work with the different resources and vault records.

Application

A Secrets Manager Application is assigned to specific shared folders. Applications are associated to devices and Gateways for accessing the assigned records.

An Application and the associated devices and Gateways can only decrypt the records assigned to the folder. Keeper recommends implementing the principle of least privilege, ensuring applications are limited in their ability to access records from the vault.

Management of Applications is found in the Keeper Secrets Manager section of the vault. An example of an Application might be "Azure DevOps Pipeline" or "Azure AD Rotations" as seen in the screenshot below.

For more information on Applications:

• Applications

Device

A 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. Each Client device has a unique key to read and access the secrets.

A device can be initialized through the Applications section of the vault user interface.

For more information on Devices:

• Devices

Gateway

The Keeper Gateway is a service that is installed on any Docker, Linux or Windows machine in order to execute password rotation, discovery, connection, tunneling or other privileged automation. The Gateway service can be installed in any remote or on-prem environment, powering a secure zero-trust connection.

Typically, a Keeper Gateway is deployed to each environment that is being managed. For example, if you are an MSP managing 500 client environments, you may deploy 500 Keeper Gateways.

The architecture of the Keeper Gateway deployments is based on your use case and can be reviewed with our implementation team.

• Gateways

Configuration

A PAM Configuration defines the target environment where a Keeper Gateway has been installed. This configuration supplies important secrets to the Gateway that can be used to manage the target infrastructure. For example, it can contain Azure client secrets or Tenant IDs.

The PAM Configuration data is stored as a record in the vault inside the specified "Application Folder". This way, the Gateway has the necessary permission to retrieve this information.

We recommend defining only one Configuration for each Gateway.

More information about PAM Configuration records:

• PAM Configuration

PAM Resources

Inside the vault, records define the type of resources being managed. We call these "PAM Resources". Several new Record Types available in the vault are associated with a resource.

When creating a resource, you can select from various targets, such as Machine, Database, Directory, etc.

Visit the pages linked below to learn more about each PAM Resource:

PAM Users

A special record type in the Keeper Vault called PAM User can be directly associated to any PAM Resource. The PAM User is used by the Keeper Gateway for establishing a connection, rotating a password, discovering accounts or running other privilege automation on a target resource.

A PAM User is linked to the PAM Resource in the "Credentials" section of the record. This linkage ensures that access to the resource does not directly allow access to the credential.

A PAM User record can be configured for on-demand and automatic rotation.

More information on PAM Users is found here:

• PAM Users

Activating PAM Features

Now that you understand the basic structure of the vault, activating and utilizing PAM features is described in the below sections.

• Password Rotation

• Connections

• Tunnels

• Remote Browser Isolation

• Discovery

Overview

The Keeper Gateway is a service that is installed on any Docker, Linux or Windows machine in order to execute rotation, discovery, connection and tunneling. A single Gateway can be used to communicate with any target infrastructure, both on-prem and cloud. Typically, customers deploy a Keeper Gateway in each environment that is being managed.

Platforms Supported

• Docker

• Windows

• Linux

Platform Specific Capabilities

The Keeper Gateway offers different feature capabilities based on the underlying operating system and hardware. We recommend using Docker on a Linux or Windows host with x86 CPUs for full feature support and ease of management.

Note: EL9 which includes Rocky Linux 9 and RHEL 9 support is coming soon.

System Requirements

System requirements vary based on the number of simultaneous user sessions and the types of connections being established. As the volume of simultaneous connections grows, scaling CPU and memory resources becomes essential. In particular, remote browser isolation (RBI) launches a headless Chromium instance for each session. If you anticipate a high number of RBI sessions, ensure the system is scaled to meet these demands.

For a testing or sandbox a minimum of 2 CPUs with 8GB of memory and 10GB of storage is required. In a production environment, increase to at least 4 CPUs with 16GB of memory. Scale the number of CPUs and memory as the number of simultaneous sessions increases.

Network Configuration

The Gateway establishes outbound-only connections to the following:

The Gateway preserves zero knowledge by performing all encryption and decryption of data locally. Keeper Secrets Manager APIs are used to communicate with the Keeper cloud.

• System Architecture

• Security & Encryption Model

Installation Steps

The Keeper Gateway generates encryption keys and a local Secrets Manager configuration that is used to authenticate with the Keeper cloud. The location depends on the context in which the Gateway is being run. It can be installed to the local user or installed as a service.

• Login to the Keeper Web Vault or Desktop App (version 17.1 or newer required)

• Click on Secrets Manager on the left side

• Create a new Secrets Manager Application or select existing application

• Click on the "Gateways" tab and click "Provision Gateway"

• Select Docker, Linux or Windows install method

• Install the Keeper Gateway using the provided method

During the creating of a Keeper Gateway using a one-time token method for Linux and Windows, you have the choice to select "Lock external WAN IP Address of device for initial request". This will additionally IP lock the Gateway in addition to the authentication and encryption built into the service.

Based on your Operating System, refer to the corresponding guide on installing the Keeper Gateway:

• Docker

• Linux

• Windows

Additional Installation Configurations

If you are installing on an EC2 instance in AWS, the Keeper Gateway can be configured to use the instance role for pulling its configuration from AWS Secrets Manager. Detailed instructions on this setup can be found here.

What's a Device?

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

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

Device Initialization

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.

One-Time Access Token Initialization

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.

One additional feature of this method is that you can optionally lock down API requests to a specific IP address. The IP address allowed to transact is based on the IP as seen by Keeper's cloud infrastructure.

• One-Time Access Token details

Configuration File Initialization

The Configuration file method of creating a device is useful for tools and integrations where all of the secrets need to be provided at runtime. Most of the CI/CD integration methods use this pre-built configuration file.

For more information about the contents of a Keeper Secrets Manager configuration:

• Secrets Manager Configuration details

Commander CLI

The Keeper Commander CLI can create devices with some additional capabilities that are not available in the UI. For example, the CLI can create any number of devices in bulk, or set an expiration on the validity of the device.

Additional features of the Commander CLI device initialization method:

• Control over the device name

• Access expiration when the device can be initialized

• Access expiration of the device

• Allow all IPs or restrict to the first requested IP

• Generate a number of device tokens or configurations in bulk

• Option to initialize with a on-time access token or configuration file

Command Help

secrets-manager client add --app [APP NAME OR UID] --unlock-ip

Options:

--name [CLIENT NAME] : Name of the client (Default: Random 10 characters string)

--first-access-expires-in-min [MIN] : First time access expiration (Default 60, Max 1440)

--access-expire-in-min [MIN] : Client access expiration (Default: no expiration)

--unlock-ip : Does not lock IP address to first requesting device

--count [NUM] : Number of tokens to generate (Default: 1)

--config-init [json, b64 or k8s] : Initialize configuration string from a one-time token

Example:

secrets-manager client add --app "My Infrastructure App" --unlock-ip

• See more details on the secrets-manager Commander CLI command

What's an Application?

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.

Creating an Application

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

Generating a One-Time Access Token

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.

Assigning Gateways to Applications

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.

Overview

This document contains information on how to install, configure, and update the Keeper Gateway on Windows.

Prerequisite

Installation

The latest Keeper Gateway for Windows is downloaded from here:

You can run the service under system privilege or use a service account.

New Installs

Upgrading

If you are upgrading an existing Gateway, un-check the "Enter a Keeper One-Time Access Token" so that the existing configuration is maintained.

Installation Location

The default installation location is the following:

C:\ProgramFiles (x86)\Keeper Gateway\<version>

Setup Options

• Install Windows service - Installs the gateway as a Windows service.

  • Start Windows service - Start the Keeper Gateway service immediately after installation

  • Enable automatic updates

• Remove Keeper Gateway configuration and logs from previous installations

Specifying the Keeper Gateway Service Account

If "Use service account" is specified you will be prompted to enter the valid credentials of the desired service account:

One-Time Access Token

After clicking "Next", click "Install" in the next screen to install the Keeper Gateway.

Gateway Service Management

After installing and running the Keeper Gateway as a service, this service can be accessed and easily managed within the Windows Services Manager as "Keeper Gateway Service".

Configuration File

If the Keeper Gateway is installed and running as a service, the gateway configuration file is stored in the following location:

C:\ProgramData\KeeperGateway\config\gateway-config.json

If the Keeper Gateway is installed locally and not running as a service, the gateway configuration file is stored in the following location:

C:\Users\<User>\.keeper\gateway-config.json

Log files

Logs that contain helpful debugging information are automatically created and stored on the local machine.

If the gateway is running as a service, the gateway log files are stored in the following location:

C:\ProgramData\KeeperGateway\logs\

If the gateway is not running as a service, the gateway log files are stored in the following location:

C:\Users\<User>\.keeper\logs\

Verbose Logging

To activate verbose logging:

• Go to Windows Services > Keeper Gateway > Properties

• Stop the service

• Set the "Start parameters" to: --debug or -d

• Start the service by clicking on "Start" Do not click "OK" without first starting the service as it will not persist the Parameter setting

Upgrading

To upgrade, stop the service, install the latest version and then start the service.

• Back up your gateway-config.json configuration file

• Run the latest Keeper Gateway installer

• During installation DO NOT select "Enter a Keeper One-Time Access Token".

Auto Updates

Select "Enable automatic updates" during the installer process to ensure that your Keeper Gateway is automatically updated when there are new versions available.

Silent Install

This section provides instructions for performing a silent installation of the Keeper Gateway on Windows systems. Silent installation allows the setup process to run in the background without displaying any user interface or messages.

To install the Keeper Gateway silently, use the following command in your command prompt or script:

keeper-gateway_windows_x86_64.exe /verysilent /suppressmsgboxes /norestart /token=<TOKEN>

Replace <TOKEN> with the token provided in the Keeper Vault when creating the Keeper Gateway.

Configuration Options

If you have previously installed Keeper Gateway and wish to use the existing configuration, you can bypass the token entry by using:

/existingconfig=1

To generate a log file during the installation process, use the following option and specify the desired log file path:

/log=<Optional log file>

Windows Service Account

If you prefer to run the Keeper Gateway under a specific Windows service account, use the following options to specify the account details:

/mergetasks="service/account" /serviceuser=<ACCOUNT USERNAME> /servicepass=<ACCOUNT PASSWORD>

Replace <ACCOUNT USERNAME> and <ACCOUNT PASSWORD> with the credentials of the service account you intend to use.

Auto Updater

To enable the Auto Updater feature, allowing Keeper Gateway to automatically check for and apply updates, use the following option:

/autoupdate=1

Uninstalling

To uninstall the service:

• Uninstall Keeper Gateway from "Add and remove programs"

• If desired, delete the private configuration .json file

Network Configuration

The Gateway establishes outbound-only connections to the following:

The Gateway preserves zero knowledge by performing all encryption and decryption of data locally. Keeper Secrets Manager APIs are used to communicate with the Keeper cloud.

Overview

In order to install and setup a Keeper Gateway device, you need to have a few resources set up:

• Shared Folders to hold the PAM Resources (Machines, Databases, Users, etc)

• Keeper Secrets Manager application

• PAM Configuration

To simplify the process, we have a new Gateway wizard which creates all of the necessary components. Or, you can run each step individually.

Using the Gateway Wizard

A new Gateway deployment can be created by clicking on Create New > Gateway from the Web Vault. We have also posted a page describing how to create a sandbox environment in just a few steps.

Creating a Gateway

Using Commander CLI

You can also create a Gateway and configuration file from the Commander CLI:

pam gateway new -n "<Gateway Name>" -a <Application Name or UID> -c b64

The Application names and UIDs can be found with secrets-manager app list

Overview

This document contains information on how to install, configure, and update your Keeper Gateway on Linux.

Prerequisites

• For full capabilities, use Rocky Linux 8, RHEL 8 or Alma Linux 8.

Installation

Install Command

Executing the following command will install the Keeper Gateway, and run it as a service:

curl -fsSL https://keepersecurity.com/pam/install | \
  sudo bash -s -- --token XXXXXX

• Replace XXXXX with the One-Time Access Token provided from creating the Keeper Gateway

Installation Location

The gateway will be installed in the following location:

/usr/local/bin/keeper-gateway

An alias gateway is also created in the same directory

gateway -> /usr/local/bin/keeper-gateway

Gateway Service Management

For managing the Keeper Gateway as a service, the following are created during the Gateway installation:

• A keeper-gateway folder

• A keeper-gw user

keeper-gateway folder

The keeper-gateway folder contains the gateway configuration file and is created in the following location:

/etc/keeper-gateway

keeper-gw user

During the gateway installation, a new user, keeper-gw, is created and added to the sudoers list in /etc/sudoers.d/.

The keeper-gw user is the owner of the keeper-gateway folder and runs the gateway service. This is required when performing rotations on the gateway service and performing post-execution scripts.

Managing the Gateway Service

The following commands can be executed to start, restart, or stop the Keeper Gateway as a service:

sudo systemctl start keeper-gateway
sudo systemctl restart keeper-gateway
sudo systemctl stop keeper-gateway

Keeper Gateway Configuration File

If the Keeper Gateway is installed and running as a service, the gateway configuration file is stored in the following location:

/etc/keeper-gateway/gateway-config.json

If the Keeper Gateway is installed locally and not running as a service, the gateway configuration file is stored in the following location:

<User>/.keeper/gateway-config.json

Keeper Gateway Log files

Logs that contain helpful debugging information are automatically created and stored on the local machine.

If the Gateway is running as a service, the log files are stored in the following location:

/var/log/keeper-gateway/

If the Gateway is not running as a service, the log files are stored in the following location:

<User>/.keeper/logs/

Verbose Logging

To add verbose debug logging, modify this file:

/etc/systemd/system/keeper-gateway.service

and add the -d flag to the "gateway start" command, e.g:

ExecStart=/bin/bash -c "/usr/local/bin/gateway start --service -d --config-file /etc/keeper-gateway/gateway-config.json"

Apply changes to the service:

sudo systemctl daemon-reload
sudo systemctl restart keeper-gateway

Tailing the Logs

sudo journalctl -u keeper-gateway.service -f

Upgrading

Executing the following command will upgrade the Keeper Gateway to the latest version:

curl -fsSL https://keepersecurity.com/pam/install | sudo bash -s --

Auto Update

Configure your Keeper Gateway installation to automatically check for updates, ensuring it stays up-to-date with the latest version.

Uninstalling

Executing the following command will uninstall the Keeper Gateway:

curl -fsSL https://keepersecurity.com/pam/uninstall | sudo bash -s --

Network Configuration

The Gateway establishes outbound-only connections to the following:

The Gateway preserves zero knowledge by performing all encryption and decryption of data locally. Keeper Secrets Manager APIs are used to communicate with the Keeper cloud.

Overview

In Keeper, the PAM Configuration contains essential information of your target infrastructure, settings and associated Keeper Gateway. We recommend setting up one PAM Configuration for each Gateway and network being managed.

Creating PAM Configuration

To create a new PAM Configuration:

• Login to the Keeper Vault

• Select Secrets Manager and the "PAM Configurations" tab

• Click on "New Configuration"

PAM Configuration Fields

When setting up the PAM Configuration, you have the option of choosing one of the following environments:

The following tables provides more details on each configurable fields in the PAM Configuration record regardless of the environment you choose:

The following tables provides more details on each configurable fields in the PAM Network Configuration record based on the environment you chose:

Local Network Environment

AWS Environment

Azure Environment

Domain Controller Environment

This PAM Configuration type is not yet available, it will be launched in January 2025.

PAM Features on PAM Configuration

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:

Overview

This section will cover additional configurations to modify the Keeper Gateway's default behavior.

Support Configurations

The following are supported configurations for the Keeper Gateway:

AWS Environment Overview

Resources in your AWS environment can be managed by a Keeper Gateway using EC2 instance role policy or using a specified Access Key ID / Secret Access Key configured in the PAM Configuration record.

The role policy must be configured appropriately to enable access to the target AWS resources:

The following diagram shows the AWS environment hierarchy:

EC2 IAM Role Policy

To create a EC2 IAM policy which supports PAM features such as password rotation and discovery, a role with the appropriate policy settings should be configured then attached to the EC2 instance running the Keeper Gateway.

For KeeperPAM to have the authority to rotate IAM users and RDS databases, the following inline role policy should be modified to meet your needs and ensure least privilege.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "iam:SimulatePrincipalPolicy",
                "ec2:DescribeInstances",
                "rds:DescribeDBInstances",
                "ds:DescribeDirectories",
                "iam:ListUsers",
                "iam:GetUser",
                "iam:ListAccessKeys",
                "iam:UpdateLoginProfile",
                "rds:ModifyDBInstance",
                "ds:ResetUserPassword",
                "ds:DescribeLDAPSSettings",
                "ds:DescribeDomainControllers"
            ],
            "Resource": "*"
        }
    ]
}

To ensure least privilege, the JSON policy should be modified based on which target resources that KeeperPAM will be managing through the "Action" and "Resource" attributes.

Follow these steps to create a new role and apply the policy:

1. Create role with JSON specified above, or click on IAM > Roles > Create Role > Select "AWS Service" with "EC2 use case".

2. Attach the policy JSON to the role.

3. From EC2 > Instances, select the instance with the gateway and go to Actions > Security > Modify IAM Role > Select your new role.

Minimum AWS Policy to Manage IAM users

IAM User Policy

Using EC2 instance role policy is preferred, however the AWS Access Key ID and Secret Access Key can be directly set in the PAM Configuration. The IAM Admin account needs to be created with the appropriate policy settings configured to access the target resource in AWS.

An sample policy is below.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "iam:SimulatePrincipalPolicy",
                "ec2:DescribeInstances",
                "rds:DescribeDBInstances",
                "ds:DescribeDirectories",
                "iam:ListUsers",
                "iam:GetUser",
                "iam:ListAccessKeys",
                "iam:UpdateLoginProfile",
                "rds:ModifyDBInstance",
                "ds:ResetUserPassword",
                "ds:DescribeLDAPSSettings",
                "ds:DescribeDomainControllers"
            ],
            "Resource": "*"
        }
    ]
}

To ensure least privilege, the JSON policy should be modified based on which target resources that KeeperPAM will be managing through the "Action" and "Resource" attributes.

The steps to create the access keys is below:

1. Create a new IAM user or select an existing user

2. Attach the policy to the user

3. Open the IAM user > Security credentials > Create access key

4. Select "Application running outside AWS"

5. Save the provided Access Key ID / Secret Access Key into the PAM Configuration

Advanced Gateway Configuration with Custom Fields

When setting up Rotation in your Keeper Vault, you store the credentials of your assets involved in rotation on their corresponding PAM Record Types. On these record types, you are able to .

The additional gateway configurations will be defined with these custom fields on the PAM Record Types. The Keeper Gateway will then adjust its behavior based on the defined configurations.

The following tables lists all the possible configurations with custom fields:

Note:

• The custom fields values are not case-sensitive.

Azure Environment Overview

In order to set up your Azure environment, the following steps must be taken:

• Create an Azure application in the default Azure Active Directory.

• Get values for the Keeper PAM Configuration from this new application.

• Grant permissions to the application to access the Azure Active Directory.

• Create a custom role to allow the application to access/perform actions on various Azure resources.

Create an Azure App Registration

Go to the Azure portal > Home and click on Microsoft Entra ID on the left side vertical menu. Select App Registrations, and then New Registration. Give the new application a name and select Single tenant. Then click the Register button at the bottom.

In the Overview of the application, the Application (client) ID UUID is shown. This is the Client Id field of the Keeper PAM Configuration record. The Directory (tenant) ID is also shown. This is the Tenant Id field of the Keeper PAM Configuration record. Save these values for later.

Next, click on the Add a certification or secret for Client credentials. On the next page, click on New client secret, give the client secret a Description, and select a desired Expires date, and click Add.

The page will refresh showing the secret Value. Copy the Value (not Secret ID) into the Keeper PAM Configuration "Client Secret" field. Save this value for later.

At this point, all the required the PAM Configuration fields should be filled in. You also have an Azure application that cannot do anything yet.

Assign Roles and Administrators

In order for the Azure tenant service principal/application to rotate Azure Active Directory users or Azure Active Directory Domain Service users, the application must be a assigned to an Administrative role.

From the Azure portal go to Home > Azure Active Directory > Roles and administrators, and click on the Administrative role to use (such as Privileged Authentication Administrator). The correct role depends on what privileges are needed for your use case. Custom roles can be used.

• Global Administrator - It is not recommended to use a Global Administrator on a service principal. However, it will allow both administrator and user passwords to be rotated.

To add the application, click Add assignments and Search for the service principal/application that was created, click it, and then Add.

Assign Azure Role

Roles need to be attached to the Azure Application (also called a Service Principle here) in order to rotate passwords of target resources. This is done in the Subscription section of the Azure portal.

Go to the Azure portal > Home > Subscriptions then select your subscription. Click on Access control (IAM), and then Roles.

Click Add on the top menu, and then Add custom role. Jump to the JSON tab. Click on Edit and paste the JSON object from below, modifying it according to your setup.

Change the following before you save:

• <ROLE NAME>: Role Name, e.g. "Keeper Secrets Manager"

• <DESCRIPTION>: Description, e.g. "Role for password rotation"

• <SUBSCRIPTION ID>: Subscription ID of this Azure subscription

{
    "properties": {
        "roleName": "<ROLE NAME>",
        "description": "<DESCRIPTION>",
        "assignableScopes": [
            "/subscriptions/<SUBSCRIPTION ID>"
        ],
        "permissions": [
            {
                "actions": [
                    "Microsoft.Compute/virtualMachines/read",
                    "Microsoft.Network/networkInterfaces/read",
                    "Microsoft.Network/publicIPAddresses/read",
                    "Microsoft.Network/networkSecurityGroups/read",
                    "Microsoft.Compute/virtualMachines/instanceView/read",
                    "Microsoft.Resources/subscriptions/resourceGroups/read",
                    "Microsoft.AAD/domainServices/read",
                    "Microsoft.Network/virtualNetworks/subnets/read",
                    "Microsoft.Sql/servers/read",
                    "Microsoft.Sql/servers/databases/read",
                    "Microsoft.DBforPostgreSQL/servers/read",
                    "Microsoft.DBforMySQL/servers/read",
                    "Microsoft.DBforPostgreSQL/servers/databases/read",
                    "Microsoft.Sql/servers/write",
                    "Microsoft.DBforPostgreSQL/servers/write",
                    "Microsoft.DBforMySQL/servers/write",
                    "Microsoft.DBforMySQL/flexibleServers/read",
                    "Microsoft.DBforPostgreSQL/flexibleServers/read",
                    "Microsoft.DBforPostgreSQL/flexibleServers/write",
                    "Microsoft.DBforMySQL/flexibleServers/write",
                    "Microsoft.DBforMariaDB/servers/read",
                    "Microsoft.DBforMariaDB/servers/write"
                ],
                "notActions": [],
                "dataActions": [],
                "notDataActions": []
            }
        ]
    }
}

Click Save.

When done, click Review + create, and click Create.

Once the role is created, it needs to be assigned to the Application (Service Principle). Click View in the Details column.

A panel will appear on the right side of the screen. Click Assignments, and then Add assignment.

Enter in the new role's name in the search bar on the Role tab, then double click it to select it. Move to the Members tab. Click Select members. In the panel that opens, enter the name of the Azure application, select the current application, and click Select.

Go to the Review + assign tab click Review + assign.

At this point, you have created the necessary roles and applications within your Azure environment.

PAM Features

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:

Configuring PAM Features on PAM Record Types

After creating the PAM configuration, visit the following pages to:

Overview

If the Keeper Gateway is installed on an AWS EC2 Instance, the corresponding Gateway configuration file can be protected and stored in AWS Secrets Manager. This method eliminates the need for storing a configuration file on the instance, and instead stores the configuration file with AWS KMS protection.

AWS Key Management Service (KMS) Key

AWS KMS is a fully managed service that makes it easy for you to create and control the cryptographic keys used to encrypt and decrypt your data. The service is integrated with other AWS services, making it easier to encrypt data and manage keys. You will need a AWS KMS key as part of this process, and it is recommended that you follow the principle of least privilege when assigning permissions to this key.

Prerequisites

In order to use AWS KMS to protect the Gateway configuration secrets, you need to install the Keeper Gateway on an EC2 instance which assumes an IAM Role. This works on either Docker or Linux install methods.

Generate a Configuration

From the Keeper Vault, go to Secrets Manager > Applications and select the application configured with your Gateway. Then select the Gateways tab and select "Provision Gateway".

Select the Gateway initialization method of "Configuration" and click Next.

Alternatively, you can generate a One-Time Access Token and then use the Keeper Gateway's "gateway ott-init" command:

gateway ott-init [ONE-TIME-TOKEN]

In either case, you'll be provided with a base64 encoded configuration. Save this for the next step.

Create Secret in AWS Secrets Manager

From the AWS Console, go to the Secrets Manager and create a new secret.

• Select "Other type of secret"

• Select Plaintext and paste the entire base64 value there.

• Click Next.

Enter a Secret Name and a description then click Next, Next and Store.

Assign Policy to Instance Role

The EC2 instance role needs to be assigned a policy which provides read access to the specific AWS Secrets Manager key. As an example:

{
    "Sid": "SecretsManagerPermissions",
    "Effect": "Allow",
    "Action": [
        "secretsmanager:GetSecretValue"
     ],
     "Resource": "arn:aws:secretsmanager:us-west-1:XXX:secret:XXX"
}

Confirming Access

From the EC2 instance, the below command will confirm the policy has been applied:

aws secretsmanager get-secret-value --secret-id YourSecretName --query SecretString --output text

Configuration of the Keeper Gateway

Docker Install Method

For Docker installations, remove the GATEWAY_CONFIG entry and add AWS_KMS_SECRET_NAME with the value containing the name of the secret from the AWS secrets manager.

services:
      keeper-gateway:
        platform: linux/amd64
        image: keeper/gateway:latest
        shm_size: 2g
        security_opt:
          - "seccomp:docker-seccomp.json"
        environment:
          ACCEPT_EULA: Y
          AWS_KMS_SECRET_NAME: "YourSecretName"

Then update the service with the new environment:

docker compose pull
docker compose down
docker compose up -d

Linux Install Method

Open the Keeper Gateway service unit file:

/etc/systemd/system/keeper-gateway.service

Modify the "ExecStart" line as seen below, replacing YourSecretName with your assigned name.

ExecStart=/bin/bash -c "/usr/local/bin/gateway start --service --aws-kms-secret-name="YourSecretName" --log-to-stdout"

Apply changes to the service:

sudo systemctl daemon-reload
sudo systemctl restart keeper-gateway

If there are any errors starting up, they can be seen through this command:

systemctl status keeper-gateway.service

Overview

A PAM Directory record is a type of KeeperPAM resource that represents an Active Directory or OpenLDAP service, either on-prem or hosted in the cloud.

Features Available

The PAM Machine resource supports the following features:

• Password rotation using either LDAP, LDAPS or WinRM

• Connections using RDP

• TCP Tunnels over any protocol

• Session recording and playback

• Sharing access without sharing credentials

Creating a PAM Directory

Prior to creating a PAM Directory Record type, make sure you have already created a PAM Configuration. The PAM Configuration contains information of your target infrastructure while the PAM Directory contains information of an asset, such as a Active Directory server, within that target infrastructure.

To create a PAM Directory:

• Click on Create New

• Depending on your use case, click on "Rotation", "Tunnel", or "Connection"

• On the prompted window:

  • Select "New Record"

  • Select the Shared Folder you want the record to be created in

  • Specify the Title

  • Select "Directory" for the Target

• Click "Next" and complete all of the required information.

PAM Directory Record Type Fields

The following table lists all the configurable fields on the PAM Directory Record Type:

PAM Settings and Administrative Credentials

On the "PAM Settings" section of the vault record, you can configure the KeeperPAM Connection and Tunnel settings and link a PAM User credential for performing rotations and connections. Tunnels do not require a linked credential.

PAM Settings

Note: PAM User is only required to successfully configure connections and rotation, and not required for Tunnels.

Configuration Steps:

1. On the PAM Database record, navigate to the PAM Settings section

2. Select the PAM Configuration and Administrative Credential Record

3. To configure Keeper Connections and Keeper Tunnels settings, visit the following page:

The following screenshot is a PAM Directory Record with LDAPS rotation, RDP connections and LDAPS tunnels enabled:

Overview

In this example, you'll learn how to configure a Azure Windows VM in your Keeper Vault as a PAM Machine record.

Prerequisites

Prior to proceeding with this guide, make sure you have

1. Installed and configured the Keeper Gateway

2. Set up a PAM Configuration for your target Environment

PAM Machine Record

Machines such as a Azure Virtual Machines can be configured on the PAM Machine record type.

Creating a PAM Machine

To create a PAM Database:

• Click on Create New

• Depending on your use case, click on "Rotation", "Tunnel", or "Connection"

• On the prompted window:

  • Select "New Record"

  • Select the Shared Folder you want the record to be created in

  • Specify the Title

  • Select "Machine" for the Target

• Click "Next" and complete all of the required information.

Configure a Windows Machine on the PAM Machine Record

Suppose I have a Azure Virtual Machine with the hostname "10.0.1.4", the following table lists all the configurable fields and their respective values:

Configuring PAM Settings on the PAM Machine

On the "PAM Settings" section of the vault record, you can configure the KeeperPAM Connection and Tunnel settings and link a PAM User credential for performing rotations and connections. Tunnels do not require a linked credential. The following table lists all the configurable fields and their respective values for the Azure Virtual Machine:

Administrative Credential Record

The Admin Credential Record in the PAM Machine links the admin user to the PAM Machine record in your Keeper Vault. This admin user is used for performing password rotations and authenticating connections.

User Accounts can be configured on the PAM User record. Visit this page for more information.

Setting a Non Admin User as the Administrative Credential Record

If you prefer not to authenticate a connection using the admin credential, you can optionally designate a regular user of the resource as the admin credential.

Sharing PAM Machine Records

PAM Machine records can be shared with other Keeper users within your organization. However, the recipient must have the appropriate PAM enforcement policies in place to utilize KeeperPAM features on the shared PAM records.

When sharing a PAM Machine record, the linked admin credentials will not be shared. For example, if the PAM Machine is configured with a Azure Virtual Machine, the recipient can connect to the Azure Virtual Machine on the PAM Machine record without having direct access to the linked credentials.

• Learn more about Sharing and Access Control

Overview

In this example, you'll learn how to configure a Linux Machine in your Keeper Vault as a PAM Machine record.

Prerequisites

Prior to proceeding with this guide, make sure you have

1. Installed and configured the Keeper Gateway

2. Set up a PAM Configuration for your target Environment

PAM Machine Record

Machines such as a Linux Machines can be configured on the PAM Machine record type.

Creating a PAM Machine

To create a PAM Database:

• Click on Create New

• Depending on your use case, click on "Rotation", "Tunnel", or "Connection"

• On the prompted window:

  • Select "New Record"

  • Select the Shared Folder you want the record to be created in

  • Specify the Title

  • Select "Machine" for the Target

• Click "Next" and complete all of the required information.

Configure a Linux Machine on the PAM Machine Record

Suppose I have a local Linux Virtual Machine with the hostname "linux-machine", the following table lists all the configurable fields and their respective values: