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, endpoint privileged 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:

• KeeperPAM Website

About this Documentation

This documentation is broken out into the following sections:

• Privileged Access Manager

• Endpoint Privilege Manager

• Secrets Manager

• Commander CLI

• Commander SDK

Additional documentation on the core Keeper platform can be found here:

• Enterprise Admin Guide

• Keeper Connection Manager (self-hosted)

• Documentation Home

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

• Agentic AI session threat detection monitoring and session summary generation

Contact the Keeper Team

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

• Contact our team

For technical questions, you can also email [email protected].

Next Steps

• Start the setup of KeeperPAM

• Launch the Quick Start: Sandbox

• Deep dive into the Getting Started guide for KeeperPAM

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

Setup Steps

Follow the below steps to start using KeeperPAM.

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.

• We recommend setting up a Keeper Gateway using the new . This provides a customized Docker Compose file that provides an instant sandbox for testing.

Feedback

Please email us at [email protected] with your feedback and we'll quickly assist you with any questions.

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

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.

Overview

Keeper Gateways are essential when configuring PAM features such as rotation and connections on PAM resources. Keeper provides KSM Application Sharing from the vault UI and Keeper Commander CLI.

Why is Gateway Sharing Needed?

Gateways are tied to Keeper Secrets Manager (KSM) applications. Only users who have access to a KSM application can view and select its associated Gateway when configuring PAM Record Types. Without sharing, only the owner of the KSM application can use the Gateway for PAM configuration.

Sharing the KSM application (and thus the Gateway) allows other administrators or team members to independently configure and manage PAM resources. This is critical when multiple users in your organization are responsible for managing privileged access.

Note: Gateways are automatically shared when the associated KSM application is shared.

Sharing KSM applications

When you share the KSM application, you also share access to the associated Gateway.

To share the KSM application:

1. From the vault, open the KSM Application you want to share

2. Edit the Application

3. Navigate to the "Users" tab

4. In the search bar, enter the user’s email address

5. Add the user to the application.

For more information, visit this .

User Permissions

Outcomes

Once the gateway is shared through the KSM application, users who now have access can configure PAM resources using that gateway.

Overview

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

Advanced Configurations

Keeper can automatically rotate a client secret in Azure. Please see the Azure Client Secret section of the SaaS Plugin documentation.

In this section, you will learn how to rotate database user credentials within your local network.

Databases Supported

• Native MySQL

• Native MariaDB

• Native PostgreSQL

• Native MongoDB

• Native MS SQL Server

• Native Oracle

Keeper can automatically rotate an IAM User Access Key in AWS. Please see the AWS Access Key section of the SaaS Plugin documentation.

Overview

In this section, you will learn how to rotate DB User or Admin credentials on the following Google Cloud Managed Databases:

Cloud SQL for MySQL:

Cloud SQL for SQL Server:

Cloud SQL for PostgreSQL

If you are running a database directly on an Google Compute instance in your GCP environment instead of using a managed service, refer to the Local Network > Database documentation for rotating passwords.

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

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

In this section, you will learn how to rotate DB User or Admin credentials on the following Azure Managed Databases:

• Azure SQL

• Azure MySQL

• Azure MariaDB

• Azure PostgreSQL

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

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.

Apache Guacamole Usage

As seen throughout the KeeperPAM and Keeper Connection Manager documentation, you will notice references to "Apache Guacamole", "guacd", or "guacamole". Apache Guacamole is a robust, open source remote desktop gateway.

In December 2021, Keeper Security acquired Glyptodon, which was operated by the creators of Apache Guacamole. As such, the creators of Guacamole now lead the Keeper Connection Manager team and continue to build out new capabilities. The Guacamole core services are bundled into the Keeper Connection Manager and KeeperPAM containers.

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

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.

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 create custom fields.

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.

Overview

In this section, you will learn how to rotate DB User or Admin credentials on the following AWS Managed Databases:

AWS RDS for MySQL:

AWS RDS for SQL Server:

AWS RDS for PostgreSQL

AWS RDS for MariaDB

AWS RDS for Oracle:

If you are running a database directly on an EC2 instance in your AWS environment instead of using a managed service, refer to the Local Network > Database documentation for rotating passwords.

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.

