1 of 100

KeeperPAM and Secrets Manager

KeeperPAM

KeeperPAM is a modern, cloud-based Privileged Access Manager

Overview

KeeperPAM is a next-gen privileged access management solution that secures and manages access to critical resources, including servers, web apps, databases and workloads.

KeeperPAM consolidates enterprise password management, secrets management, connection management, endpoint privileged management, zero-trust network access, remote browser isolation and a cloud-based access control plane in one unified product.

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

About this Documentation

This documentation is broken out into the following sections:

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

KeeperPAM vs. Keeper Connection Manager

KeeperPAM is a cloud-native privileged access solution that requires only a lightweight gateway installation, while Keeper Connection Manager (KCM) is a fully self-hosted solution.

KeeperPAM works through outbound-only connections with zero-knowledge encryption, eliminating the need for inbound firewall rules or direct line-of-sight to resources. In contrast, KCM is fully hosted by the customer with control over the authentication, database, web server, reverse proxy and session recordings.

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

Features

KeeperPAM provides the following capabilities:

Zero-trust connections launched from the Vault
Tunnels established from the Desktop App for ZTNA
Sharing connections without exposing credentials
Sharing tunnels on a time-limited basis

Contact the Keeper Team

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

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

Next Steps

of KeeperPAM
Launch the
Deep dive into the

Privileged Access Manager

Setup Steps

Accessing the KeeperPAM platform

Setup Steps

Follow the below steps to start using KeeperPAM.

Quick Start: Sandbox

Quickly and easily get started with a pre-configured PAM setup in your vault

Quick Start Wizard

To learn some KeeperPAM basics, we have created a wizard that is integrated into the Vault. If you select the Docker install method, this wizard will create all the necessary vault records, configurations and a customized Docker Compose file for quickly standing up a sandbox environment in less than 3 minutes.

Activate KeeperPAM

Region

URL

Under Admin > Roles, create a new role for PAM or modify an existing role
Go to Enforcement Policies and open the "Privilege Access Manager" section.
Enable all the PAM enforcement policies
Ensure you are assigned to this role

Run the New Gateway Wizard

Test some PAM features

You can now instantly connect to any of the resources by clicking "Launch" from the record detail view.

Records Created

The wizard will create the following in your vault:

A folder containing Resources and Users in separate shared folders
A MySQL database
A Linux machine with VNC connection to the desktop UI
A Linux machine with SSH connection using an SSH Key

Quick Start Video

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

Screenshots

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

Getting Started

Getting Started with KeeperPAM fundamentals

The Basics

Architecture

KeeperPAM Features

Secrets Manager Features

Commander CLI Features

Enterprise Password Manager

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

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.

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

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

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

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

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

Components

Keeper Gateway

The Keeper Gateway is a service which is installed into the customer's environment and communicates outbound to Keeper services. The Gateway performs the rotation, discovery and connections to assets on the network. The Gateway receives commands from the Keeper Router, then uses Keeper Secrets Manager APIs to authenticate, communicate and decrypt data from the Keeper cloud.

Keeper Router

The Keeper Router is infrastructure in Keeper's cloud that manages connections between Keeper and Rotation Gateways. The Cloud Router provides real-time messaging and communication between the Keeper Vault, customer gateway and Keeper backend services.

Keeper Relay

The Keeper Relay is infrastructure in Keeper's cloud that is responsible for establishing encrypted 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 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

Keeper user performs action (rotation, connection, tunneling, discovery) from the Vault interface, Admin Console, Commander CLI or other endpoint application.
Keeper Gateway establishes an outbound WebSocket connection to the Keeper Router, receives the requests to perform the action.
The Vault Client application establishes a WebRTC connection to the customer's hosted Keeper Gateway.
The Keeper Gateway pulls the necessary secrets from the vault using Keeper Secrets Manager APIs.

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 .

A video covering this model is below.

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.

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?

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.

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.

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.

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.

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:

