All pages
Powered by GitBook
1 of 42

Getting Started

Getting Started with KeeperPAM fundamentals

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

Architecture

Technical details on the KeeperPAM platform architecture

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

Architecture Diagram

Keeper Password Rotation architecture diagram and data flow

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.

KeeperPAM Architecture

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.

Vault Security

Security and encryption model of the Keeper Vault

Keeper's platform is built with End-to-End Encryption (E2EE) across all devices and endpoints.

  • Data stored in the platform is encrypted locally and encrypted in transit between the user's devices

  • Information exchanged between Keeper users is encrypted from vault-to-vault

  • Data at rest is encrypted with multiple layers, starting with AES-256 encryption at the record level

  • Data in transit is encrypted with TLS and additional layers of transmission encryption which protects against access MITM, service providers and untrusted networks.

A full and detailed disclosure of all encryption related to data at rest, data in transit, cloud architecture and certifications can be found on the Keeper Enterprise Encryption Model page.

A video covering this model is below.

Vault Encryption & Security Model

Router Security

Security and encryption model of the Keeper Router

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.

Gateway Security

Security and encryption model of the Keeper Gateway service

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 zero-knowledge protocols.

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 security model of Keeper Secrets Manager ensures least privilege and zero knowledge by allocating only specific folders and records that can be decrypted by the service. API requests to the Keeper Cloud are sent with a Client Device Identifier and a request body that is signed with the Client Device Private Key. The server checks the ECDSA signature of the request for the given Client Device Identifier using the Client Public Key of the device.

Like any other Secrets Manager device, access can also be restricted based on IP address in addition to the encryption and signing process.

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 Docker installation method 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 protected with the AWS KMS.

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 Keeper Secrets Manager SDKs or the Secrets Manager CLI tool.

Connection and Tunnel Security

Security and encryption model of Connections and Tunnels

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

KeeperPAM Licensing

Features included with the PAM License

KeeperPAM Licensing Requirements

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

  • Keeper Business or Keeper Enterprise License

  • Privileged Access Manager Add-On

    • 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 enterprise license trial. 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 is a cloud-native privileged access solution that requires only a lightweight gateway installation, while Keeper Connection Manager (KCM) is a fully self-hosted solution. For more information, visit this page.

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:

License Type
License Model

Business or Enterprise License

Number of Users using the Business or Enterprise Features

Privileged Access Manager Add-On

Number of Users using the Business or Enterprise Features AND PAM Features

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 MSP Consumption Model allows MSPs and their Managed Companies (MCs) to allocate Keeper licenses to their users and pay only for used licenses at the beginning of the following month.

KeeperPAM will be a Secure Add-On that MSPs can add or remove at any time for their Managed Companies.

Features available with the KeeperPAM Add-On are listed here.

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?

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

Enforcement Policies

Role-based enforcement policy settings for KeeperPAM

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

Policy
Definition
Commander CLI

Can create applications and manage secrets

Allow users to create and manage KSM application

ALLOW_SECRETS_MANAGER

Keeper Gateway

Policy
Definition
Commander CLI

Can create, deploy, and manage Keeper Gateways

Allow users to create, setup, and manage Keeper Gateways

ALLOW_PAM_GATEWAY

Keeper Rotation

Policy
Definition
Commander CLI

Can configure rotation settings

Allow users to configure Rotation settings on PAM User and PAM Configuration Record Types

ALLOW_CONFIGURE_ROTATION_SETTINGS

Can rotate credentials

Allow users to rotate credentials on PAM User Record Types

ALLOW_ROTATE_CREDENTIALS

Keeper Connection Manager (KCM)

Policy
Definition
Commander CLI

Can configure connection settings

Allow users to configure Connection and Session Recordings settings on PAM Machine, PAM Directory, PAM Database and PAM Configuration Record Types

ALLOW_CONFIGURE_PAM_CLOUD_CONNECTION_SETTINGS

Can launch connections

Allow users to launch connections on PAM Machine, PAM Directory, PAM Database Record Types

ALLOW_LAUNCH_PAM_ON_CLOUD_CONNECTION

Can view session recordings

Allow users to view Session Recordings

ALLOW_VIEW_KCM_RECORDINGS

Keeper Tunnels

Policy
Definition
Commander CLI

Can configure tunnel settings

Allow users to configure Tunnel settings on PAM Machine, PAM Directory, PAM Database and PAM Configuration Record Types

ALLOW_CONFIGURE_PAM_TUNNELING_SETTINGS

Can start tunnels

Allow users to start tunnels on PAM Machine, PAM Directory, PAM Database Record Types

ALLOW_LAUNCH_PAM_TUNNELS

Remote Browser Isolation (RBI)

Policy
Definition
Commander CLI

Can configure remote browsing

Allow users to configure Remote Browser and Session Recordings settings on PAM Remote Browsing and Configuration Record Types

ALLOW_CONFIGURE_RBI

Can launch remote browsing

Allow users to launch remote browsing on PAM Remote Browsing Record Types

ALLOW_LAUNCH_RBI

Can view RBI session recordings

Allow users to view RBI Session Recordings

ALLOW_VIEW_RBI_RECORDINGS

Discovery

Discovery is currently only available on Keeper Commander. The UI is coming soon.

Policy
Definition
Commander CLI

Can run discovery

Allow users to run discovery

ALLOW_PAM_DISCOVERY

Legacy Policies

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

Policy
Definition
Commander CLI

Legacy allow rotation

Allow users to perform password rotation

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"

Vault Structure

Understanding the Keeper Vault structure and organization for KeeperPAM

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

Typical Folder Setup for KeeperPAM

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.

Linked Credentials in the Users folder

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.

Human users with access to a Shared Folder
Applications and Machines with access to a Shared Folder

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.

Secrets Manager Applications

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.

Devices

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.

Keeper Gateway

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.

PAM Configuration

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.

Creating a PAM Resource

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

PAM Record Type
Supported Assets

PAM Machine

Windows, Linux, macOS devices, VMs, EC2 instances, Azure VMs, Network devices and other operating systems.

PAM Database

MySQL, PostgreSQL, SQL Server, MongoDB, MariaDB, Oracle

PAM Directory

Active Directory, Azure AD, OpenLDAP

PAM Remote Browser

Web-based Applications, self-hosted apps, cloud apps, any http or https target.


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.

PAM User linked to PAM Resource

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

PAM User settings

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

Record Linking

KeeperPAM migration of records to new linked format

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.

Splitting Resource and Credentials

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.

Finish Record Splitting

Click "Next" to finish the conversion. After this is completed, a new record in the same folder will contain the linked credential.

Converted Resource with Split Credential

Once the resource has been split, PAM capabilities including connections, tunnels and rotations can be enabled.

Applications

Secrets Manager Applications with KeeperPAM

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.

One-Time Access Token

After creating the application, it is managed from the Secrets Manager screen. You can then assign additional devices or Keeper Gateways.

Managing Applications

Applications can be added to new or existing Shared Folders.

Creating a Shared Folder

Edit the Shared Folder to assign the application.

Add Application to Shared Folder

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.

  • Secrets Manager CLI

  • Developer SDKs

  • Integrations

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.

Assigning a Gateway to an Application

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

Create a Gateway and associated applications

The "Project Name" is used to create a PAM Configuration, Gateway, Application and optionally a set of example folders and records.

Gateway Creation Wizard

Devices

Keeper Secrets Manager Devices with KeeperPAM

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

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

Add a device using One-Time Access Token and IP Lockdown
Access Token Generated

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.

Creating a new device with Configuration File method
Device created with Configuration method

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

Gateways

Installation and setup of the Keeper Gateway

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.

Platform
Compatibility

Docker (Linux or Windows host w/ x86)

  • All features supported

Linux (RHEL 8, Rocky Linux 8)

  • All features supported

Docker (Linux host on ARM)

  • No Remote Browser Isolation

Linux Binary Install (Ubuntu, Debian)

  • No Remote Browser Isolation

  • Limited connection protocols

Windows Binary Install

  • No Remote Browser Isolation

  • No database connections

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:

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

Creating a Gateway

Creating a Keeper Gateway

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.

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

1

Create a Secrets Manager Application

  • In the Keeper Web Vault or Desktop App user interface, create a Shared Folder. This Shared Folder will contain the PAM resource records.

  • Navigate to the "Secret Managers" tab on the left and click on "Create Application" to create a KSM application

  • In the prompted window:

    • Enter the name of your KSM application

    • Choose the Shared Folder

    • Set the Record Permissions for Application to "Can Edit"

    • Click on "Generate Access Token" and then click on "OK"

    • You can safely ignore the first One-Time Access Token generated for the newly created KSM application. When creating a Keeper Gateway device, a different One-Time Access Token will be created.

Create a KSM Application
2

Generate the Gateway Token

  • From the Application screen, open the Gateways tab

  • Click on Provision Gateway

  • Select a name for the Gateway and the operating system

  • Follow the on-screen instructions based on the type of install

Windows Gateway

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

Docker Installation

Instructions for installing Keeper Gateway on Docker

Overview

This document contains information on how to install, configure, and update your Keeper Gateway on Docker. The Docker container is built upon the base image of Rocky Linux 8 and it is hosted in DockerHub.

For full PAM capabilities, use a Linux host with a x86 AMD processor.

Prerequisites

  • A Linux host with a x86 AMD processor

  • docker and docker-compose installed (see Docker Install for help)

Note: The syntax is docker-compose for servers, but on a local Docker Desktop it might be docker compose (with no space).

Create a Gateway

A new Gateway deployment can be created by clicking on Create New > Gateway from the Web Vault or Desktop App (version 17.1 or newer required).

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

Installation

1

Docker Compose

A Docker Compose file is provided through the Vault UI. Typically this file would be saved in your local environment as docker-compose.yml in your preferred folder. An example is below:

services:
      keeper-gateway:
        platform: linux/amd64
        image: keeper/gateway:latest
        shm_size: 2g
        security_opt:
          - seccomp:./docker-seccomp.json
          - apparmor=unconfined
        environment:
          ACCEPT_EULA: Y
          GATEWAY_CONFIG: XXXXXXXXXXXXXXXXX

The only required environment variable setting is GATEWAY_CONFIG which is the resulting base64-encoded configuration provided when creating a Gateway device.

2

SecComp File

Download this file called docker-seccomp.json and place it in the same folder as your Docker Compose file.

Github Location:

Download the file below by clicking on "Download Raw File":

https://github.com/Keeper-Security/discovery-playground/blob/main/guacd-docker-seccomp.jsongithub.com

Curl Command:

curl -O https://raw.githubusercontent.com/Keeper-Security/KeeperPAM/refs/heads/main/gateway/docker-seccomp.json
3

Start the Service

Ensure that you are located in the folder where the docker-compose.yml is saved. Executing the following command will run the Keeper Gateway container in the background, as specified in the docker compose file:

docker compose up -d

Logging

When running the latest version of the Keeper Gateway, you'll see the output in the logs like below:

docker compose logs keeper-gateway
Docker Logs from Keeper Gateway

On the Vault UI in the Secrets Manager > Applications > Gateways screen, the Gateway will show Online.

Gateway is Online

Gateway Service Management

Starting the service

docker compose up -d

Stopping the service

docker compose stop

Restarting the service

docker compose restart

Connecting to the Gateway container

docker compose exec keeper-gateway bash

Enable Debugging

If you need to enable verbose debug logs on the Gateway, enable debug logging by adding the below environment section variables to your Docker Compose file:

services:
      keeper-gateway:
        .....
        environment:
          KEEPER_GATEWAY_LOG_LEVEL: "debug" # logs for gateway
          LOG_LEVEL: "debug" # logs for guacd

After debug is enabled, restart the service with docker compose restart

Tailing the logs:

docker compose logs -f keeper-gateway

Updating

Executing the following command will update the Keeper Gateway container to the latest version and restart the service:

docker compose pull
docker compose down
docker compose up -d

Start up automatically

Adding the "restart" parameter in the docker-compose.yml file will assign a restart policy to the environment:

restart: always

Starting Gateway on Reboot

If you would like to force the host operating system to automatically start the Keeper Gateway on a Docker installation, follow these steps (Linux host).

First, create a .service file in /etc/systemd/system/keeper-gateway.service

[Unit]
Description=Keeper Gateway Docker Compose
Requires=docker.service
After=docker.service

[Service]
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=/home/ec2-user
ExecStart=/usr/local/bin/docker-compose up -d
ExecStop=/usr/local/bin/docker-compose down
User=ec2-user
Group=docker

[Install]
WantedBy=multi-user.target

NOTE:

  • Replace /home/ec2-user with the path to your docker-compose.yml

  • Replace ec2-user user with your user running Docker

  • Replace docker group with your defined group

Then enable the service:

sudo systemctl daemon-reload
sudo systemctl enable keeper-gateway.service
sudo systemctl start keeper-gateway.service

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.

Connecting to the Host Instance

A very useful capability of the Keeper Gateway is being able to open connections and tunnels to the host machine. By adding the extra_hosts section to your docker compose file with a value of host.docker.internal:host-gateway, you can open sessions directly to the host.

Example docker compose with the Gateway container:

services:
      keeper-gateway:
        platform: linux/amd64
        image: keeper/gateway:latest
        shm_size: 2g
        restart: always
        extra_hosts:
          - "host.docker.internal:host-gateway"
        security_opt:
          - seccomp:./docker-seccomp.json
          - apparmor=unconfined
        environment:
          ACCEPT_EULA: Y
          GATEWAY_CONFIG: xxxxxxxx

Enabling this option allows you to establish a Connection to the host. For example, to open an SSH connection:

  • Create a PAM User record with the SSH private key

  • Create a PAM Machine record with the hostname to host.docker.internal and port 22

  • Activate the SSH connection in PAM settings referencing the PAM User

Upgrading the Keeper Gateway service through the host

If you use KeeperPAM to SSH over to the host service, you can upgrade the container by running the container update of the gateway in the background:

docker-compose pull
nohup docker-compose up -d keeper-gateway &

Network Configuration

The Keeper Gateway establishes outbound-only connections and does not require any inbound firewall rules. The following outbound connections must be allowed:

Destination
Port Needed
More Info

Keeper Cloud (keepersecurity.[com|eu|com.au|jp|ca|us])

TLS Port 443

Communicates with Keeper Cloud to access target infrastructure via native protocols (e.g., SSH, RDP)

Keeper Router (connect.keepersecurity.[com|eu|com.au|jp|ca|us])

TLS Port 443

Communicates with Keeper Router to establish secure, real-time WebSocket connections

Keeper KRelay Server (krelay.keepersecurity.[com|eu|com.au|jp|ca|us])

TCP and UDP opened on Port 3478 Outbound access to TCP and UDP ports 49152 through 65535

Facilitates secure and encrypted relay connections between end-user's vault and target systems via the Gateway

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.

References:

  • DockerHub listing: https://hub.docker.com/r/keeper/gateway

  • Quick reference for Installing Docker and Docker Compose on Linux

Linux Installation

Instructions for installing Keeper Gateway on Linux

Overview

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

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

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.

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

Network Configuration

The Keeper Gateway establishes outbound-only connections and does not require any inbound firewall rules. The following outbound connections must be allowed:

Destination
Port Needed
More Info

Keeper Cloud (keepersecurity.[com|eu|com.au|jp|ca|us])

TLS Port 443

Communicates with Keeper Cloud to access target infrastructure via native protocols (e.g., SSH, RDP)

Keeper Router (connect.keepersecurity.[com|eu|com.au|jp|ca|us])

TLS Port 443

Communicates with Keeper Router to establish secure, real-time WebSocket connections

Keeper KRelay Server (krelay.keepersecurity.[com|eu|com.au|jp|ca|us])

TCP and UDP opened on Port 3478 Outbound access to TCP and UDP ports 49152 through 65535

Facilitates secure and encrypted relay connections between end-user's vault and target systems via the Gateway

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.

Checksum Verification

Keeper Gateway SHA256 hashes for the latest version are published at the below location:

https://keepersecurity.com/pam/latest.txt

Calculating and verifying the checksum:

Linux

sha256sum keeper-gateway_linux_x86_64
cat keeper-gateway_X.X.X_SHA256SUMS | grep keeper-gateway_linux_x86_64

PowerShell

Get-FileHash -Algorithm SHA256 keeper-gateway_windows_x86_64.exe | Format-List
Get-Content keeper-gateway_X.X.X_SHA256SUMS | Select-String keeper-gateway_windows_x86_64.exe

Windows Installation

Instructions for installing Keeper Gateway on Windows

Overview

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

Prerequisite

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

Installation

The latest Keeper Gateway for Windows is downloaded from here:

  • Download the Keeper Gateway for Windows

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

Keeper Gateway for Windows

New Installs

Upon installation of the service, select "Enter a Keeper One-Time Access Token" and supply the token provided by when you created a Gateway on the Vault. After installation, the service will automatically start up and register with the Keeper cloud.

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.

    • Use service account - Use the specified service account, otherwise the account installing the gateway will be used.

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

    • Enable automatic updates

  • Turn on debug logging - Enable verbose logging on the gateway log files. NOT recommended for production environments. Only use this when debugging with Keeper support.

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

Service Account Setup

One-Time Access Token

The final step prior to successfully installing the Keeper Gateway as service is to enter the One-Time Access Token provided from the Keeper Vault.

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

Keeper Gateway Service

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:

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

Verbose Logging Mode

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.

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.


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 Keeper Gateway establishes outbound-only connections and does not require any inbound firewall rules. The following outbound connections must be allowed:

Destination
Port Needed
More Info

Keeper Cloud (keepersecurity.[com|eu|com.au|jp|ca|us])

TLS Port 443

Communicates with Keeper Cloud to access target infrastructure via native protocols (e.g., SSH, RDP)

Keeper Router (connect.keepersecurity.[com|eu|com.au|jp|ca|us])

TLS Port 443

Communicates with Keeper Router to establish secure, real-time WebSocket connections

Keeper KRelay Server (krelay.keepersecurity.[com|eu|com.au|jp|ca|us])

TCP and UDP opened on Port 3478 Outbound access to TCP and UDP ports 49152 through 65535

Facilitates secure and encrypted relay connections between end-user's vault and target systems via the Gateway

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.

Checksum Verification

Keeper Gateway SHA256 hashes for the latest version are published at the below location:

https://keepersecurity.com/pam/latest.txt

Calculating and verifying the checksum:

Linux

sha256sum keeper-gateway_linux_x86_64
cat keeper-gateway_X.X.X_SHA256SUMS | grep keeper-gateway_linux_x86_64

PowerShell

Get-FileHash -Algorithm SHA256 keeper-gateway_windows_x86_64.exe | Format-List
Get-Content keeper-gateway_X.X.X_SHA256SUMS | Select-String keeper-gateway_windows_x86_64.exe

Auto Updater

Instructions for installing and configuring the Auto Updater for the Keeper Gateway.

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.

By default, the Auto Updater is disabled when installing the Keeper Gateway

We recommend enabling the Auto Updater to ensure you receive the most recent security and functionality enhancements. The Auto Updater verifies all Keeper Gateway downloads by checking the GPG signature of hash value, which are then utilized to checksum each file.

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.

Windows Automatic Updates

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.

Sharing Gateways

Sharing the Keeper Gateway with other admins

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

User Permissions

When sharing a KSM application with other users, the following permissions can be assigned:

Permission
Description

Member

Can view the application and use the gateways associated with the application

Sharing Implications

Shared Folders

Shared folders assigned to a KSM application are accessible by the devices and gateways associated with the application. When sharing a KSM application with another user, if the user does not already have access to the shared folders associated with the application, those folders will be automatically shared with the user.

The level of access the user receives to these shared folders depends on their assigned role in the application:

  • If the user is added as a "Member":

    • The user receives the "No User Permissions" shared folder permissions

If the user already had access to any of the shared folders before being added to the KSM application, their existing folder permissions remain unchanged and are not overwritten.

Records

Records can be directly assigned to a KSM application via Keeper Commander secrets-manager app share command.

When sharing a KSM application with another user, if the user does not already have access to the records associated with the application, those records will be automatically shared with the user. The level of access the user receives to these records is "View Only".

Note: Adding individual records to a KSM application requires using Keeper Commander.

Removing a user from the KSM application

Removing a user from the KSM application does not revoke their permissions from the shared folders. Folder access must be manually removed if desired.

Outcomes

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

Alerts and SIEM Integration

Monitoring Gateway events and integrating with your SIEM

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 Reporting, Alerts & SIEM integration

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)

KeeperPAM Events

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.

Set Alert for Gateway Offline

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

Gateway Offline Alert

Email alerts contain event information

Email Alert for Gateway Offline

Health Checks

Monitoring the Keeper Gateway using health checks

Overview

This document describes the health check functionality implemented for the KeeperPAM Gateway. Health checks provide essential monitoring capabilities that solve several common operational challenges. Health checks require the Keeper Gateway 1.5.5 or newer.

Docker Container Lifecycle Management

Problem: When a gateway goes offline or loses connection, Docker containers continue running and report as "healthy" even though the gateway inside is not functioning properly. This creates misleading container status and prevents proper automated recovery.

Solution: With health checks enabled, Docker can properly monitor the gateway's actual operational status and automatically restart or terminate containers when the gateway is unhealthy.

Load Balancer Integration

Problem: Load balancers need to know which gateway instances are actively handling connections to route traffic appropriately.

Solution: Health check endpoints allow load balancers to automatically remove unhealthy instances from rotation and add them back when they recover.

Monitoring and Alerting