Keeper is designed for high availability, scalability, secure authorization, and robust disaster recovery. Hosted on Amazon Web Services (AWS), Keeper’s backend infrastructure is multi-region and multi-zone, ensuring redundancy across geographic locations. All core services are designed with high availability (HA) in mind, leveraging AWS best practices for fault tolerance and reliability. The system scales automatically to accommodate increased demand without compromising performance. Keeper's infrastructure supports millions of active users and devices.

On the customer side, the Keeper vault is deployed to users for all PAM access. The vault communicates with the Keeper backend APIs for establishing connections to resources. Keeper's zero-knowledge APIs ensure that Keeper's backend systems do not have the ability to decrypt any stored customer data. Encryption and decryption of data is always performed locally on the device.

Keeper Secrets Manager and Keeper Gateway Devices are responsible for performing secret retrieval, credential rotation, resource discovery and privileged session proxying to the customer's local or cloud environment. These devices communicate directly with the Keeper cloud APIs for the management of state, encrypted data storage, audit event logging and session recording. Since these devices are not responsible for the management of data, Keeper's architecture allows the customer environments to scale automatically without any specific hosting requirements on the customer side.

When a customer installs a Keeper Gateway or Keeper Secrets Manager device, it is typically deployed as a Docker container. Customers can use their preferred container orchestration platform such as Kubernetes, Docker Swarm, or Amazon ECS to manage deployment, enable scaling, and provide the necessary levels of local device redundancy.

Multiple Keeper Gateways can also be assigned to the same resources and folders in the Keeper vault in order to establish physical redundancy.

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 or establishing a privileged session) 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 interact with the target systems through a zero-trust encrypted session to the target infrastructure.

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.

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

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

The fastest way to create a Gateway and associated resources is using the Gateway Wizard. From the Web Vault or Desktop App, click on Create New > Gateway.

The below link describes how to create a sandbox environment in just a few steps:

• Quick Start: Sandbox

Using Keeper Secrets Manager

To set up a Keeper Gateway manually using the Keeper Secrets Manager application resources, follow these steps.

Using Commander CLI

You can also create a Gateway and configuration file from the Commander CLI. The below CLI commands will create a Secrets Manager application, shared folders and other resources before creating a Gateway instance.

Create an Application

secrets-manager app create "My Infrastructure"

Create Folders

mkdir -uf "My Infrastructure"
mkdir -sf -a "My Infrastructure/Resources"
mkdir -sf -a "My Infrastructure/Users"

Share the KSM app to the Shared Folders

secrets-manager share add --app "My Infrastructure" --secret <Resources folder UID>
secrets-manager share add --app "My Infrastructure" --secret <Users folder UID>

Create a Gateway

To initialize a Gateway for Linux or Windows native install methods, the one-time token method is used:

pam gateway new -n "My Demo Gateway" -a "My Infrastructure"

To initialize a Gateway using Docker, the base64 configuration is provided as GATEWAY_CONFIG environment variable as described in the Docker Installation instructions.

pam gateway new -n "My Demo Gateway" -a "My Infrastructure" -c b64

Overview

In this section, you will learn how to rotate user credentials within a Local Network environment across various target systems.

A "local network" simply means any resource that has line of sight access from the Keeper Gateway. This configuration can be used in any cloud or managed environment. Native protocols are used to communicate to the target resources and perform rotations.

Setup Steps

At a high level, the following steps are needed to successfully rotate passwords on a network:

1. Create Shared Folders to hold the PAM records involved in rotation

2. Create PAM Machine, PAM Database and PAM Directory records representing each resource

3. Create PAM User records that contain the necessary account credentials for each resource

4. Link the PAM User record to the PAM Resource record.

5. Assign a Secrets Manager Application to all of the shared folders that hold the PAM records

6. Install a Keeper Gateway and add it to the Secrets Manager application

7. Create a PAM Configuration with the AWS environment setting

8. Configure Rotation settings on the PAM User records

Use Cases

• Active Directory User

• Windows User

• Linux User

• macOS User

• Database

Attaching Post Rotation Scripts