Advanced Configuration

Advanced Keeper Gateway Configurations

Overview

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

Advanced Configurations

Password Rotation

Keeper password rotation capabilities with Keeper Secrets Manager

Overview

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

Features

Comprehensive Credential Rotation: Automate rotation for machines, service accounts, and user accounts across your infrastructure and multi-cloud environments.
Flexible Scheduling: Schedule rotations to occur at any time or trigger them on demand.
Service Management: Automatically update the log on credentials for Windows services and scheduled tasks after rotation.
Post-Rotation Actions

Architecture

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

How does Password Rotation Work?

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

The record holds the credential that is being rotated.
The Rotation Settings of the PAM User record references a specific PAM Machine, PAM Database or PAM Directory resource. This is the target resource where the rotation is performed.
The uses the Admin Credential associated to the PAM Machine, PAM Database or PAM Directory resource to perform the rotation with native protocols.
For AWS, Azure and GCP resources, the record holds the necessary rights and access keys to perform rotations with cloud native APIs.

Local Network

Password Rotation in the Local Network Environment

Overview

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

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

Setup Steps

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

Create Shared Folders to hold the PAM records involved in rotation
Create PAM Machine, PAM Database and PAM Directory records representing each resource
Create PAM User records that contain the necessary account credentials for each resource
Link the PAM User record to the PAM Resource record.

Use Cases

Database

DB credential Rotation in the Local Environment

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

Databases Supported

Native MySQL

Azure Managed Database

Rotate Azure Managed Database credentials with Keeper

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

Azure SQL
Azure MySQL

Azure Client Secret Rotation

Automatically rotate the secret of an Azure app using Keeper rotation

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

IAM User Access Key

Automatically rotate AWS access keys using Keeper Secrets Manager rotations

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

Managed Database

Rotating AWS RDS accounts with Keeper

Overview

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

Cloud SQL Database User

Rotating Google Cloud SQL Database user accounts with Keeper

Overview

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

Cloud SQL for MySQL:

Cloud SQL for SQL Server:

Cloud SQL for PostgreSQL

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

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:

Make the script executable:

Edit the crontab:

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

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.

Existing Keeper Gateway

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

Verify Installation (Optional)

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

Windows

New Gateway

Download and run the latest version of the Gateway installer.
During installation, check the box "Enable automatic updates".
This setup option will create a new Task Scheduler task for updating the Gateway.

Existing Gateway

Open a command prompt as Administrator.
Install Auto Updater with the following Keeper Gateway command:

Verify Installation (Optional)

Open a command prompt as Administrator.
Verify that Auto Updater has been installed successfully by executing the following Keeper Gateway command:

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:

Status on Windows

Open a command prompt as Administrator
Check the Auto Updater status by executing the following Keeper Gateway command:

Auto Updater Configuration

Configuration on Linux

Edit the crontab that runs Auto Updater.

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

The first part 0 * * * * is the crontab expression which will cause execution to occur every hour at 0 minutes.
The second part is the update command keeper-gateway-update
The option --trust causes explicit trust of the Keeper Gateway GPG public key for verification of downloaded install files.

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:

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:

Troubleshooting

Check the status of the Auto Update

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.

Proxy Configuration

Configure Keeper Gateway to route traffic through corporate HTTP/HTTPS proxy servers for air-gapped or restricted network environments.

Overview

In enterprise environments, network security policies may require internet traffic to flow through a corporate proxy server. Keeper Gateway supports standard HTTP/HTTPS proxy configuration through environment variables and command-line parameters, ensuring compatibility with corporate network architectures.

When proxy support is enabled, the Gateway routes all outbound connections through the specified proxy server, including:

WebSocket connections to Keeper servers
HTTP/HTTPS API calls
Health check endpoints
Version verification requests
TURN credential requests

Proxy support is currently available for Discovery and Rotation operations. PAM connection sessions (SSH, RDP, VNC, database connections, RDP) are not supported through proxies at this time due to the complexity of WebRTC media traffic routing. WebRTC connections require direct network access or TURN server configuration.