Problem: Operations teams need real-time visibility into gateway status across multiple deployments and environments.

Solution: Health checks integrate with monitoring systems (Prometheus, Nagios, Datadog, etc.) to provide automated alerting and dashboards showing gateway health across your infrastructure.

Service Orchestration

Problem: In Kubernetes or other orchestration platforms, services need to know when gateways are ready to accept connections and when they should be restarted.

Solution: Health checks provide the necessary endpoints for readiness probes, liveness probes, and automated restart policies.

Automated Recovery

Problem: Manual intervention is required to detect and restart failed gateway instances.

Solution: Health checks enable automated monitoring scripts and orchestration tools to detect failures and trigger recovery procedures without human intervention.

IMPORTANT: The health check server is disabled by default. You must explicitly enable it with the --health-check flag or by setting the environment variable KEEPER_GATEWAY_HEALTH_CHECK_ENABLED=true when starting the gateway.


Quick Start / Common Issues

Step 1: Start the gateway with health check enabled:

gateway start --health-check

Step 2: Only after the gateway is running with health check enabled, you can check its health:

gateway health-check

If you get an error like "Could not connect to health check server", it means you haven't completed Step 1.

If you see "Exception No such command 'keeper-gateway.exe'", you're using the wrong command syntax. Always use gateway as the command name.


Complete Configuration Examples

Here are comprehensive examples showing how to start the gateway and check its health in different configurations:

Configuration
Start Command
CLI Health Check
Curl Health Check

Basic HTTP

gateway start --health-check

gateway health-check

curl http://127.0.0.1:8099/health

HTTP with Auth

gateway start --health-check --health-check-auth-token mytoken

gateway health-check --token mytoken

curl -H "Authorization: Bearer mytoken" http://127.0.0.1:8099/health

HTTPS (SSL)

gateway start --health-check --health-check-ssl --health-check-ssl-cert /path/cert.pem --health-check-ssl-key /path/key.pem

gateway health-check --ssl

curl -k https://127.0.0.1:8099/health

HTTPS with Auth

gateway start --health-check --health-check-ssl --health-check-ssl-cert /path/cert.pem --health-check-ssl-key /path/key.pem --health-check-auth-token mytoken

gateway health-check --ssl --token mytoken

curl -k -H "Authorization: Bearer mytoken" https://127.0.0.1:8099/health

Custom Port

gateway start --health-check --health-check-port 8443

gateway health-check --port 8443

curl http://127.0.0.1:8443/health

Custom Host

gateway start --health-check --health-check-host 0.0.0.0

gateway health-check --host 0.0.0.0

curl http://0.0.0.0:8099/health

Production Setup

gateway start --health-check --health-check-host 0.0.0.0 --health-check-port 8443 --health-check-ssl --health-check-ssl-cert /etc/ssl/cert.pem --health-check-ssl-key /etc/ssl/key.pem --health-check-auth-token $(cat /etc/secrets/token)

gateway health-check --host 0.0.0.0 --port 8443 --ssl --token $(cat /etc/secrets/token)

curl -k -H "Authorization: Bearer $(cat /etc/secrets/token)" https://0.0.0.0:8443/health

Output Format Examples

Output Format
CLI Command
Description

Simple Status

gateway health-check --ssl --token mytoken

Returns OK: Gateway is running and connected (exit code 0) or CRITICAL: ... (exit code 1)

Detailed Info

gateway health-check --ssl --token mytoken --info

Key=value pairs suitable for monitoring scripts

JSON Format

gateway health-check --ssl --token mytoken --json

Full JSON response matching HTTP endpoint

Troubleshooting Commands

Issue
Test Command
Expected Result

Check if server is running

curl http://127.0.0.1:8099/health

Connection success or "Connection refused"

Test SSL connectivity

curl -k https://127.0.0.1:8099/health

SSL handshake success or SSL error

Test authentication

curl -k -H "Authorization: Bearer wrongtoken" https://127.0.0.1:8099/health

{"error": "Invalid authentication token"}

Check server binding

curl http://0.0.0.0:8099/health

Success if bound to 0.0.0.0, failure if bound to 127.0.0.1

Error Messages and Troubleshooting

The CLI health check provides detailed error messages to help diagnose issues:

Authentication Errors (HTTP 401)

CRITICAL: Authentication failed when connecting to https://127.0.0.1:8099/health
ERROR: Invalid or missing authentication token.

Possible fixes:
1. Check if auth token is required:
   curl -k https://127.0.0.1:8099/health
2. Provide the correct auth token:
   gateway health-check --ssl --token YOUR_TOKEN
3. Check gateway startup logs for the configured token

Connection Errors

CRITICAL: Could not connect to health check server at http://127.0.0.1:8099/health
ERROR: Connection failed.

Possible causes:
1. Health check server is not running
2. Wrong host/port combination
3. Network connectivity issues
4. SSL/non-SSL mismatch

Troubleshooting steps:
1. Verify gateway is running with health check enabled:
   gateway start --health-check
2. Check if server is using SSL:
   gateway health-check --ssl
3. Verify host and port:
   Current: 127.0.0.1:8099
4. Test with curl:
   curl http://127.0.0.1:8099/health

SSL Certificate Errors

CRITICAL: SSL error connecting to health check server at https://127.0.0.1:8099/health
ERROR: SSL certificate validation failed.

Possible causes:
- Self-signed certificate (try curl with -k flag)
- Invalid certificate path
- Certificate expired

Implementation

The Gateway health check is implemented using Bottle, a lightweight WSGI micro web-framework for Python. Bottle was chosen for the following advantages:

  • Minimal dependency (single file, ~60KB in size)

  • Enhanced security over the built-in Python HTTP server

  • Proper request routing and handling

  • Better error management

  • Thread safety

  • Production-ready with minimal overhead

CLI Health Check

You can check the gateway's health from the command line:

gateway health-check

This command returns:

  • Exit code 0 if the gateway is healthy

  • Exit code 1 if the gateway is not running or not healthy

  • Text output indicating the status (OK/CRITICAL/WARNING)

For detailed output in a machine-parsable format (one key=value pair per line):

gateway health-check -i

For JSON format output (matching the HTTP endpoint format):

gateway health-check -j

If your health check server is using SSL:

gateway health-check --ssl

If your health check server requires authentication:

gateway health-check --ssl --token your_auth_token

If your health check server is running on a non-default port:

gateway health-check --port 8123

If your health check server is running on a different host:

gateway health-check --host 10.0.0.5

The detailed output includes:

  • Gateway version

  • Connection status

  • WebSocket metrics (when available)

  • Process information (in background mode)

This makes it suitable for monitoring scripts and cron jobs.

Note: The CLI health check command requires the HTTP health check server to be running. If the health check server is not running, the command will return an error message suggesting to enable the health check server.


HTTP Health Check

The gateway includes a secure HTTP health check endpoint that can be enabled with environment variables or command line arguments.

Configuration

The health check server can be configured using environment variables or command line arguments:

Environment Variables

Environment Variable
Purpose
Default

KEEPER_GATEWAY_HEALTH_CHECK_ENABLED

Enable HTTP health check (1, true, yes)

Disabled

KEEPER_GATEWAY_HEALTH_CHECK_PORT

Port for HTTP server

8099

KEEPER_GATEWAY_HEALTH_CHECK_HOST

Host address to bind to

127.0.0.1

KEEPER_GATEWAY_HEALTH_CHECK_AUTH_TOKEN

Authentication token for requests

None

KEEPER_GATEWAY_HEALTH_CHECK_USE_SSL

Enable SSL (1, true, yes)

Disabled

KEEPER_GATEWAY_HEALTH_CHECK_SSL_CERT

Path to SSL certificate

None

KEEPER_GATEWAY_HEALTH_CHECK_SSL_KEY

Path to SSL private key

None

Command Line Arguments

When starting the gateway, you can also use these command line arguments:

--health-check               Enable the health check server
--health-check-port INT      Port for the health check server (default: 8099)
--health-check-host STRING   Host address to bind to (default: 127.0.0.1)
--health-check-auth-token    Auth token for the health check server
--health-check-ssl           Enable SSL for the health check server
--health-check-ssl-cert      Path to SSL certificate
--health-check-ssl-key       Path to SSL private key

Command line arguments take precedence over environment variables when both are specified.

Example Commands

Basic health check with default settings:

gateway start --health-check

Custom port and authentication token:

gateway start --health-check --health-check-port 9000 --health-check-auth-token mysecrettoken

Bind to all interfaces (only in secure environments):

gateway start --health-check --health-check-host 0.0.0.0

Enable SSL with certificate and key:

gateway start --health-check --health-check-ssl --health-check-ssl-cert /path/to/cert.pem --health-check-ssl-key /path/to/key.pem

Complete example with all options:

gateway start --health-check --health-check-port 8443 --health-check-host 10.0.0.5 --health-check-auth-token mysecrettoken --health-check-ssl --health-check-ssl-cert /path/to/cert.pem --health-check-ssl-key /path/to/key.pem

Usage

When enabled, the HTTP health check endpoint will be available at:

http://localhost:8099/health

Or with SSL:

https://localhost:8099/health

Response Format

The endpoint returns:

  • HTTP 200 if the gateway is healthy

  • HTTP 503 if the gateway is not healthy

  • JSON response with details:

{
  "status": "healthy",
  "message": "Gateway is running and connected",
  "details": {
    "timestamp": 1742849941,
    "version": 1,
    "connection_status": "connected",
    "websocket": {
      "uptime_seconds": 85,
      "uptime_human": "1m 25s",
      "last_ping_received_seconds_ago": 10,
      "latency_ms": 75,
      "last_ping_sent_timestamp": 1742850455,
      "last_pong_received_timestamp": 1742850455
    }
  }
}

The response includes:

  • status: Overall health status ("healthy" or "unhealthy")

  • message: Human-readable description of the status

  • details: Detailed information about the gateway

    • timestamp: Current server timestamp

    • version: API version

    • connection_status: Current connection status ("connected", "disconnected", etc.)

    • websocket: WebSocket connection metrics

      • uptime_seconds: WebSocket connection uptime in seconds

      • uptime_human: Human-readable uptime (e.g., "1m 25s")

      • last_ping_received_seconds_ago: Seconds since the last ping was received

      • latency_ms: Round-trip latency of the last ping-pong in milliseconds

      • last_ping_sent_timestamp: Unix timestamp when the last ping was sent

      • last_pong_received_timestamp: Unix timestamp when the last pong was received

Example Responses

Healthy Gateway:

{
  "status": "healthy",
  "message": "Gateway is running and connected",
  "details": {
    "timestamp": 1742849941,
    "version": 1,
    "connection_status": "connected",
    "websocket": {
      "uptime_seconds": 85,
      "uptime_human": "1m 25s",
      "last_ping_received_seconds_ago": 10,
      "latency_ms": 75,
      "last_ping_sent_timestamp": 1742850455,
      "last_pong_received_timestamp": 1742850455
    }
  }
}