When creating or editing a PAM record, click on the Add PAM Script button

Clicking on Add PAM Script will allow you to:

• Browse locally and choose your Rotation Script(s).

• Add "Additional Credentials". This is an option to add additional records which contains the credentials needed by the post rotation script. These credentials must be available to the Keeper Gateway.

• Specify an optional custom command to executed. In the below screenshot, a python script (postRotationTest.py) is attached, and a specific command to be used to execute the python script.

After successfully selecting the script(s), the record will be updated to show the attached Post Rotation scripts:

Click Save to create or update the record. Attached Post Rotation Scripts can be deleted or edited by clicking on their respective actions.

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

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.

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:

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 .

Overview

KeeperPAM Password Rotation enables customers to securely and automatically rotate credentials across cloud-based and on-premises environments, including Active Directory accounts, Windows and Linux users, database passwords, Azure IAM accounts, AWS accounts, Google Workspace accounts, SSH keys, and more. Adhering to Keeper’s Zero Trust and Zero Knowledge security model, this feature helps organizations mitigate risks associated with weak, reused, or long-standing credentials, as well as threats such as breaches, terminations, and dark web exposure.

Features

• Comprehensive Credential Rotation: Automate rotation for machines, service accounts, and user accounts across your infrastructure and multi-cloud environments.

• Flexible Scheduling: Schedule rotations to occur at any time or trigger them on demand.

• Service Management: Automatically update the log on credentials for Windows services and scheduled tasks after rotation.

• Post-Rotation Actions: Perform custom actions or functionality after rotation takes place.

• Access-Based Rotation: Automatically rotate credentials once access expires.

• Secure Access Control: Control and audit access to credentials through secure sharing and compliance reporting.

• Detailed Audit Logs: Track all rotation events using Keeper’s Advanced Reporting and Alerts Module (ARAM).

• Automation with Keeper Commander: Leverage Keeper Commander for fully automated rotation workflows.

• Rotation Plugins: Open source Plugin framework provides rotation capabilities with any 3rd party SaaS service.

Architecture

Rotation is performed on the Keeper Gateway and controlled through the Keeper Web Vault, Desktop App or Commander CLI.

How does Password Rotation Work?

In KeeperPAM, the way Password Rotation works is as follows:

• The record holds the credential that is being rotated.

• The Rotation Settings of the PAM User record references a specific PAM Machine, PAM Database or PAM Directory resource. This is the target resource where the rotation is performed.

• The uses the Admin Credential associated to the PAM Machine, PAM Database or PAM Directory resource to perform the rotation with native protocols.

• For AWS, Azure and GCP resources, the record holds the necessary rights and access keys to perform rotations with cloud native APIs.

• For AWS-deployed Gateways, Keeper uses Instance Role permission of the Gateway to perform the rotation with APIs.

• For Azure and Google Cloud managed resources, Keeper uses the Service Account permissions of the Gateway.

KeeperPAM Licensing Requirements

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

• License or..

• or license with

Trial License

If you are not a Keeper customer or do not have the required license, you can start a .

Features Included with KeeperPAM

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

• Secrets Manager with Unlimited API Calls

• Unlimited Password Rotations

• Unlimited Privileged Sessions / Connections

• Unlimited Tunnels

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

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

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 is a that MSPs can add or remove at any time for their Managed Companies.

Features available with the KeeperPAM Add-On are listed .

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

• KeeperPAM 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?

To purchase, upgrade, or if you have any questions, contact your Keeper account manager or use our .

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:

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:

Confirming Access

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

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.

Then update the service with the new environment:

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.

Apply changes to the service:

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

Overview

KeeperPAM Resource records are special record types designed to organize and store information of your target infrastructure, machines, web apps, workloads and user accounts.

KeeperPAM Record Types

In your Keeper Vault, resources that represent your infrastructure are created with the following Record Types:

Record Linking

The PAM User record is special because it can be from the other resources. This way, you can to a Machine, Database, Directory or Remote Browser without sharing access to the underlying credentials.

Creating a PAM Record

From the Vault UI, click on Create New and select either Rotation, Tunnel or Connection.

Alternatively, you can right-click on a folder and select Rotation, Tunnel or Connection.