Supported Proxy Types

Keeper Gateway supports the following proxy configurations:

HTTP Proxy - Standard HTTP proxy servers (e.g., Squid, Apache Traffic Server)
HTTPS Proxy - Secure proxy connections with TLS
Authenticated Proxies - Proxies requiring username/password authentication
Bypass Lists - Exclude specific domains or IP addresses from proxy routing

Configuration Methods

You can configure proxy settings using either environment variables or command-line parameters. Command-line parameters take precedence over environment variables.

Option 1: Environment Variables

Environment variables provide a standard way to configure proxy settings across all network-aware applications. These variables are recognized by most networking tools and libraries.

Supported Environment Variables

Keeper Gateway recognizes the following environment variables (in order of precedence):

HTTPS_PROXY or https_proxy - Primary proxy configuration (recommended)
HTTP_PROXY or http_proxy - Fallback proxy configuration
NO_PROXY or no_proxy

These are standard environment variable names used across many applications and programming languages. The Keeper Gateway follows this industry convention for seamless integration with existing infrastructure.

Setting Environment Variables

Linux/macOS:

Windows (Command Prompt):

Windows (PowerShell):

With Authentication

Include credentials in the proxy URL:

Special characters in passwords must be URL-encoded. For example, p@ssw0rd becomes p%40ssw0rd.

Option 2: Command-Line Parameters

Command-line parameters provide additional flexibility and override environment variables when both are present.

Available Parameters

Parameter

Description

Example

Docker Deployment with Proxy

When deploying Keeper Gateway in Docker, configure proxy settings in your docker-compose.yml file.

Docker Compose Configuration

Add proxy environment variables to your Gateway service:

The proxy server must be accessible from the Gateway container. If using an external proxy, ensure network connectivity. If deploying a proxy container in the same Docker Compose stack, include it in the depends_on section.

Air-Gapped Docker Environment Example

For complete network isolation, deploy the Gateway with a dedicated proxy container:

In this configuration:

Gateway container has no direct internet access (only on internal: true network)
All internet traffic must flow through the proxy container
Proxy container bridges the air-gapped and public networks
Internal services (databases, application servers) bypass the proxy

Configuration Priority

When multiple configuration sources are present, Keeper Gateway applies settings in the following priority order (highest to lowest):

Individual command-line parameters (--proxy-host, --proxy-port, etc.)
--proxy-url command-line parameter
HTTPS_PROXY environment variable

For bypass lists:

--no-proxy command-line parameter
NO_PROXY environment variable
no_proxy environment variable

Proxy URL Format

Proxy URLs follow standard URI syntax:

Examples

Basic HTTP proxy:

HTTPS proxy:

Authenticated proxy:

Proxy with special characters in password:

Note: URL-encode special characters in usernames and passwords using percent-encoding (e.g., @ becomes %40, ! becomes %21).

NO_PROXY Bypass List

The NO_PROXY setting allows you to exclude specific hosts from proxy routing. This is useful for:

Internal services on the same network
Local resources that don't require proxy access
Services that cannot work through a proxy

Bypass List Format

The bypass list is a comma-separated list of:

Exact hostnames: localhost, internal-server
IP addresses: 127.0.0.1, 192.168.1.100
Domain suffixes: .internal.com

Examples

Basic bypass list:

With domain suffixes:

Docker internal services:

Spaces are automatically trimmed. Both localhost, 127.0.0.1 and localhost,127.0.0.1 work identically.

Verification and Testing

Step 1: Verify Configuration

After starting the Gateway with proxy configuration, check the logs for confirmation:

Step 2: Test Proxy Connectivity

Before starting the Gateway, verify proxy accessibility:

Linux/macOS:

Windows (PowerShell):

If the proxy requires authentication:

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

How to Configure:

In the KeeperPAM resource configuration, navigate to the "JIT" tab
Enable just-in-time elevated access for the target resource
Configure the elevation settings (Ephemeral account or Group/Role elevation)
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

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.

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

Active Directory / LDAP Domain User
Windows User
Linux User
MySQL 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).

Domain User Group Elevation

When elevating an ephemeral Domain User to a group, you must specify the group in Distinguished Name (DN) format.

Example: If the group name is RemoteUsers, the DN would be:

If your group name contains spaces, you must enclose the DN in quotes.

Example: If the group name is Remote Users, the DN would be:

Just-in-Time Elevated Access on Endpoints using PEDM

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:

Users operate with standard, non-privileged accounts by default
When administrative privileges are needed, users request elevation for specific tasks
Based on policy, requests are auto-approved or routed for manual approval
Elevated privileges are granted only for the specified process or time window

For more information see:

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.

For more information see:

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

Configuration Options:

Required approvers based on resource sensitivity
Approval timeouts and escalations
Working hours restrictions
Maximum session duration settings

Implementation Best Practices

When implementing JIT access and ZSP with KeeperPAM:

Start with critical systems: Begin your implementation with your most sensitive systems and infrastructure
Define clear policies: Establish clear guidelines for when JIT access is required and who can approve it
Educate users: Ensure users understand how to request elevated access when needed
Monitor and adjust: Regularly review logs and adjust policies based on actual usage patterns

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 .

Gateway with Docker

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 Keeper Gateway container is built upon the base image of Rocky Linux 8 and it is hosted in DockerHub.

Prerequisites

A Linux host with a x86 AMD processor for all PAM capabilities
docker and docker compose installed (see for help)

Create a Gateway

A new Gateway deployment can be created by clicking on Create New > Gateway from the Web Vault or Desktop App.

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

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

Installation Options

Keeper provides 2 ways of setting up the Gateway:

Option 1: Auto Docker Installation

Keeper's automatic installer will set up the environment for you.

Create a Docker Gateway and Copy the Installation Command

Create a new Gateway with either the or using for the Docker Operating System.

You will be provided with an installation command to paste into your Linux host.

Option 2: Manual Docker Installation

If you prefer to set up the Docker environment yourself, follow the instructions below.

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:

Note: There's a typo in Vault version 17.4 that references gateway-app-armor-profile instead of gateway-apparmor-profile in the provided docker-compose.yml file when creating a new gateway. To fix this issue, remove the extra dash. It needs to be labeled as gateway-apparmor-profile

Logging

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

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

Gateway Service Management

Starting the service

Stopping the service

Restarting the service

Connecting to the Gateway container

Starting the Gateway Automatically on Reboot

In the docker-compose.yml file, ensure that a restart policy is enabled. For example:

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

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 file /etc/systemd/system/keeper-gateway.service

NOTE:

Replace /path/to/install with the path to your docker-compose.yml
Replace myusername user with your user running Docker
Replace docker group with your defined group

Then enable the service:

Important: Ensure that the apparmor file is loaded up and available on reboot

After a reboot, verify that it's running:

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:

After changing the log level, apply the changes to the docker

Tail the logs of the Keeper Gateway using this command:

Updating

Executing the following command will update the Keeper Gateway container to the latest version and restart the 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 for full setup details and examples.

Managing Disk Space

Over time, as new versions of the Gateway are deployed, old Docker images may accumulate on the host server. This can consume a significant amount of disk space. To ensure smooth operation and avoid storage issues, we recommend periodically checking your available disk space and removing unused Docker images.

Checking Disk Space Usage

To view your current disk usage, run the following command on your Keeper Gateway server:

This command displays available disk space on all mounted filesystems in a human-readable format. Pay particular attention to the partition where Docker stores its data (typically /var/lib/docker).

If you notice the disk space running low (for example, more than 80–90% full), it’s a good idea to clean up old Docker images.

Cleaning Up Old Docker Images