Unhealthy Gateway:

{
  "status": "unhealthy",
  "message": "Gateway is not properly connected (status: reconnecting)",
  "details": {
    "timestamp": 1742850874,
    "version": 1,
    "connection_status": "reconnecting",
    "websocket": {
      "uptime_seconds": 1018,
      "uptime_human": "16m 58s",
      "last_ping_received_seconds_ago": 324,
      "latency_ms": 77
    }
  }
}

Note that some metrics like latency_ms, last_ping_sent_timestamp, and last_pong_received_timestamp may not always be present in the response. The availability of these metrics depends on the current state of the WebSocket connection and the timing of ping/pong messages.

Status Update Delays

The health check reflects the current state of the WebSocket connection, but there may be a delay in status updates.

Delayed Status Updates

When connectivity is lost, it may take up to 2 minutes for the health check to report an "unhealthy" status, as the gateway attempts to reconnect. Similarly, when connectivity is restored, it may take up to 2 minutes for the health check to reflect a "healthy" status.

This latency is intentional and allows the gateway to attempt reconnection without immediately reporting failures for transient connectivity issues.

Security

The HTTP health check includes the following security features:

  1. Authentication: When KEEPER_GATEWAY_HEALTH_CHECK_AUTH_TOKEN is set, requests must include the token in the Authorization header:

    Authorization: Bearer <token>
  2. SSL/TLS: When SSL is enabled, all communication is encrypted. You must provide a valid certificate and private key.

  3. Localhost binding: The server binds to localhost only by default, not exposing the endpoint over the network.

  4. Security Headers: The health check server adds the following security headers to responses:

    • X-Content-Type-Options: nosniff

    • X-Frame-Options: DENY

    • Content-Security-Policy: default-src 'none'

  5. Rate Limiting: Automatic rate limiting is applied to non-localhost connections (60 requests per minute per IP).

  6. Information Protection: When the server is bound to a non-localhost address, sensitive information is automatically redacted from the response.

  7. Forced SSL: SSL is automatically enforced when binding to non-localhost interfaces.

TLS Compatibility

The health check server is configured to support a wide range of clients by:

  • Using secure TLS defaults (TLS 1.2+ minimum) for maximum security

  • Supporting modern cipher suites for strong encryption

  • Automatically handling protocol negotiation for HTTP and HTTPS

For clients that support modern TLS versions, use standard curl commands:

curl -k -H "Authorization: Bearer your_token" https://localhost:8099/health

Docker-Specific Configuration Requirements

When running Keeper Gateway inside Docker, special configuration is required to expose the health check to the host or external systems:

Binding to 0.0.0.0

  • The health check server must bind to 0.0.0.0 to be reachable outside the container.

  • 127.0.0.1 restricts access to within the container only.

SSL Enforcement

  • When using 0.0.0.0, Keeper Gateway forces SSL to protect health check data.

  • You must provide a valid certificate and key or the server will not start.

Authentication Requirement

  • If binding to 0.0.0.0, you must also specify an AUTH_TOKEN to secure the endpoint.

Docker Compose Example

services:
  keeper-gateway:
    image: keeper/gateway:latest
    ports:
      - "8099:8099"
    volumes:
      - ./certs:/certs:ro
    environment:
      KEEPER_GATEWAY_HEALTH_CHECK_ENABLED: true
      KEEPER_GATEWAY_HEALTH_CHECK_HOST: "0.0.0.0"
      KEEPER_GATEWAY_HEALTH_CHECK_PORT: 8099
      KEEPER_GATEWAY_HEALTH_CHECK_USE_SSL: true
      KEEPER_GATEWAY_HEALTH_CHECK_SSL_CERT: /certs/healthcheck.crt
      KEEPER_GATEWAY_HEALTH_CHECK_SSL_KEY: /certs/healthcheck.key
      KEEPER_GATEWAY_HEALTH_CHECK_AUTH_TOKEN: mysecrettoken

Generate a Self-Signed Certificate

mkdir -p certs
openssl req -x509 -nodes -days 365 \
  -newkey rsa:2048 \
  -keyout certs/healthcheck.key \
  -out certs/healthcheck.crt \
  -subj "/CN=localhost"

Test the Endpoint from the Host

curl -k -H "Authorization: Bearer mysecrettoken" https://localhost:8099/health

Example Linux Configuration

# Enable HTTP health check
export KEEPER_GATEWAY_HEALTH_CHECK_ENABLED=true
export KEEPER_GATEWAY_HEALTH_CHECK_PORT=8099
export KEEPER_GATEWAY_HEALTH_CHECK_AUTH_TOKEN=mysecrettoken

# Start the gateway
gateway start

Or using command line arguments:

gateway start --health-check --health-check-port 8099 --health-check-auth-token mysecrettoken

Self-Signed SSL Certificates

For testing or internal use, you can generate self-signed certificates to enable SSL/TLS encryption:

# Generate a private key
openssl genrsa -out healthcheck.key 2048

# Generate a certificate signing request (CSR)
openssl req -new -key healthcheck.key -out healthcheck.csr -subj "/CN=localhost"

# Generate a self-signed certificate (valid for 365 days)
openssl x509 -req -days 365 -in healthcheck.csr -signkey healthcheck.key -out healthcheck.crt

# Set the environment variables
export KEEPER_GATEWAY_HEALTH_CHECK_ENABLED=true
export KEEPER_GATEWAY_HEALTH_CHECK_USE_SSL=true
export KEEPER_GATEWAY_HEALTH_CHECK_SSL_CERT=/path/to/healthcheck.crt
export KEEPER_GATEWAY_HEALTH_CHECK_SSL_KEY=/path/to/healthcheck.key
export KEEPER_GATEWAY_HEALTH_CHECK_PORT=8443  # Typical HTTPS port
export KEEPER_GATEWAY_HEALTH_CHECK_AUTH_TOKEN=mysecrettoken

# Start the gateway
gateway start

Or using command line arguments:

gateway --health-check --health-check-port 8443 --health-check-ssl --health-check-ssl-cert /path/to/healthcheck.crt --health-check-ssl-key /path/to/healthcheck.key --health-check-auth-token mysecrettoken start

When using self-signed certificates, your HTTP client will need to be configured to trust the certificate or ignore SSL verification (not recommended for production).

Monitoring Integration

This endpoint can be used with monitoring systems like:

  • Prometheus with blackbox exporter

  • Nagios/Icinga

  • Zabbix

  • Datadog

  • AWS CloudWatch

  • Any monitoring system that can perform HTTP checks

Advanced Configuration

Advanced Keeper Gateway Configurations

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:

  • Storing Gateway Configuration in AWS KMS

  • Gateway Configuration with Custom Fields

Gateway Configuration with AWS KMS

Storing and protecting the Keeper Gateway Configuration using AWS KMS

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.

  • Docker Installation

  • Linux Installation

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.

Select Configuration Method
Copy the Base64 Configuration

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.

Create Secret using Plaintext formatting

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

Secret Name and Description
View Secrets

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

Gateway Configuration with Custom Fields

Advanced configuration of the Keeper gateway with Keeper Vault custom fields

These configuration capabilities are functional and currently in an experimental phase, and we invite users to actively explore and utilize them. We are actively evaluating their functionality and performance, with the intention of considering them for official integration into our product in the future.

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:

Custom Field Name
Type
Default Value
Description

Shell

Text

None

Allows you to specify a custom shell path that the Gateway will use when executing rotation and post-rotation scripts. This gives you control over the environment in which these scripts run. Example Value: C:\MY\SHELL

NOOP

Text

False

Allows you to control whether the Gateway performs the primary rotation operation or proceeds directly to execution of the post-rotation script.

If set to True the Gateway will skip the rotation process and proceed directly in executing the post-rotation script(s). Example Value: True

Kerberos

Text

False

Specifically designed for WinRM connections using Kerberos authentication. By default, the Gateway automatically decides whether to use Kerberos based on certain rules, and If these conditions are met, the Gateway will attempt to use Kerberos for WinRM. However, if you encounter issues with this automatic detection, setting this field to True will override the default behavior and force the Gateway to use Kerberos for WinRM. Example Value: True

Private Key Type

Text

ssh-rsa

Gateway Version 1.3.4+ This custom field pertains to the type or algorithm of the private key stored in a record. When adding a private key to a record, users do not need to take any additional action regarding its type or algorithm. The system is designed to automatically recognize and use the same algorithm as the existing private key during the rotation process. If the algorithm in use is ECDSA, the key size will also be preserved during the rotation. Available Options if needed to overwrite the key type: ssh-rsa (Note: 4096 bits)

ssh-dss (Note: 1024 bit, obsolete) ecdsa-sha2-nistp256

ecdsa-sha2-nistp384

ecdsa-sha2-nistp521

ssh-ed25519

Private Key Rotate

Text

True

Gateway Version 1.3.4+

TRUE - (Default) If the custom field doesn't exist, the private key will be rotated if it exists.

FALSE - The private key won't be rotated, even if it exists. Users should pick this if they wish to retain the private key in the record without any rotations.

Note:

  • The custom fields values are not case-sensitive.

PAM Configuration

Creating a PAM Configuration in the Keeper Vault

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:

  • Local Network

  • AWS

  • Azure

  • Domain Controller

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

Field
Description
Notes

Title

Name of PAM configuration record

Ex: US-EAST-1 Config

Gateway

The configured gateway

See docs for more info

Application Folder

The shared folder where the PAM Configuration data will be stored

Best practice is to create a folder with limited access to admins. See Security Note (1) below

PAM Settings

List of Zero-Trust KeeperPAM features that should be enabled

See this section for more info

Default Rotation Schedule

Specify frequency of Rotation

Ex: Daily

Port Mapping

Define alternative default ports

Ex: 3307=mysql See port mapping docs

Security Note (1) The PAM Configuration information is stored as a record in the vault inside the specified Application Folder and may contain secrets. Therefore, we recommend that the Application Folder should be limited in access to only privileged admins.

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

Field
Description
Notes

Network ID

Unique ID for the network

This is for the user's reference

Ex: My Network

Network CIDR

Subnet of the IP address

Ex: 192.168.0.15/24 Refer to this for more info

AWS Environment

Field
Description
Notes

AWS ID

A unique id for the instance of AWS

Required, This is for the user's reference Ex: AWS-US-EAST-1

Access Key ID

From an IAM user account, the Access key ID from the desired Access key.

Leave Empty when EC2 instance role is assumed.

Secret Access Key

The secret key for the access key.

Leave Empty when EC2 instance role is assumed.

Region Names

AWS region names used for discovery. Separate newline per region

Ex: us-east-2 us-west-1

Port Mapping

Any non-standard ports referenced. Separate newline per entry

Ex: 2222=ssh 3390=rdp

  • See additional information on AWS Environment Setup