The "Target" selection will determine what type of record will be created.

Bulk Import of Resources

There are several ways of creating resources in the Keeper vault.

• Manually in the Keeper Vault

• Using Keeper Discovery

• Bulk Import with Keeper Commander

Manually in the Keeper Vault

As described in this section, you can create PAM Machines, Databases, Directories, Remote Browsers and Users directly in the Keeper Vault.

Using Keeper Discovery

KeeperPAM can perform discovery on a network or cloud resource to find all associated machines, accounts, etc. Visit the section to learn more.

Bulk Import with Keeper Commander

Keeper Commander CLI can perform import of resources based on a template. See this example for a step by step guide. See the command for more advanced import options.

The following sections will describe each of the PAM resources.

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

Keeper Gateway

Keeper Rotation

Keeper Connection Manager (KCM)

Keeper Tunnels

Remote Browser Isolation (RBI)

Discovery

Legacy Policies

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

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"

Local Environment Overview

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.

Prerequisites

Prior to proceeding with this guide, make sure to install and configure your Keeper Gateway.

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 - Local Environment

The following tables provides more details on each configurable fields in the PAM Configuration record for the local environment:

For Discovery, the following fields are required, otherwise they are optional:

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:

• Configure Rotation

• Configure Connections

• Configure RBI

• Configure Tunnels

• Configure Discovery

Overview

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

Prerequisites

• Prior to proceeding with this document, make sure you created a Gateway device.

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

• If you cannot use one of these Linux flavors, please install using the Docker method

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

The Keeper Gateway configuration file contains a set of tokens that includes encryption keys, client identifiers, and tenant server information used to authenticate and decrypt data from the Keeper Secrets Manager APIs. This configuration file is created from the One-Time Access Token generated when you created the Gateway.

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

Updating

Executing the following command will update 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.

• Activate the Auto Updater

Uninstalling

Executing the following command will uninstall the Keeper Gateway:

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

Health Checks

To monitor the Gateway service, you can configure health checks that expose its operational status. These checks are useful for Docker orchestration, load balancing, and automated monitoring. See the Health Check section for full setup details and examples.

Overview

A PAM Remote Browser is a type of KeeperPAM resource that represents a remote browser isolation target, such as a protected internal application or cloud-based web app.

What is Remote Browser Isolation

KeeperPAM remote browser isolation records provide secure access to internal and cloud-based web applications through a protected browser, embedded within the vault. This browser is projected visually from the Keeper Gateway through the Keeper Vault, isolating the session and providing zero-trust access.

Features Available

The PAM Remote Browser resource supports the following features:

• Zero-trust Connections over http:// and https:// websites

• Session recording

• Sharing access without sharing credentials

• Autofill of linked credentials and 2FA codes

• URL AllowList patterns

• Navigation bar

Creating a Remote Browser Isolation Record

Prior to creating a PAM Remote Browser, make sure you have already created a PAM Configuration. The PAM Configuration contains information of your target infrastructure while the PAM Remote Browser contains information about the target web application and associated access rules.

To create a PAM Remote Browser:

• Click on Create New

• Select "Connection"

• On the prompted window:

  • Select "New Record"

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

  • Specify the Title

  • Select "Browser" for the Target

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

PAM Remote Browser Record Type Fields

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

PAM Settings and Administrative Credentials

On the "PAM Settings" section of the vault record, you can configure the KeeperPAM Connection and link a PAM User credential for performing autofill.

PAM Settings

Additional information on Remote Browser Isolation is available at this page.

Overview

A PAM User is a type of KeeperPAM resource that represents an account credential. The PAM User is linked from other resources.

What is a PAM User

KeeperPAM User records define a specific account inside another PAM resource. PAM Machines, PAM Databases, PAM Directories and PAM Remote Browser records link to a PAM User.

Features Available

The PAM User resource supports the following features:

• On-demand and scheduled password rotation

• PAM Scripts for privilege automation

• Persistent sharing to users and teams

• Sharing with time-limited access

• Auto-rotation after share revocation

Creating a PAM User

Prior to creating a PAM User, make sure you have already created a PAM Configuration and a PAM Resource such as a Machine, Database, Directory or Browser.