When you update the Keeper Gateway, Docker keeps older images on your system. To remove all unused Docker images, you can use the following command:

The -a flag ensures that all unused images are deleted (not just dangling ones).
You may be prompted to confirm the action — type y when prompted.

Example output:

This operation safely removes old images that are no longer used by any running containers.

References:

DockerHub listing:
Quick reference for

Google Cloud Environment Setup

Setting up your Google Cloud environment to work with KeeperPAM

Google Cloud Environment Overview

Overview

Resources in your GCP environment can be managed by a Keeper Gateway using a service account configured in the PAM Configuration record. Optionally this service account can be configured to have domain-wide delegation, enabling Keeper Gateway to rotate passwords for Google Workspace users (GCP principals) discovered during GCP discovery.

The service account must be configured appropriately to enable access to the target GCP resources:

Compute Engine
Cloud SQL
Cloud Resource Manager
Managed Microsoft Active Directory

Additionally, in order to enable Google Workspace user password changes, the service account also needs:

Domain-wide delegation enabled in Google Workspace Admin Console
Scope: https://www.googleapis.com/auth/admin.directory.user
The google_admin_email must have user management permissions in Workspace

See for more details about enabling password rotations for GCP Principals.

Required Service Account Setup

A service account is a special kind of account typically used by an application or compute workload, such as a Compute Engine instance, rather than a person.

The minimal set of permissions needed by the KeeperPAM service account are as follows:

To ensure least privilege, the service account provided in the GCP configuration should be granted these permissions only:

Create a (e.g. KeeperPAM)
Create a Service Account
Assign the role to the Service Account
Create a new JSON Private Key for the Service Account

Save the downloaded file in the Keeper vault for protection. The contents of this file will also be added to the "Service Account Key" field of the PAM Configuration record in the Keeper vault.

Optional Setup for GCP User Password Rotation

You can optionally activate the ability for KeeperPAM to rotate Google Workspace identities by following the steps in this section.

When discovering GCP resources, the system identifies users from IAM policies with the user: prefix (e.g., user:[email protected]). These are typically Google Workspace users who have been granted permissions in your GCP project.

To rotate passwords for these Workspace users, the service account must:

Have domain-wide delegation enabled in Google Workspace
Be authorized with the appropriate OAuth scope
Have an admin email specified that the service account will impersonate

Prerequisites

A Google Cloud Platform project with a service account
Google Workspace admin access
The service account's Client ID (found in the service account details)

Step-by-Step Configuration

Enable Domain-Wide Delegation for the Service Account

Go to the
Navigate to IAM & Admin → Service Accounts
Locate your service account (the one whose key is used in the PAM Configuration)
Click on the service account to view its details

Authorize the Service Account in Google Workspace Admin Console

Go to the
Navigate to Security → Access and data control → API controls
Scroll down to Domain-wide delegation
Click Manage Domain-Wide Delegation

Configure the Google Admin Email

The Google Admin Email is a Google Workspace user account that:

Has administrative privileges in Google Workspace
Specifically has User Management permissions
Will be impersonated by the service account when making password changes

Create or Identify an Admin User

Option A: Use an existing Super Admin

Use the email of an existing Google Workspace Super Admin
Example: [email protected]

Option B: Create a dedicated service admin account (Recommended)

Go to Directory → Users in Google Workspace Admin Console
Click Add new user
Create a user with a name like:
- Name: Keeper Gateway Service

Set up the PAM Configuration Record

In the Keeper Vault > Secrets Manager > PAM Configurations > create a new GCP PAM Configuration record. Set the following:

Service Account Key (JSON format)

This is the key file created above during the Service Account setup. The format is like this:

Google Admin Email

This is only required if GCP service principal rotation is configured.

How It Works

When rotating a password for a GCP user:

The system discovers users from GCP IAM policies (e.g., user:[email protected])
During password rotation, the code:
- Loads the service account credentials from the JSON key
- Requests credentials with the admin.directory.user