Azure Environment

Field
Description
Notes

Azure ID

A unique id for your instance of Azure

Required, This is for the user's reference Ex: Azure-1

Client ID

The application/client id (UUID) of the Azure application

Required

Client Secret

The client credentials secret for the Azure application

Required

Subscription ID

The UUID of the subscription (i.e. Pay-As-You-GO).

Required

Tenant ID

The UUID of the Azure Active Directory

Required

Resource Groups

A list of resource groups to be checked. If left blank, all resource groups will be checked. Newlines should separate each resource group.

  • See additional information on Azure Environment Setup

Domain Controller Environment

Field
Description
Required

DNS Domain Name

The FQDN domain used by the Domain Controller. For example, EXAMPLE.COM and not EXAMPLE.

Yes

Hostname and Port

Hostname and port for the domain controller.

Yes

Use SSL

If using LDAPS (default 636), check the box. If using LDAP (default 389), uncheck the box.

Yes

Scan Network

Scan the CIDRs from the domain controller. Default to False.

No

Network CIDR

Scan additional CIDRs from the field.

No

Port Mapping

Define alternative default ports

No

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:

Field
Description

Rotation

If enabled, allow rotations on privileged user users managed by this PAM configuration

Connections

If enabled, allow connections on resources managed by this PAM configuration

Remote Browser Isolation (RBI)

If enabled, allow RBI sessions on resources managed by this PAM configuration

Tunneling

If enabled, allow tunnels on resources managed by this PAM configuration

Graphical Session Recording

If enabled, visual playback sessions will be recorded for all connections and RBI sessions

Text Session Recording (TypeScript)

If enabled, text input and output logs will be logged for all connections and RBI sessions

AWS Environment Setup

Setting up your AWS environment to work with KeeperPAM

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:

  • EC2 Role Policy

  • IAM User Policy

The following diagram shows the AWS environment hierarchy:

AWS Rotation 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

Managed User Type
IAM Policy

EC2 User

Rotation uses local credentials and no specific AWS permissions are needed.

Managed Database

Rotation uses AWS APIs for PAM Database records and requires: iam:GetUser iam:SimulatePrincipalPolicy rds:ModifyDBInstance rds:DescribeDBInstances

For managing PAM Database or PAM User Records via SQL no AWS permissions are needed.

Directory User

Rotation uses AWS APIs for PAM Directory records and requires:

iam:SimulatePrincipalPolicy ds:DescribeDirectories ds:ResetUserPassword ds:DescribeLDAPSSettings ds:DescribeDomainControllers

IAM User

Rotation uses AWS APIs for PAM User records and requires:

iam:SimulatePrincipalPolicy iam:UpdateLoginProfile iam:GetUser


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

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

Azure Environment Setup

Setting up your Azure environment to work with KeeperPAM

Azure Environment Overview

Resources in your Azure environment can be managed by a Keeper Gateway using Azure App policies and client IDs configured in the PAM Configuration record.

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.

Create Application

Next, go to Home > General > Subscriptions and get your subscription ID. Copy the subscription ID into the Keeper PAM Configuration "Subscription ID" field. For more information on how to get your subscription ID, visit this page.

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.

Client Secret

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.

  • Privileged Authentication Administrator - Can change the password for any user, including a Global Administrator user.

  • Authentication Administrator - Can change the password for any user, except a Global Administrator user.

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

Assign Administrator Role to Keeper Application

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.

This is a complete list of all of the permissions that Keeper Gateway can use, if applicable. Only include those that are needed for 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.

Role

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.

Create Azure Custom Role
Assign Role to Keeper Secrets Manager application member

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:

Field
Description

Rotation

If enabled, allow rotations on privileged user users managed by this PAM configuration

Connections

If enabled, allow connections on resources managed by this PAM configuration

Remote Browser Isolation (RBI)

If enabled, allow RBI sessions on resources managed by this PAM configuration

Tunneling

If enabled, allow tunnels on resources managed by this PAM configuration

Graphical Session Recording

If enabled, visual playback sessions will be recorded for all connections and RBI sessions

Text Session Recording (TypeScript)

If enabled, text input and output logs will be logged for all connections and RBI sessions

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

Local Environment Setup

Setting up your Local environment to work with KeeperPAM

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:

Field
Description
Notes

Title (Required)

Name of PAM configuration record

Ex: Local Configuration

Environment (Required)

Your infrastructure's environment

For this guide, select "Local"

Gateway (Required)

The configured gateway

See docs for more info

Application Folder (Required)

The shared folder where the PAM Configuration data will be stored

Best practice is to create a folder with limited access to admins. See Security Note (1) below

PAM Settings (Required)

List of Zero-Trust KeeperPAM features that should be enabled

See this section for more info

Default Rotation Schedule

Specify frequency of Rotation

Ex: Daily

Port Mapping

Define alternative default ports

Ex: 3307=mysql See port mapping docs

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

Field
Description
Notes

Network ID

Unique ID for the network

This is for the user's reference

Ex: My Network

Network CIDR

Subnet of the IP address

Ex: 192.168.0.15/24 Refer to this for more info

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:

Field
Description

Rotation

If enabled, allow rotations on privileged user users managed by this PAM configuration

Connections

If enabled, allow connections on resources managed by this PAM configuration

Remote Browser Isolation (RBI)

If enabled, allow RBI sessions on resources managed by this PAM configuration

Tunneling

If enabled, allow tunnels on resources managed by this PAM configuration

Graphical Session Recording

If enabled, visual playback sessions will be recorded for all connections and RBI sessions

Text Session Recording (TypeScript)

If enabled, text input and output logs will be logged for all connections and RBI sessions

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

PAM Resources

Guide for using PAM Resource Records in the Keeper Vault for privileged access functionality.

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.

  • What's a Record Type?

KeeperPAM Record Types

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

PAM Record Type
Target Infrastructure

PAM Machine

Windows/macOS/Linux Machines, EC2 Instances, Azure VMs, etc.

PAM Database

MySQL, PostgreSQL, SQL Server, MongoDB, MariaDB, Oracle

PAM Directory

Active Directory, OpenLDAP

PAM Remote Browser

Web-based Applications, internal apps or cloud apps

PAM User

Any local user, remote user, database credential or admin account. PAM User records can also be configured for scheduled or on-demand password rotation.

Record Linking

The PAM User record is special because it can be linked from the other resources. This way, you can share access 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.

Create a new PAM Resource Record

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

Right-click to create PAM Resource Records

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

Selecting a Target

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 Discovery section to learn more.

Bulk Import with Keeper Commander

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

The following sections will describe each of the PAM resources.

PAM Machine

KeeperPAM resource for managing machines on-prem or in the cloud

Overview

A PAM Machine record is a type of KeeperPAM resource that represents a workload, such as a Windows or Linux server.

PAM Record Type
Supported Assets

PAM Machine

Windows/macOS/Linux Machines, EC2 Instances, Azure VMs

Features Available

The PAM Machine resource supports the following features:

  • Password rotation

  • SSH key rotation

  • Zero-trust Connections using RDP, SSH, VNC, K8s and Telnet protocols

  • TCP Tunnels

  • Session recording

  • Sharing access without sharing credentials

  • File transfer through drag-and-drop

Connecting to the PAM machine requires only that the Keeper Gateway has access to the target machine. The Keeper Vault operates independently and does not require direct connectivity to the machine, leveraging Keeper's zero-trust network access model to securely manage access through the Gateway. See the network architecture diagram for more details.

Creating a PAM Machine

Prior to creating a PAM Machine, make sure you have already created a PAM Configuration. The PAM Configuration contains information of your target infrastructure while the PAM Machine contains information of an asset, such as a Windows or Linux server.

To create a PAM Machine:

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

Creating a new PAM Machine record

PAM Machine Record Type Fields

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

Field
Description
Notes

Hostname or IP Address

Address of the machine resource

Required

Port

Port to connect on. The Gateway uses this to determine connection method.

Required Must be a port for SSH or WinRM

Keeper expects 22, 5985, 5986, or an alternative port for SSH or WinRM specified in the PAM Configuration port mapping

Administrative Credentials

Linked PAM User credential used for connection and administrative operations

Required Visit this section for more details

PAM settings

This is where you configure Connection and Tunnel settings for this machine.

Required Visit this section for more details

Operating System

The target's Operating System

For your reference only

SSL Verification

When checked, verifies certificate of host when connecting with SSH

Only applies to certain databases and directories where SSL is optional

Instance Name

Azure or AWS Instance Name

Required if AWS/Azure Machine

Instance Id

Azure or AWS Instance ID

Required if AWS/Azure Machine

Provider Group

Provider Group for directories hosted in Azure

Required if Azure Machine

Provider Region

AWS region of hosted directory

Required if AWS Machine

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 and Administrative Credentials

PAM Settings

Field
Description
Required

PAM Configuration

Associated PAM Configuration record which defines the environment

Required

Administrative Credential Record

Linked PAM User credential used for connection and administrative operations

Required

Protocol

Native protocol used for connecting the session from the Gateway to the target

Required

Session Recording

Options for recording sessions and typescripts

See session recording

Connection Parameters (multiple)

Connection-specific protocol settings which can vary based on the protocol type

Depends on protocol. We recommend specifying the Connection Port at a minimum.

PAM Settings for a PAM Machine resource

Below are a couple examples of PAM Machine records with Connections and Tunnels activated.

PAM Machine Record - Windows
PAM Machine Record - Linux

Examples

Visit the following pages to set up:

  • Linux Machine

  • Azure Virtual Machine

Example: Linux Machine

Configuring SSH Server as a PAM Machine Record

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.

Linux Machine Example

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:

Field
Description
Value

Title (Required)

Title of the PAM Machine Record

Linux Machine

Hostname or IP Address (Required)

Address or RDP endpoint or Server name of the Machine Resource

linux-machine

Port (Required)

Port to connect to the Linux Resource

22

Operating System

The target's Operating System

linux

Instance Name

Azure or AWS Instance Name

Required if AWS/Azure Machine

Instance ID

Azure or AWS Instance ID

Required if AWS/Azure Machine

Provider Group

Azure or AWS Provider Group

Required if a managed Azure Machine

Provider Region

Azure or AWS Provider Region

Required if a managed AWS Machine

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:

Field
Description
Required

PAM Configuration

Associated PAM Configuration record which defines the environment

Required - This is the PAM configuration you created in the prerequisites

Administrative Credential Record

Linked PAM User credential used for connection and administrative operations

Required Visit this section for more details

Protocol

Native protocol used for creating a session from the Gateway to the target

Required - for this example: "SSH"

Session Recording

Options for recording sessions and typescripts

See session recording

Connection Parameters

Connection-specific protocol settings which can vary based on the protocol type.

See this section for SSH protocol settings. We recommend specifying the Connection Port at a minimum. E.g. "22" for SSH.

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 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 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 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 Sharing and Access Control