To create a PAM User:

• 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 "User" for the Target

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

PAM User Record Type Fields

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

Note (1)

When connecting to Windows machines that are domain-joined:

• For domain-joined systems, always use the UPN format ([email protected]) as it is more modern, DNS-reliant, and avoids NetBIOS issues.

• Reserve DOMAIN\user for older systems or mixed environments where UPN isn't supported.

Note that Keeper will attempt to login to the remote system using the username exactly as supplied. If authentication fails, Keeper will then attempt to use the below variations:

• User Principal Name (UPN) format: [email protected]

• Domain NetBIOS format: COMPANY\admin

• Shortened UPN format (no TLD): admin@company

• Domain FQDN with backslash format: company.com\admin

SSH Key Passphrase

When the PAM User record is storing an SSH key, the PEM-encoded private key is added to the "Private Key" field. If the SSH key file is encrypted, you can create a custom field with the title of "Passphrase" which stores the SSH key passphrase.

Configure rotation settings

Commander CLI

The Keeper Commander CLI provides specialized automation tools to create PAM User records, perform rotations, share credentials to team members, and deliver credentials through one-time share links for new employee onboarding.

References:

• Commander CLI

• KeeperPAM Commands

• Sharing Commands

• Automation Commands

Overview

In this section, you will learn how to rotate user credentials within the AWS Cloud environment across various target systems and services.

KeeperPAM Record Types

Configurations for your AWS environment are defined in the PAM Configuration section of Keeper Secrets Manager. Keeper will use the inherited EC2 instance role where the Gateway is installed to authenticate with the AWS system and perform rotation. If instance roles are not defined, the AWS Access Key ID and Secret Key can be stored in the PAM Configuration record to authenticate and perform rotations.

Configurations for managed resources like EC2, RDS, and Directory Services are defined in the PAM Machine, PAM Database, and PAM Directory record types. The following table shows the supported AWS managed resources with KeeperPAM and their corresponding PAM Record Type:

Configurations for directory users or IAM users are defined in the PAM User record type.

Prerequisites

To successfully rotate IAM User accounts or EC2 local user accounts, the Keeper Gateway needs to have the necessary AWS role policies with the permissions for performing the password rotation.

• See the AWS environment setup guide for more information.

If you are not using EC2 instance role policies, the following values are needed in the PAM Configuration:

The Keeper Gateway will always first attempt to use the EC2 instance role to authenticate and perform the rotation. If this fails or is not available on the machine, Keeper will use the Access Key ID and Secret Access Key stored in the PAM Configuration.

Setup Steps

At a high level, the following steps are needed to successfully rotate passwords on your AWS network:

1. Create Shared Folders to hold the PAM records involved in rotation

2. Create PAM Machine, PAM Database and PAM Directory records representing each resource

3. Create PAM User records that contain the necessary account credentials for each resource

4. Link the PAM User record to the PAM Resource record.

5. Assign a Secrets Manager Application to all of the shared folders that hold the PAM records

6. Install a Keeper Gateway and add it to the Secrets Manager application

7. Create a PAM Configuration with the AWS environment setting

8. Configure Rotation settings on the PAM User records

Use Cases

• IAM User Password

• Managed Microsoft AD User

• EC2 Instance local user

• IAM User Access Key

• Managed Database

What are Keeper Connections?

Keeper Connections allow users to instantly and securely access assets within their target infrastructure, such as servers, databases, web apps and workloads directly from their Keeper Vault. Connections can be established without exposing the underlying credentials to the user, ensuring zero-trust and zero-knowledge access.

Keeper Connections are configured on PAM Machine, PAM Database, PAM Directory and PAM Remote Browser record types, and once configured, connections are launched directly from these records.

One of the key features of Keeper Connections is the agentless and clientless architecture. Organizations need to install only a Keeper Gateway in each managed environment. This streamlined approach simplifies deployment and enhances security by centralizing access management.

Connection User Interface

Connections are launched directly from the Vault interface with one click. The connection is established between the Keeper Gateway and the target machine, and the session is visually projected into the Vault where you can interact seamlessly.

Click "Launch" to open a privileged session.