Required Permissions Summary

GCP Project Permissions (for Discovery)

The service account needs these IAM permissions in the GCP project:

resourcemanager.projects.getIamPolicy - To discover users from IAM policies

Google Workspace Permissions

The service account needs:

Domain-wide delegation enabled
OAuth Scope: https://www.googleapis.com/auth/admin.directory.user

The Google Admin email account needs:

User Management Admin role (or Super Admin)

Troubleshooting

Error: "No Google Admin email provided"

Cause: The google_admin_email field is not set in the PAM Configuration record
Solution: Add the admin email to the PAM Configuration record

Error: "Permission denied" or "Forbidden"

Cause: Domain-wide delegation not properly configured
Solution:
1. Verify the service account has domain-wide delegation enabled
2. Verify the Client ID is correctly added in Google Workspace Admin Console

Error: "Insufficient permissions"

Cause: The Google Admin email doesn't have sufficient privileges
Solution: Ensure the admin email has User Management Admin role or Super Admin role

Error: "Invalid credentials" or "Authentication failed"

Cause: Service account key is invalid or expired
Solution:
1. Regenerate the service account key in GCP Console
2. Update the PAM Configuration record with the new key JSON

User password change succeeds but user can't log in

Cause: Password policy requirements not met
Solution: Password generation respects these constraints:
- Minimum 8 characters
- At least one lowercase letter

Security Best Practices

Use a dedicated service admin account: Create a separate Google Workspace user specifically for this service rather than using a personal admin account
Limit service account key distribution: Store the service account key JSON securely in Keeper Secrets Manager only
Monitor admin activity: Regularly review the Google Workspace admin audit logs for activities by the service account
Rotate service account keys

Additional Resources

SaaS Plugins

SaaS and REST-based rotation plugins

KeeperPAM SaaS Rotation Plugins

Overview

KeeperPAM supports automated password rotation for various SaaS applications and services, including cloud infrastructure. This feature requires Keeper Gateway version 1.6 or newer. Currently, the configuration of SaaS rotations requires the use of Keeper Commander CLI. The front-end for managing these rotations will be included in an upcoming release of the Web Vault and Desktop App.

SaaS rotations are available as built-in integrations, catalog integrations or custom integrations.

Built-in SaaS Integrations

KeeperPAM includes pre-built integrations for popular services:

Okta - Identity and access management
Snowflake - Cloud data platform
REST APIs - Generic REST endpoint integration
AWS Access Keys - Amazon Web Services credential rotation

Catalog SaaS Integrations

In Keeper's , several new rotation plugins have been created, including:

AWS Cognito
Cisco APIC
and

As new catalog rotations are added, customers may use these rotations within their environments.

Custom Integrations

Following the examples in Keeper's , customers can create their own plugins that are private and only available to their Keeper Gateway. See the section for more information.

Setting Up SaaS Password Rotation

This is accomplished in 3 steps outlined below:

Step 1: Create a SaaS Configuration Record

SaaS rotation configurations are stored as records with custom fields that define the configuration parameters.

Using Keeper Commander CLI

The fastest way to create a SaaS configuration is using the Commander CLI pam action saas config command:

The command will prompt you for the required configuration values specific to your chosen SaaS type. Each of the configuration values is documented in the section below, for built-in and catalog plugins.

You can also just create a Login record with custom fields as defined below.

Okta Configuration Record

Custom Field Name

Description

Required?

Snowflake Configuration Record

Custom Field Name

Description

Required?

REST Configuration Record

Custom Field Name

Description

Required?

AWS Access Key Configuration Record

Custom Field Name

Description

Required?

Note: The admin access key does NOT be set if you using an EC2 instance an attached IAM role or the using an AWS configuration. The plugin with get its credentials from the following in the specified order.

SaaS Configuration Record - Ensure that the Access Key and Secret Key
AWS PAM Configuration - See the for details

Assigning Permissions