Example: Azure Windows VM

Configuring an Azure Windows VM as a PAM Machine Record

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.

Example of Azure Windows VM

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:

Field
Description
Value

Title (Required)

Title of the PAM Machine Record

Windows VM

Hostname or IP Address (Required)

Address or RDP endpoint or Server name of the Machine Resource

10.0.1.4

Port (Required)

Port to connect to the Azure VM for rotation. 22 for SSH, 5986 for WinRM

5986

Operating System

The target's Operating System

Set to: Windows

Instance Name

Azure or AWS Instance Name

Required if AWS/Azure Machine webserver-prod-01

Instance ID

Azure or AWS Instance ID

Required if AWS/Azure Machine

Provider Group

Azure or AWS Provider Group

Required if a managed Azure Machine

Provider Region

Azure or AWS Provider Region

Required if a managed AWS Machine

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:

Field
Description
Required

PAM Configuration

Associated PAM Configuration record which defines the environment

Required - This is the PAM configuration you created in the prerequisites

Administrative Credential Record

Linked PAM User credential used for connection and administrative operations

Required Visit this section for more details

Protocol

Native protocol used for connecting from the Gateway to the target

Required - for this example: "RDP"

Session Recording

Options for recording sessions and typescripts

See session recording

Connection Parameters

Connection-specific protocol settings which can vary based on the protocol type

See this section for RDP protocol settings We recommend specifying the Connection Port at a minimum. E.g. "3389" for RDP.

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

PAM Database

KeeperPAM resource for managing databases either on-prem or in the cloud

Overview

In your Keeper Vault, the following assets can be configured on the PAM Database record type:

PAM Record Type
Supported Assets

PAM Database

MySQL, PostgreSQL, SQL Server, MongoDB, MariaDB, Oracle

This guide will cover the PAM Database Record type in more details.

Features Available

The PAM Database resource supports the following features:

  • Password rotation

  • Zero-trust Connections

  • TCP Tunnels

  • Graphical session recording

  • Text session recording (Typescript)

  • Sharing access without sharing credentials

Connecting to the PAM database requires only that the Keeper Gateway has access to the database either through native protocols or AWS/Azure APIs. The Keeper Vault operates independently and does not require direct connectivity to the database, leveraging Keeper's zero-trust network access model to securely manage access through the Gateway. See the network architecture diagram for more details.

Creating a PAM Database

Prior to creating a PAM Database, make sure you have already created a PAM Configuration. The PAM Configuration contains information of your target infrastructure while the PAM Database contains information about the target database, such as the hostname, type (MySQL, PostgreSQL, etc) and port number.

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

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

Create a PAM Database

PAM Database Record Type Fields

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

Field
Description
Notes

Hostname or IP Address

Address of the Database Resource

Required

Port

Port to connect to the Database Resource

Required Standard ports are: PostgreSQL: 5432 MySQL: 3306 Maria DB: 3306 Microsoft SQL: 1433 Oracle: 1521 Mongo DB: 27017

Use SSL

Use SSL when connecting

Connect Database

Database name to connect to

Required for connecting to PostgreSQL, MongoDB, and MS SQL Server

Database Id

Azure or AWS Resource ID

Required if a managed AWS or Azure Database

Database Type

Appropriate database type from supported databases.

If a non-standard port is provided, the Database Type will be used to determine connection method.

Provider Group

Azure or AWS Provider Group

Required if a managed AWS or Azure Database

Provider Region

Azure or AWS Provider Region

Required if a managed AWS or Azure Database

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 and Administrative Credentials

PAM Settings

Field
Description
Required

PAM Configuration

Associated PAM Configuration record which defines the environment

Required

Administrative Credential Record

Linked PAM User credential used for connection and administrative operations

Required Visit this section for more details

Protocol

Native database protocol used for connecting from the Gateway to the target

Required

Session Recording

Options for recording sessions and typescripts

See session recording

Connection Parameters (multiple)

Connection-specific protocol settings which can vary based on the protocol type

Depends on protocol

PAM Settings on Database resource

Below is an example of a PAM Database record with Connections and Tunnels activated.

PAM Database with Connections and Tunnels activated

Examples

Visit the following pages to set up:

  • MySQL Database

  • PostgreSQL Database

  • Microsoft SQL Server Database

Example: MySQL Database

Configuring MySQL DB as a PAM Database Record

Overview

In this example, you'll learn how to configure a MySQL DB in your Keeper Vault as a PAM Database 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 Database Record

Databases such as a MySQL DB can be configured on the PAM Database record type.

Creating a PAM Database

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

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

PAM Database

Configure a MySQL Database on the PAM Database Record

Suppose I have a database with the hostname "db-mysql-1", the following table lists all the configurable fields and their respective values:

Field
Description
Value

Title (Required)

Title of the PAM Database Record

Local MySQL Database

Hostname or IP Address (Required)

Address or RDP endpoint or Server name of the Database Resource

db-mysql-1

Port (Required)

Port to connect to the Database Resource

3306

Use SSL (Required)

Check to perform SSL verification before connecting, if your database has SSL configured

Enabled

Database ID

Azure or AWS Resource ID (if applicable)

Required if a managed AWS or Azure Database

Database Type

Appropriate database type from supported databases.

mysql

Provider Group

Azure or AWS Provider Group

Required if a managed AWS or Azure Database

Provider Region

Azure or AWS Provider Region

Required if a managed AWS or Azure Database

Configuring PAM Settings on the PAM Database

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 MySQL Database:

Field
Description
Required

PAM Configuration

Associated PAM Configuration record which defines the environment

Required - This is the PAM configuration you created in the prerequisites

Administrative Credential Record

Linked PAM User credential used for connection and administrative operations

Required Visit this section for more details

Protocol

Native database protocol used for connecting from the Gateway to the target

Required - for this example: "MySQL"

Session Recording

Options for recording sessions and typescripts

See session recording

Connection Parameters

Connection-specific protocol settings which can vary based on the protocol type

See this section for MySQL protocol settings We recommend specifying the Connection Port at a minimum. E.g. "3306" for MySQL.

Administrative Credential Record

The Admin Credential Record in the PAM Database links a user to the PAM Database record in your Keeper Vault. This linked user is used for authenticating the connection when clicking "Launch".

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

Administrative Credential Record

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 Database Records

PAM Database records can be shared with other Keeper users within your organization. However, the recipient must be assigned to a role with the appropriate PAM enforcement policies in place to utilize KeeperPAM features.

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

  • Learn more about Sharing and Access Control

Sharing PAM Database Records

Setup Complete

The MySQL Database record is set up. The user with the ability to launch connections can now launch an interactive MySQL connection or tunnel to the target database.

MySQL Database Record
Connection to MySQL Database
MySQL Interactive Session

Example: PostgreSQL Database

Configuring PostgreSQL DB as a PAM Database Record

Overview

In this example, you'll learn how to configure a PostgreSQL DB in your Keeper Vault as a PAM Database 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 Database Record

Databases such as a PostgreSQL DB can be configured on the PAM Database record type.

Creating a PAM Database

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

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

PostgreSQL PAM Database Record

Configure a PostgreSQL Database on the PAM Database Record

Suppose I have a database with the hostname "db-postgres-1", the following table lists all the configurable fields and their respective values:

Field
Description
Value

Title (Required)

Title of the PAM Database Record

PostgreSQL Database - postgresuser

Hostname or IP Address (Required)

Address or RDP endpoint or Server name of the Database Resource

db-postgres-1

Port (Required)

Port to connect to the PostgreSQL DB Resource

5432

Use SSL (Required)

Check to perform SSL verification before connecting, if your database has SSL configured

Enabled

Database ID

Azure or AWS Resource ID (if applicable)

Required if a managed AWS or Azure Database

Database Type

Appropriate database type from supported databases.

postgresql

Provider Group

Azure or AWS Provider Group

Required if a managed AWS or Azure Database

Provider Region

Azure or AWS Provider Region

Required if a managed AWS or Azure Database

Configuring PAM Settings on the PAM Database

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 PostgreSQL Database:

Field
Description
Required

PAM Configuration

Associated PAM Configuration record which defines the environment

Required - This is the PAM configuration you created in the prerequisites

Administrative Credential Record

Linked PAM User credential used for connection and administrative operations

Required Visit this section for more details

Protocol

Native database protocol used for connecting from the Gateway to the target

Required - for this example: "PostgreSQL"

Session Recording

Options for recording sessions and typescripts

See session recording

Connection Parameters

Connection-specific protocol settings which can vary based on the protocol type

See this section for PostgreSQL protocol settings We recommend specifying the Connection Port at a minimum. E.g. "5432" for PostgreSQL.

Administrative Credential Record

The Admin Credential Record in the PAM Database links a user to the PAM Database record in your Keeper Vault. This linked user is used for authenticating the connection when clicking "Launch".

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

Administrative Credential Record

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 Database Records

PAM Database records can be shared with other Keeper users within your organization. However, the recipient must be assigned to a role with the appropriate PAM enforcement policies in place to utilize KeeperPAM features.

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

  • Learn more about Sharing and Access Control

Sharing a PostgreSQL Database Record

Setup Complete

The PostgreSQL Database record is set up. The user with the ability to launch connections can now launch an interactive PostgreSQL connection or tunnel to the target database.

Launching interactive CLI session to PostgreSQL
Interactive Connection to PostgreSQL Database

Example: Microsoft SQL Server Database

Configuring Microsoft SQL Server DB as a PAM Database Record

Overview

In this example, you'll learn how to configure a Microsoft SQL Server DB in your Keeper Vault as a PAM Database 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 Database Record

Databases such as a Microsoft SQL Server DB can be configured on the PAM Database record type.

Creating a PAM Database

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

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

SQL Server PAM Database Record

Configure a Microsoft SQL Server Database on the PAM Database Record

Suppose I have a database with the hostname "db-mssql-1", the following table lists all the configurable fields and their respective values:

Field
Description
Value

Title (Required)

Title of the PAM Database Record

Local SQL Database

Hostname or IP Address (Required)

Address or RDP endpoint or Server name of the Database Resource

db-mssql-1

Port (Required)

Port to connect to the Database Resource

1433

Use SSL (Required)

Check to perform SSL verification before connecting, if your database has SSL configured

Enabled

Database ID

Azure or AWS Resource ID (if applicable)

Required if a managed AWS or Azure Database

Database Type

Appropriate database type from supported databases.

mssql

Provider Group

Azure or AWS Provider Group

Required if a managed AWS or Azure Database

Provider Region

Azure or AWS Provider Region

Required if a managed AWS or Azure Database

Configuring PAM Settings on the PAM Database

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 Microsoft SQL Database:

Field
Description
Required

PAM Configuration

Associated PAM Configuration record which defines the environment

Required - This is the PAM configuration you created in the prerequisites

Administrative Credential Record