Sessions are opened directly inside the Keeper vault, establishing a zero trust encrypted connection to the target.

Full screen mode and zoom controls are available from the upper right corner of the window.

Connection Dock

The Connection Dock provides instant switching between active sessions. The dock can be moved to any desired location on the screen.

The dock can be minimized and moved anywhere on the screen.

How do Keeper Connections Work?

When launching a connection, the Web and Desktop Vault Client will render a window with the established connection protocol to the specified target defined on the PAM record. This is done by:

1. The Vault Client communicating with the Keeper Gateway with the relevant connection info through a secure tunnel

2. The Keeper Gateway then establishes the connection protocol to the target defined on the PAM Record

3. After establishing the connection, the Keeper Gateway projects the visual session to the Keeper vault client.

For more information on the architecture, see this page.

Why Use Keeper Connections?

IT Admins, DevOps and development teams struggle with protecting access to cloud and on-prem infrastructure to endpoints like remote desktops, Windows machines, Linux Servers, critical web-based apps, Kubernetes clusters and Databases.

Keeper Connections protects your business, your employees and your customers against data breaches by providing a unified vault for all access and control. Reducing risk and simplifying access are the core tenants of the Keeper platform.

• Lower complexity: All zero trust access is managed by the Keeper Vault

• Lower employee risk: No VPNs, No ZTNAs and no Agents

• Lower supply chain risk: No client-side connection apps

• Lower attack surface risk: Zero-knowledge encryption and networking

Keeper Connection Features

• Support for RDP, SSH, VNC, K8s, telnet remote access protocols

• Support for MySQL, PostgreSQL, SQL Server database protocols

• Remote browser isolation (http/https) protocol for web-based apps

• Drag-and-drop file transfer via SFTP to target machines

• Session Recording and playback

• Privileged Session Management

• Role-Based Access Controls

To get started with Keeper Connections, proceed to the next section.

Overview

Post-rotation scripts (PAM Scripts) are user-defined software programs that can perform privilege automation tasks. Scripts can be attached to any PAM resource records in the vault. Depending on the PAM record the script is attached to, the script will execute either on the Keeper Gateway, or the remote host where password rotation occurred.

The following table shows all the available PAM Records and where the attached script will execute:

Rotation Options on PAM User Records

When setting up rotation on a record on a PAM User record, you can select from one of the following methods:

• General

• IAM User

• Run PAM scripts only

When the "General" or "IAM User" methods are selected, Keeper will attempt to rotate the credentials using built-in capabilities based on the information stored in the record.

When the "Run PAM scripts only" option is selected, Keeper will skip the default rotation task and immediately run the attached PAM scripts on the gateway.

Order of Execution

Scripts will be executed in the following order:

1. Scripts attached on PAM User records

2. Scripts attached on PAM Machine, PAM Database, or PAM Directory Record types

3. Scripts attached on PAM Configuration Record types

If multiple scripts are attached to a record, scripts will be executed in the order they appear on the PAM Record.

Common Use Cases

Here are some of the use cases made possible with Keeper Post-Rotation Scripts:

• Custom rotation scripts for any type of target

• Revoking access to a resource

• Sending notifications to team members

• Propagating the password change to other systems

• Any other custom privilege automation task

Documentation included

• Inputs and outputs

• Attaching scripts

• Code Examples

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.

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.

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

In addition to these policies, we recommend protecting the Gateway Configuration secrets .

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.

In AWS environments, the configuration can be .

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.

If a Post-Rotation script requires access to other secrets beyond those passed in automatically, users are strongly encouraged to use the or the tool.

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

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:

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 Linux 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 for more information on the PAM User.

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 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 Linux Machine, the recipient can connect to the Linux Machine on the PAM Machine record without having direct access to the linked credentials.

• Learn more about

Overview

In this section, you will learn how to rotate user credentials within the Azure network environment across various target systems. Rotation works on the devices configured and attached to the Azure Active Directory (Azure AD) which can also be your default directory.

KeeperPAM can rotate the password for Azure AD users, service accounts, local admin users, local users, managed services, databases and more.

KeeperPAM Record Types