Ensure that the roles assigned to your AWS PAM Configuration or to the specific administrative access key / secret key include the below policies required to rotate a target access key:

Azure Client Secret Configuration Record

Custom Field Name

Description

Required?

Note: The administrative application ID and client secret does not be set if you using a PAM Configuration that already has necessary Azure permissions.

The plugin with get its credentials from the following in the specified order.

SaaS Configuration Record
Azure PAM Configuration

Assigning Permissions to Admin Application

In order for the target secret to be rotated, the administrative application must have the necessary Azure role permissions.

Required Microsoft Graph Permissions:

Application.ReadWrite.All

How to Assign:

Go to Azure Portal > Azure Active Directory > App registrations
Select your Administrative app (the one that will rotate secrets)
Go to API permissions > Add a permission
- Choose Microsoft Graph

Cisco IOS EX Configuration Record

Custom Field Name

Description

Required?

Cisco Meraki Configuration Record

Custom Field Name

Description

Required?

API:

Step 2: Associate SaaS Rotation with PAM Users

Once your SaaS configuration record is created, associate that record with one or more PAM User records in the vault.

Create the PAM User record either in the vault, or using the Commander CLI
Using Commander, run the below commands to create the association:

Step 3: Verify Configuration

Check that your SaaS rotation is properly configured on the PAM User record:

This will display all configured SaaS rotations for the specified PAM User, including their current settings.

Performing SaaS Rotation

To perform the rotation from the Commander CLI, use the pam action rotate command:

Managing SaaS Rotations

Remove SaaS Rotation

To remove a SaaS rotation from a PAM User record:

Activate/Deactivate Rotations

You can control whether a SaaS rotation is active by setting the Active custom field:

Set to any value (e.g., "true", "yes", "1") to activate
Remove the field or set to empty/false to deactivate

Custom and Community Plugins

Available Custom Plugins

In addition to built-in integrations, you can use custom plugins for additional services. Keeper maintains a repository of community-contributed plugins:

GitHub Repository:

Check the integrations/ folder for available plugins, which may include:

Additional cloud services
Database systems
Network equipment
Custom enterprise applications

Using Custom Plugins

To use custom plugins in your environment:

1. Set Up Plugin Directory

Configure your PAM Gateway to recognize custom plugins:

2. Deploy Plugin Files

Copy the plugin Python files to your configured directory:

3. Docker Container Setup

If using Docker, mount the plugin directory:

Update the PAM configuration to use the container path:

4. Configure Plugin Access (If Required)

Some plugins may need access to your PAM configuration credentials (e.g., for AWS or Azure integration). Grant access by adding the plugin name to the allow list:

Developing Custom Plugins

If you need a plugin for a service not currently available, you can develop your own using the development environment provided in the repository. The repository includes:

Development and testing tools
Example plugins and templates
API documentation
Testing framework

Visit the for detailed development instructions. To contribute to the community rotation plugin directory, submit a pull request.

Best Practices

Security Considerations

Use dedicated service accounts with minimal required permissions for SaaS integrations
Regularly rotate API keys and tokens used in SaaS configurations
Test rotations in a development environment before production deployment
Monitor rotation logs for failures or authentication issues

Configuration Management

Store SaaS configurations in dedicated shared folders for better organization
Use descriptive names for configuration records (e.g., "Okta Production", "Snowflake Dev")
Document any custom field requirements for team members
Regularly review and update SaaS rotation assignments

Troubleshooting

Check Gateway logs for detailed error messages during rotations
Verify API credentials and permissions in your SaaS applications
Ensure network connectivity between Gateway and target services
Test individual SaaS configurations before associating with multiple users

Support and Resources

Built-in SaaS Types: Supported through standard Keeper support channels
Custom Plugins: Community support via GitHub repository issues
Development Questions: Refer to repository documentation and examples
Enterprise Support: Contact your Keeper representative for assistance with custom integrations

For the most up-to-date list of available plugins and integration examples, regularly check the .