Linked PAM User credential used for connection and administrative operations

Required Visit this section for more details

Protocol

Native database protocol used for connecting from the Gateway to the target

Required - for this example: "SQL Server"

Session Recording

Options for recording sessions and typescripts

See session recording

Connection Parameters

Connection-specific protocol settings which can vary based on the protocol type

See this section for SQL Server protocol settings We recommend specifying the Connection Port at a minimum. E.g. "1433" for SQL Server.

Administrative Credential Record

The Admin Credential Record in the PAM Database links a user to the PAM Database record in your Keeper Vault. This linked user is used for authenticating the connection when clicking "Launch".

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

Administrative Credential Record

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 Database Records

PAM Database records can be shared with other Keeper users within your organization. However, the recipient must be assigned to a role with the appropriate PAM enforcement policies in place to utilize KeeperPAM features.

When sharing a PAM Database record, the linked admin credentials will not be shared. For example, if the PAM Database is configured with a Microsoft SQL Database, the recipient can connect to the database without having direct access to the linked credentials.

  • Learn more about Sharing and Access Control

Sharing PAM Database Records

Setup Complete

The Microsoft SQL Database record is set up. The user with the ability to launch connections can now launch an interactive SQL connection or tunnel to the target database.

Microsoft SQL Server Database
Connection to a Microsoft SQL Database
Interactive Session with Microsoft SQL Database

PAM Directory

KeeperPAM resource for managing directory services, either on-prem or in the cloud

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.

PAM Record Type
Supported Assets

PAM Directory

Active Directory, OpenLDAP

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

Connecting to the PAM Directory requires only that the Keeper Gateway has access to the target directory service. The Keeper Vault operates independently and does not require direct connectivity to the service, leveraging Keeper's zero-trust network access model to securely manage access through the Gateway. See the network architecture diagram for more details.

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.

Creating a PAM Directory

PAM Directory Record Type Fields

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

Field
Description
Notes

Hostname or IP Address

Address of the directory resource

Required

Port

Port to connect on

Required Typically 389 or 636 (LDAP/LDAPS) Active Directory only supports 636

Use SSL

Use SSL when connecting

Required for Active Directory

Alternative IPs

List of failover IPs for the directory, used for Discovery

Newline separated

Directory ID

Instance ID for AD resource in Azure and AWS hosted environments

Required if Azure Active Directory or AWS Directory Service AWS Example: "d-9a423d0d3b'

Directory Type

Directory type, used for formatting of messaging

Required Must be Active Directory or OpenLDAP

User Match

Match on OU to filter found users during Discovery

Domain Name

domain managed by the directory

Required Example: some.company.com

Provider Group

Provider Group for directories hosted in Azure

Required for directories hosted in Azure

Provider Region

AWS region of hosted directory

Required for directories hosted in AWS Example: us-east-2

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

PAM Settings

Field
Description
Required

PAM Configuration

Associated PAM Configuration record which defines the environment

Required

Administrative Credential Record

Linked PAM User credential used for connection and administrative operations

Required

Protocol

Native protocol used for connecting the session from the Gateway to the target

Required

Session Recording

Options for recording sessions and typescripts

See session recording

Connection Parameters (multiple)

Connection-specific protocol settings which can vary based on the protocol type

Depends on protocol. We recommend specifying the Connection Port at a minimum.

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:

    1. Keeper Connections

    2. Keeper Tunnels

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

PAM Directory with Connection, Rotation and Tunnel Enabled

PAM Remote Browser

KeeperPAM resource for managing remote browser isolation access to a protected web application

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.

PAM Record Type
Supported Assets

PAM Remote Browser

Any http:// or https:// web application, on-prem or in the cloud

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

Connecting to the protected web application requires only that the Keeper Gateway has access to the target website. The Keeper Vault operates independently and does not require direct connectivity to the website, leveraging Keeper's zero-trust network access model to securely manage access through the Gateway. See the network architecture diagram for more details.

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.

Creating a Browser Isolation Record

PAM Remote Browser Record Type Fields

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

Field
Description
Notes

URL

IP or Website address

Required The target URL only needs to be accessible from the Keeper Gateway

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 on a Remote Browser Isolation resource
PAM Settings for Remote Browser Isolation
Autofill Credentials for Remote Browser Isolation

PAM Settings

Field
Description
Required

PAM Configuration

Associated PAM Configuration record which defines the environment

Required

Browser Autofill Credentials

Linked PAM User credential used for autofill

Protocol

Native protocol used for connecting from the Gateway to the target

Required

Session Recording

Options for recording sessions and typescripts

See session recording

Browser Settings (multiple)

Browser-specific protocol settings

See RBI page

PAM Remote Browser resource

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

PAM User

Record Type Details for PAM User Record Type

Overview

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

PAM Record Type
Supported Assets

PAM User

Account credential, IAM user, password or SSH Private Key

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

  • Sharing with time-limited access

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.

Creating a PAM User

PAM User Record Type Fields

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

Field
Description
Notes

Login

Username; exact context and format depends on the associated resource. See Note (1) below.

Required Examples: username username@domain DOMAIN\username

Password

Password of the user

Can be rotated

Private Key

PEM-encoded SSH Private Key associated with user.

Can be rotated

Distinguished Name

Distinguished name; used if associated with a PAM Directory

Required only when the User is managed by a directory Example: CN=Jeff Smith,OU=Sales,DC=demo,DC=COM

If left blank, defaults are attempted depending on the provider type

Managed User

Flag for accounts that are managed by the AWS or Azure IAM systems

Set by Keeper Discovery to indicate that the password cannot be rotated. For example, AWS token-based auth.

Connect Database

Used in certain scenarios if a database name is needed

Edge cases, e.g. using LDAP to connect to a MySQL database

Note(1)

When connecting to Windows machines that are domain-joined:

  • For domain-joined systems, always use the UPN format (user@domain.local) 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.

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.

Field
Description
Notes

Passphrase

Used to decrypt the SSH Private Key for use in connections.

Required if the SSH key is encrypted

Configure rotation settings

On the "Rotation Settings" section of the PAM User vault record, you can configure how credential rotation is managed.

PAM User record editing

Password Rotation Settings

Field
Description
Required

Rotation Type

Specifies which type of rotation is being performed (and which protocol is utilized).

Required "General", "IAM User" or "Run PAM Scripts Only". See below for details.

PAM Resource

For General rotation type, specifies the PAM Resource record which can provide the necessary privilege. For IAM User rotation type, specifies the PAM Configuration utilizing cloud APIs.

Required only for "General" and "IAM User" rotation types

Rotation Schedule

Rotation can be performed on-demand or on a specific schedule.

For advanced scheduling, see the cron spec.

Password Complexity

Applies to password-based rotations, not PEM keys.

Select "Show More" to control special characters and symbols.

Rotation Type

Keeper supports 3 different types of rotation:

  • General: Uses native protocols for performing the rotation, such as LDAP, Databases, SSH keys, etc.

  • IAM User: Uses the cloud-specific APIs for performing rotation, such as AWS IAM users and Azure managed resources. In this case, only the PAM Configuration is required since it contains the necessary

  • Run PAM scripts only: Skips the standard rotation and only executes the attached PAM Scripts.

Password Rotation Settings

The rotation schedule can be set on a specific interval, or using a cron spec.

Custom Schedule
Calendar Settings
Cron Spec

PAM Resource

To complete the Rotation setup, you need to select a resource, which depends on the rotation type.

For a "General" rotation, the Keeper Gateway uses a native protocol for performing the necessary rotation, and the rotation will be executed on the associated PAM Resource supplied. If necessary, the rotation will use the associated administrative credential on the PAM Resource.

In the example below, a Windows service account password is going to be rotated on the associated Windows Server.

Rotation Resource

For an "IAM User" rotation type, the Keeper Gateway will use the referenced PAM Configuration to determine which APIs and methods are used to perform the rotation. In the example below, an IAM user in AWS will use the "AWS (US-WEST-1)" configuration.

When using the IAM User rotation method, it is assumed that the Keeper Gateway either inherits its privilege from the instance role policy, or through explicit access keys that are provided on the PAM Configuration record.

IAM User rotation type

In Summary:

  • The PAM User 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 Keeper Gateway uses the Admin Credential associated to the PAM Machine, PAM Database or PAM Directory resource to perform the rotation with native protocols.

  • For AWS and Azure managed resources, Keeper uses Instance Role permission of the Gateway, or specific PAM Configuration secrets to perform the rotation with APIs.

Examples

Below are some examples of PAM User records.

  • Windows Domain Admin

Windows Domain Admin User
  • Windows Domain User with post-rotation scripts

Windows Domain User with post-rotation scripts
  • AWS IAM User

AWS IAM User
  • Database user

Database user
  • Azure AD User

Azure AD User

Access Controls

KeeperPAM Access Control Implementation

Overview

Access to resources and features in KeeperPAM is governed by a robust cloud-based access control plane, leveraging multiple layers of policies and configuration settings. Devices and gateways are assigned specific permissions, enabling them to access and decrypt data allocated to them from the vault. Users with KeeperPAM management privileges can assign access rights to managed resources with flexibility, offering permanent, time-limited, or just-in-time (JIT) access based on organizational needs.

  • Planning your Deployment

  • Role-Based Enforcement Policies

  • PAM Configuration Settings

  • Application and Device Access Control

  • Device and Gateway IP Locking

  • PAM Resource Sharing and Permissions

  • Record Linking

  • Zero-Trust Access through Connection Sharing

  • Time-limited Access

  • Revoking Access

Planning your Deployment

For optimal use of KeeperPAM, it is recommended to create a dedicated service account user within the Keeper Admin Console. This account will oversee the creation and management of Applications, Shared Folders, Gateways, Resources and their associated rights and permissions.

Vault KSM Application Sharing

Keeper Commander and Vault version 17.3+ support "Application Sharing", which allows multiple administrators to share applications and gateways.

Go to Secrets Manager > Applications > Edit and select the administrators who require management of the application, devices and gateways.

  • Application Admin: Can manage application folders, users, all devices and gateways

  • Application Viewer: Can view and use the application and gateways

Application Sharing

Keeper Commander

Sharing and unsharing applications is available in the Keeper Commander CLI and SDK.

See the secrets-manager app share command.

Role-Based Enforcement Policies

Enforcement Policies determine what overall permissions a user has associated to their role. A role can have administrative abilities, or they can be limited to only using resources assigned to them.

  • From the Admin Console, visit Admin > Roles

  • Either create a new role or modify an existing role

  • Under Enforcement Policies, visit the "Privileged Access Manager" tab

PAM Roles
Example of role with KeeperPAM administration capabilities
Example of a role with the ability to only launch connections and tunnels

A more in-depth look at Admin Console nodes, roles and permissions can be found in the Keeper Enterprise admin guide:

  • Nodes and Organizational Structure

  • Roles, RBAC and Permissions