Configurations for the Azure Active Directory are defined in the PAM Configuration section of Keeper Secrets Manager.

Configurations for the Azure AD joined devices are defined in the PAM Directory, PAM Machine, and PAM Database record types. The credentials and user accounts are defined in PAM User records. The following table shows the supported Azure AD joined devices with Keeper Rotation and their corresponding PAM Record Type:

Prerequisites for Rotation

Prior to rotating user credentials within your Azure environment, you need to make sure you have the following information and configurations in place:

1. All Azure AD joined devices that you want to use with Rotation need to be created and configured within your Azure Active Directory

2. To successfully configure and setup Rotation within your Azure Network, the following values are needed for your :

1. Make sure all the Azure services or Azure AD joined devices you plan on using for rotation have access to the Azure Active Directory.

2. Create a custom role to allow application to access/perform actions on various Azure resources. For more information see the document.

Setup Steps

At a high level, the following steps are needed to successfully rotate passwords on your Azure network:

1. Create Shared Folders to hold the PAM records involved in rotation

2. Create PAM Machine, PAM Database and PAM Directory records representing each resource

3. Create PAM User records that contain the necessary account credentials for each resource

4. Link the PAM User record to the PAM Resource record.

5. Assign a Secrets Manager Application to all of the shared folders that hold the PAM records

6. Install a Keeper Gateway and add it to the Secrets Manager application

7. Create a PAM Configuration with the Azure environment setting

8. Configure Rotation settings on the records

Use Cases:

Overview

KeeperPAM Password Rotation is able to automatically manage the "log on" credentials for Windows services and scheduled tasks.

When rotation is performed for a specific PAM User record, the Keeper Gateway will update the credentials for all services and scheduled tasks on the associated PAM Machine, and restart the services. One PAM User record can be associated to any number of PAM Machine records, allowing you to update the services and scheduled tasks across a fleet of servers.

Prerequisites

This guide assumes the following tasks have already taken place:

• are configured for your role

• A Keeper Secrets Manager has been created

• Your is online

• The Keeper Gateway can communicate over WinRM or SSH to the target machine:

  • WinRM: Enabled and running on port 5986. Verification: Run winrm get winrm/config to verify that WinRM is running. See for installation help. OR...

  • SSH: Enabled and running on port 22. Verification: Run ssh [your-user]@[your-machine] -p 22 to verify that SSH is running.

• Any Windows-based PAM Machine record being managed needs to have the operating system field set to windows

Setup

Service account and scheduled task management works by associating a PAM User record with one or more PAM Machine records in the vault. This mapping tells the Keeper Gateway to reach into each machine and look up any services running as the user, updating the password and restarting the service.

Using Discovery

When running a , Keeper will automatically locate any services or scheduled tasks that require update when a password is rotated.

If you don't use Discovery, this can be managed directly through the Commander CLI interface using the pam action service commands.

Using the Commander CLI

Keeper Commander provides the necessary commands to associate services and scheduled tasks, such that password rotations will trigger an update and restart of the service.

Installing Commander

If you haven't set up Keeper Commander yet, please follow the .

Locate Gateway UID

Use the pam gateway list command to locate the Gateway UID which manages the machine containing the services and scheduled tasks. You'll need this for the next step.

Locate PAM Machine and PAM User UID

The PAM Machine and PAM User UIDs can be found in Commander by using the ls -l command inside a folder or by using the search command.

The UIDs can also be found in the Keeper Vault "Record Information" screen:

Services Management Commands

Use the pam action service command to instruct Keeper to update services and scheduled tasks on a particular machine, for a particular user, within a network.

Adding a Service

To instruct Keeper to update and restart services and scheduled tasks on a particular machine, use the syntax below:

Removing a Service

To instruct Keeper to remove the associations of services and scheduled tasks on a machine:

Listing all Mappings

To display the current mappings between Gateway, Machine and User accounts where services and tasks need to be managed, use the pam action service list command.

Triggering the service update

To perform a password rotation of a PAM User account, click on the Rotate button from the vault user interface.

To perform the rotation from Commander, run pam action rotate :

To view the status of the rotation job, check the Vault UI or run the pam action job-info command as instructed:

Troubleshooting

Service Restarts

Keeper will not start a service which is currently stopped. We will only restart any actively running services after updating the log on credential.

When troubleshooting a service credential update issue, please make sure of the following:

• For a Windows server, ensure the operating system field is set to windows

• Ensure that the Keeper Gateway can communicate to the PAM Machine via WinRM or SSH.

• Check the Event Viewer > Windows Logs > Application events for any error messages

• Ensure that you are using a PAM Machine record to manage services and scheduled tasks.

Overview

Upon successful rotation of credentials on a PAM record, Keeper executes the attached Post-Rotation scripts with parameters containing information on the involved records, credentials, and user.

Inputs

The Keeper Gateway executes PAM scripts and provides inputs to the script through stdin parameters. These parameters are placed in a Base64 encoded JSON object and piped to the script.

For example, the Keeper Gateway will essentially execute the script on a Linux machine as follows:

Windows:

The following keys can be found in this base64 encoded JSON object:

Additional Info on records field

The records key value is a Base64, JSON array of dictionaries. This array will include the following data:

• PAM Configuration information

• Related PAM Machine, PAM Database, or PAM Directory Record Data

• Additional Records supplied when uploading the post-rotation scripts

• User Record Data

Each dictionary object will contain:

• uid - The UID of the Vault record.

• title - The title of the Vault record.

• The rest of the dictionary will contain key/value pairs of the record's data where the key will be the label of the field. If the field does not contain a label, the field type will be used. If the key already exists, a number will be added to the key.

Outputs

Upon execution of the PAM Script, an array is returned containing instances of RotationResult for each script that was executed. The class RotationResult has the following attributes:

• uid - Keeper Vault record UID that has the script attached

• command - Command that was issued to the shell

• system - Operating system the script will run upon

• title - Title of the script attached to the Keeper Vault record

• name - Name of the script attached to the Keeper Vault record

• success - Was the script successful?

  • Linux and macOS - Script returned in a 0 return code.

  • Windows - Script returned a True status.

• stdout - The stdout from the execution of the script

• stderr - The stderr from the execution of the script

Additionally, the following methods can be used to determine if the script was a success, or not:

With this, it is possible to customize logging:

Troubleshooting

The class RotationResult has attribute stderr which logs the errors from execution of the script.

Although post rotation script results and information are available via the RotationResult class, errors and outputs of scripts are based on the type of shell the script is executed on. Keeper does not check the stdout or errors of the scripts as Keeper does not know what defines as an error for a customer-controlled script.

For example, if a BASH script does not contain a set -e, the script will continue even if part of the script fails. If the script exits with a 0 return code, the script will be flagged as successful.

Therefore, it is up to the customer to properly handle the outputs and errors of the script.

Overview

In this section, you will learn how to rotate user credentials within the Google Cloud environment across various target systems and services.

KeeperPAM Record Types

Configurations for your GCP environment are defined in the PAM Configuration section of Keeper Secrets Manager. Keeper will use the inherited service account where the Gateway is installed to authenticate with the GCP system and perform rotation.

Configurations for managed resources like Compute Engine, Cloud SQL, and Managed Microsoft AD are defined in the , , and record types. The following table shows the supported AWS managed resources with KeeperPAM and their corresponding PAM Record Type:

Configurations for directory users, database users, or VM users are defined in the record type.

Prerequisites

To successfully rotate Compute Cloud Resource User accounts or Google Workspace Principal accounts, the Keeper Gateway needs to have the necessary service account with the permissions for performing the password rotation.

• See the for more information.

Setup Steps

At a high level, the following steps are needed to successfully rotate passwords on your Google Cloud network:

1. Create Shared Folders to hold the PAM records involved in rotation

2. Create PAM Machine, PAM Database and PAM Directory records representing each resource

3. Create PAM User records that contain the necessary account credentials for each resource

4. Link the PAM User record to the PAM Resource record.

5. Assign a Secrets Manager Application to all of the shared folders that hold the PAM records

6. Install a Keeper Gateway and add it to the Secrets Manager application

7. Create a PAM Configuration with the AWS environment setting

8. Configure Rotation settings on the PAM User records

Use Cases