PAM Configuration Settings

The PAM Configuration acts as a set of "parental controls" for PAM records. It enables or disables specific PAM features for all resources using the configuration.

PAM Configuration
  • More information on PAM Configuration

Application and Device Access Control

When creating an application with its devices and gateways, the admin assigns access to specific shared folders with record permissions. This setup allows controlled vault access for both the gateways and the connected devices interacting with the Keeper vault. By managing permissions at both the application and gateway levels, an extra security layer is added.

Application Permissions

Multiple applications can be associated to a Shared Folder with different levels of permission.

Adding multiple applications to a shared folder

Device and Gateway IP Locking

When creating a new Device or Gateway on a Windows or Linux-based installation method, Keeper provides the option to apply IP locking upon first access. This added security measure is layered on top of the existing device authorization model.

Device and Gateway IP Locking

PAM Resource Sharing and Permissions

As a zero-knowledge platform, Keeper provides resource-level access control through our secure sharing technology, powered by strong encryption. Access to a resource is controlled through both policy (RBAC, ABAC) in addition to encryption. In order to access a resource, the user must be able to decrypt the record in their vault. The decryption process allows the user to establish a zero trust connection to the target system, or simply access a secret.

In the Keeper Vault, Shared Folders control access to any resource managed by KeeperPAM. Resources can be placed inside shared folders just like any other Keeper record.

One of the key benefits of the KeeperPAM platform is the ability to share access to a resource without exposing credentials to the recipient.

A Shared Folder contains PAM Resources, such as:

  • PAM Machine

  • PAM Database

  • PAM Directory

  • PAM Remote Browser

  • PAM User

To ensure least privilege, we recommend splitting the PAM Users into a separate shared folder, in order to restrict what users and devices can access the underlying secrets. When launching our Quick Start Sandbox or using our Gateway wizard, Keeper will automatically place the resources and users into separate shared folders.

For example, this demo environment as seen below provides full access to DevOps, but limits access to only viewing and using resources to the Developers team:

Managing access to PAM Resources

In this scenario, only the DevOps team has access to the Users folder. The Developers are restricted from accessing these credentials.

Managing access to PAM Users

Record Level Permissions

Resource-level permissions in a shared folder limit members from editing or sharing records. Users with view-only access can still use PAM features, like launching sessions, if their role allows it.

Record-level permissions on PAM Resources

To ensure least privilege access, the recommendation is to reduce record-level permissions in a Shared Folder to "View Only". Only the Keeper service account user responsible for building Applications and Gateways should have full administrative capabilities.

Direct Resource Sharing

A record can be shared to an individual user with persistent or time-limited access.

To share an individual record, click on Share and then select the user. Providing view-only access to a resource allows the recipient to launch connections and tunnels to the target without having access to the underlying credentials.

Share an Individual Resource

A user can be assigned standing access or time-limited access to a resource.

Sharing with Time-limited Access

Team Level Permissions

From the Admin Console, a team can optionally be restricted in their ability to edit or re-share records that have been provisioned to the team via shared folders across the entire environment. This only applies to shared folders that have been assigned to a specific team.

Restricting Permissions on Teams

Share Admin Permissions

Managing ownership and permissions of resources and records within the Keeper Vault can be delegated to other Keeper admins through the Share Admin permission.

  • Read more about the Share Admin feature in the Keeper Enterprise docs

Share Admin Permissions

Record Linking

A PAM User record containing credentials can be "linked" to a PAM Resource. Sharing a PAM Resource record to another user does not automatically share the linked credentials. This allows the recipient with view-only access with the ability to launch zero-trust connections without having access to the underlying credentials.

  • Sharing a resource to a user with view-only access only gives them the ability to launch connections and tunnels.

  • Keeper's zero-trust architecture provides access to the target systems without sharing the credential, ensuring least privilege access.

In the example below, a PAM Database is linked to a specific user sqluser. Connections to the database using that account is available to users without access to the actual credential.

Linking a PAM User to a Resource

Here's another example which provides SSH access to a Linux machine without sharing the key:

SSH Access to a machine without the key

Time-Limited Access

Folder and record access can be either persistent or time-limited.

Time-limited Access

Access to the resource can be revoked at a specific date and time.

Revoking Access

Removing a user from a Shared Folder or removing the user from a direct share of the resource will immediately destroy any active sessions or tunnels.

To remove a user from a Shared Folder:

  • Select the Shared Folder

  • Select "Edit" and then remove the user or team from the "Users" tab

  • Click Save

To remove a user from an individual resource

  • Select the record

  • Click on "Sharing"

  • Delete the share

Removing access

If you select "Remove ... from all your shared records", this will revoke access to all resources and destroy any active sessions or tunnels for that user.

Automatic Rotation after Share Expiration

If you have a use case where a PAM User credential needs to be shared to another user, you have the option of automatically rotating the credential after the sharing has expired.

Rotate password upon expiration

Just-In-Time Access (JIT)

KeeperPAM Just-In-Time Access and Zero Standing Privilege

Just-In-Time Access and Zero Standing Privilege

Introduction

KeeperPAM provides comprehensive just-in-time (JIT) access capabilities to help organizations achieve zero standing privilege (ZSP) across their entire IT infrastructure and endpoints. By implementing JIT access controls, organizations can significantly reduce their attack surface by ensuring that privileged access is only granted when needed, for the duration required, and with appropriate approvals.

Understanding JIT and ZSP

Just-In-Time (JIT) Access: Provides users with privileged access only at the moment they need it, for a limited time period, and often with approval workflows.

Zero Standing Privilege (ZSP): A security approach where users have no permanent privileged access to systems, eliminating the risk associated with compromised privileged accounts.

Use Cases

KeeperPAM offers JIT capabilities across multiple scenarios:

Just-in-Time Elevated Access to Infrastructure

Keeper's zero-trust privileged sessions can be established to any target with a single click from the web vault. When configured for JIT, elevated privileges are only granted for the duration of the session and automatically revoked upon session termination.

Supported Connection Protocols:

  • RDP (Remote Desktop Protocol)

  • SSH (Secure Shell)

  • VNC (Virtual Network Computing)

  • HTTP/HTTPS

  • Database connections (MySQL, PostgreSQL, SQL Server, Oracle, etc.)

How to Configure:

  1. In the KeeperPAM resource configuration, navigate to the "JIT" tab

  2. Enable just-in-time elevated access for the target resource

  3. Configure the elevation settings (Ephemeral account or Group/Role elevation)

  4. Update the configuration

Ephemeral Account Creation

KeeperPAM can create temporary accounts with appropriate privileges that exist only for the duration of a privileged session.

Key Features:

  • Automatic creation of temporary privileged accounts when sessions begin

  • Dynamic privilege assignment based on access requirements

  • Complete account removal when sessions terminate

  • No persistent privileged accounts to be compromised

  • Comprehensive logging of all account creation and removal activities

Benefits:

  • Eliminates attack vectors associated with standing privileged accounts

  • Prevents lateral movement using compromised credentials

  • Creates clean audit trails linking specific sessions to temporary accounts

  • Reduces administrative overhead of managing privileged accounts

The Keeper Gateway is responsible for creating a temporary account on the target using the selected account type.

Just-In-Time Ephemeral Account Creation during PAM Sessions

Keeper can create ephemeral accounts on any assigned target resource, such as:

  • Active Directory / LDAP User

  • Windows User

  • Linux User

  • MySQL User

  • PostgreSQL User

  • Microsoft Server SQL User

Group and Role Elevation

Role elevation can be assigned at the Group or Role level. For example, an AWS group or role can be assigned to the connecting user account for the duration of the session.

In the input field, provide Keeper with the identifier of the group or role to elevate during the connection. E.g. for Windows this might be “Administrators” and for AWS this would be the full ARN (e.g. arn:aws:iam::12345:role/Admin).

Just-In-Time Role Elevation during Privileged Sessions

Just-in-Time Elevated Access on Endpoints using PEDM

Keeper Privilege Manager extends JIT capabilities to end-user devices, allowing for precise privilege elevation for specific processes, applications, or tasks without granting full administrative access.

Key Features:

  • Process-level privilege management across Windows, macOS, and Linux

  • Policy-based elevation rules with granular controls

  • User-initiated elevation requests with approval workflows

  • Comprehensive auditing and reporting

How it Works:

  1. Users operate with standard, non-privileged accounts by default

  2. When administrative privileges are needed, users request elevation for specific tasks

  3. Based on policy, requests are auto-approved or routed for manual approval

  4. Elevated privileges are granted only for the specified process or time window

  5. Full audit trails capture all elevation activities

Just-In-Time Access with Keeper Privilege Manager

For more information see:

  • Keeper Privilege Manager


Time-Limited Access with Automated Credential Rotation

KeeperPAM provides time-bounded access to resources with automatic credential rotation.

Key Features:

  • Automated credential rotation on-demand or on a scheduled basis

  • Time-limited access window for authorized users

  • Integration with password rotation policies

  • Complete audit trail of credential changes

Security Benefits:

  • Ensures credentials are never re-used for future sessions

  • Protects against credential theft during access periods

  • Creates cryptographically verifiable access boundaries

  • Maintains compliance with credential rotation requirements

To provide time-limited access to a resource, open the resource from the vault and select Sharing. Add the user as a share recipient, and select Set Expiration.

Time-Limited Access

For more information see:

  • Time-Limited Access

  • Password Rotation

Workflow and Requests for Approval

KeeperPAM includes flexible approval workflows for JIT access requests, ensuring proper oversight of privileged access.

Key Features:

  • Multi-level approval workflows

  • Time-based auto-approval or denial

  • Delegation of approval authority

  • Email and mobile notifications

  • Detailed justification requirements

  • Single-user mode (Check-in / Check-out)

  • MFA enforcement on access

Configuration Options:

  • Required approvers based on resource sensitivity

  • Approval timeouts and escalations

  • Working hours restrictions

  • Maximum session duration settings

  • User-specific approval requirements

Workflow and Requests for Approval

Implementation Best Practices

When implementing JIT access and ZSP with KeeperPAM:

  1. Start with critical systems: Begin your implementation with your most sensitive systems and infrastructure

  2. Define clear policies: Establish clear guidelines for when JIT access is required and who can approve it

  3. Educate users: Ensure users understand how to request elevated access when needed

  4. Monitor and adjust: Regularly review logs and adjust policies based on actual usage patterns

  5. Plan for emergencies: Establish break-glass procedures for critical situations where normal approval workflows may be too slow

Conclusion

KeeperPAM's comprehensive JIT and ZSP capabilities provide organizations with the tools needed to significantly reduce their privileged access attack surface. By implementing these capabilities across your infrastructure, you can ensure that privileged access is strictly controlled, properly approved, and thoroughly audited.

For more information on specific JIT use cases or implementation guidance, contact your Keeper Security account manager or email pam@keepersecurity.com.