This section will cover additional configurations to modify the Keeper Gateway's default behavior.
Advanced Configurations
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.
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:
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.
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 .
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:
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 .
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:
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
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:
The Vault Client application communicates to the Keeper Router infrastructure to initiate a WebRTC connection that is protected by a ECDH symmetric key that is stored inside the relevant Keeper record.
The Keeper Gateway communicates with the Keeper Router through outbound-only WebSockets. This is described in detail in the Gateway Security section.
The Keeper Gateway utilizes Keeper Secrets Manager APIs to retrieve the necessary secrets from the vault, including the ECDH symmetric key.
For Connections, the Vault Client (using the Apache Guacamole protocol) passes data through the WebRTC connection to the Keeper Gateway that then uses Guacd to connect to the destination found in the Keeper record.
For Tunneling features (port forwarding), a local port is opened up on the local device running Keeper Desktop software. Data sent to the local port is transmitted through the WebRTC connection to the Keeper Gateway and subsequently forwarded to the target endpoint defined in the Keeper record.
Session recordings of connections are protected by an AES-256 encryption key ("recording key") which is generated on the Keeper Gateway on every session. The recording key is additionally wrapped by a HKDF-derived AES-256 resource key.
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.
The Keeper Gateway pulls the necessary secrets from the vault using Keeper Secrets Manager APIs.
The Keeper Gateway performs the action on the target infrastructure (such as rotating a credential or establishing a privileged session) and updates the relevant Keeper vault records.
The Keeper Gateway runs any required privilege automation scripts on the Gateway or target machines using native protocols and APIs.
Client devices securely retrieve the updated record using Keeper Secrets Manager APIs.
Vault end-users interact with the target systems through a zero-trust encrypted session to the target infrastructure.
The vault performs encrypted syncing to the Keeper cloud to retrieve the latest record content.
Keeper's Advanced Reporting & Alerts module logs all events and triggers alerts.
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.
If you are not a Keeper customer or do not have the required license, you can from our website. The free trial includes KeeperPAM full capabilities.
2
Activate Privileged Access Manager
From the Keeper Admin Console, ensure that your Privileged Access Manager subscription is active. Go to the Admin Console > Subscriptions and activate the trial or contact your Keeper customer success manager.
3
Enable PAM Policies
From the Admin Console, enable the corresponding PAM Enforcement Policies.
Login to the Admin Console for your region.
4
Existing Customers: Updating your Gateway
This assumes you are an existing customer with Keeper Secrets Manager and you have a Gateway already deployed. Using the latest Keeper Gateway is required to support the new features. Depending on the operating system, features available will differ.
5
New Customers: Create a new Gateway and Sandbox
Follow the step by step guide in the section of this documentation. A new is available to instantly create a sandbox for exploring some of the connection types.
6
Explore new features
Notes
PAM Features differ between Linux, Docker and Windows versions of the Keeper Gateway.
For a full range of features, use the Docker installation method, or Linux installation method on Rocky Linux or RHEL.
We recommend setting up a Keeper Gateway using the . This provides a customized Docker Compose file that provides an instant sandbox for testing.
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.
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.
By clicking "Convert Now", you'll be asked to confirm the change and the credentials will be separated from the resource and placed in the same folder.
Click "Next" to finish the conversion. After this is completed, a new record in the same folder will contain the linked credential.
Once the resource has been split, PAM capabilities including connections, tunnels and rotations can be enabled.
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
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 CLI
KeeperPAM Events
Events related to KeeperPAM include:
Starting and stopping sessions, tunnels, remote browser isolation
Connection lifecycle (creation, editing and deleting PAM resources)
Recommended Alerts
As a KeeperPAM administrator, it is useful to receive alerts related to Gateway actions, such as when a Gateway goes offline (in case of server outage or system restart).
From the Admin Console, go to Reporting & Alerts > Alerts > select Event Types and set the recipient information.
Event alert details will include the name and UID of the affected Keeper gateway.
Email alerts contain event information
Integrations
Keeper integrates with ITSM platforms for realtime ticket creation, alerting and incident response.
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
Use Cases
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.
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.
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.
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:
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.
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, database management, endpoint privileged management, zero-trust network access, remote browser isolation and a cloud-based access control plane in one unified product.
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 demo environment in less than 2 minutes.
1
Splitting Resource and Credentials
Finish Record Splitting
Converted Resource with Split Credential
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:
From the vault, open the KSM Application you want to share
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.
If you are running a database directly on an EC2 instance in your AWS environment instead of using a managed service, refer to the Local Network > Database documentation for rotating passwords.
You'll be asked to confirm uninstalling the previous Gateway, this is OK
Ensure the "Enter one-time access token" selection is NOT selected
Linux
To update an existing Gateway on Linux:
Retrieving the Configuration
If you are replacing an existing Gateway, get the old base64 configuration string from:
/etc/keeper-gateway/gateway-config.json on Linux or C:\ProgramData\KeeperGateway\config\gateway-config.json on Windows.
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.
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:
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
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.
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
Features
Comprehensive Credential Rotation: Automate rotation for machines, service accounts, and user accounts across your infrastructure and multi-cloud environments.
Flexible Scheduling: Schedule rotations to occur at any time or trigger them on demand.
Service Management: Automatically update the log on credentials for Windows services and scheduled tasks after rotation.
Post-Rotation Actions: Perform custom actions or functionality after rotation takes place.
Access-Based Rotation: Automatically rotate credentials once access expires.
Secure Access Control: Control and audit access to credentials through secure sharing and compliance reporting.
Detailed Audit Logs: Track all rotation events using Keeper’s Advanced Reporting and Alerts Module (ARAM).
Automation with Keeper Commander: Leverage Keeper Commander for fully automated rotation workflows.
Rotation Plugins: Open source Plugin framework provides rotation capabilities with any 3rd party SaaS service.
Architecture
Rotation is performed on the Keeper Gateway and controlled through the Keeper Web Vault, Desktop App or Commander CLI.
Password Rotation System Architecture Diagram
How does Password Rotation Work?
In KeeperPAM, the way Password Rotation works is as follows:
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, Azure and GCP resources, the record holds the necessary rights and access keys to perform rotations with cloud native APIs.
For AWS-deployed Gateways, Keeper uses Instance Role permission of the Gateway to perform the rotation with APIs.
For Azure and Google Cloud managed resources, Keeper uses the Service Account permissions of the Gateway.
The Keeper Gateway enables KeeperPAM features such as Connections, Tunnels, Discovery, and Credential Rotation. With the growing use of PAM, Gateway scaling offers an excellent solution to boost scalability and availability by enabling multiple Gateway instances to run concurrently using the same configuration. This approach increases reliability by efficiently distributing PAM workloads across several Gateway instances, allowing for a greater number of simultaneous connections.
HA Gateway Scaling is available with Keeper Gateway version 1.7.6+ and Commander 17.2+
How Scaling Works
When Gateway scaling is enabled on the Keeper Gateway, you can run multiple Gateway instances using the same Gateway configuration. These instances form a Gateway pool that collectively handles PAM workloads.
Features
Workload distribution: PAM workloads are distributed across the available Gateway instances.
Instance limits: Enforces a configurable maximum number of Gateway instances.
Cross-platform support: Gateway instances can run on any supported platforms.
Scaling Down
Reducing the maximum number of Gateway instances does not stop running Gateways. and requires you to manually stop the gateway instance(s) to align with the new limit. For example, If you set the instance limit to 3 and run 3 active Gateways, all instances will operate normally.
If you later reduce the limit (for example, 3 → 2):
Existing Gateway instances are not automatically shut down.
You must manually stop one instance to meet the new limit.
After the limit is reduced, additional instances will be prevented from starting above the configured maximum.
Setup
Prerequisites
Prior to configuring scaling for your Keeper Gateway, you need the following:
Keeper Gateway version 1.7.6 or higher
version 17.2 or higher
User with the following :
Set the Maximum Number of Gateway Instances
After logging into Keeper Commander, get a list of gateways from this command:
Run the following command for the gateway being configured for scaling:
<GATEWAY_UID> is the UID of the Gateway you are scaling.
<MAX_INSTANCES> is the maximum number of Gateway instances you want to allow.
Example:
The following example allows up to 5 Gateway instances to run concurrently:
Run multiple Gateways using the same config
Use the original Gateway configuration file to initialize additional instances on new servers or environments, ensuring scaling remains enabled.
Each instance started with this configuration will join the same Gateway pool, up to the configured maximum instance limit.
Gateway Configuration File
For more information on the gateway configuration file, visit the following:
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 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
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.
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.
The below link describes how to create a sandbox environment in just a few steps:
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.
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
Create Folders
Share the KSM app to the Shared Folders
Create a Gateway
To initialize a Gateway for or native install methods, the one-time token method is used:
To initialize a Gateway using , the base64 configuration is provided as GATEWAY_CONFIG environment variable as described in the instructions.
Post-Rotation Scripts
Perform privileged automation tasks with Post-Rotation scripts and password rotation
Overview
Post-rotation scripts (PAM Scripts) are user-defined software programs that can perform privilege automation tasks. Scripts can be attached to any PAM resource records in the vault. Depending on the PAM record the script is attached to, the script will execute either on the Keeper Gateway, or the remote host where password rotation occurred.
The following table shows all the available PAM Records and where the attached script will execute:
Record Type
Attached Post Execution Script will execute on
Rotation Options on PAM User Records
When setting up rotation on a record on a PAM User record, you can select from one of the following methods:
General
IAM User
Run PAM scripts only
When the "General" or "IAM User" methods are selected, Keeper will attempt to rotate the credentials using built-in capabilities based on the information stored in the record.
When the "Run PAM scripts only" option is selected, Keeper will skip the default rotation task and immediately run the attached PAM scripts on the gateway.
Order of Execution
Scripts will be executed in the following order:
Scripts attached on PAM User records
Scripts attached on PAM Machine, PAM Database, or PAM Directory Record types
Scripts attached on PAM Configuration Record types
If multiple scripts are attached to a record, scripts will be executed in the order they appear on the PAM Record.
Common Use Cases
Here are some of the use cases made possible with Keeper Post-Rotation Scripts:
Custom rotation scripts for any type of target
Revoking access to a resource
Sending notifications to team members
Documentation included
KeeperPAM Licensing
Features included with the PAM License
KeeperPAM Licensing Requirements
In order to enable and use KeeperPAM, the following are required:
License or..
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.
SaaS Configuration
Automatically rotates credentials for supported cloud-based services.
Overview
SaaS Configuration enables users to automate password rotations for cloud-based services. By rotating passwords and secrets on a defined schedule (or on-demand), you can strengthen security, reduce risk from credential exposure, and support compliance requirements.
With SaaS Configurations, you can:
AWS
Password Rotation in the AWS Environment
Overview
In this section, you will learn how to rotate user credentials within the AWS Cloud environment across various target systems and services.
secrets-manager client add --app "My Infrastructure App" --unlock-ip
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.
Communication with Head
Automatically rotate passwords/secrets for built-in services
Build your own SaaS rotation plugins
Use one of the community plugins (catalog)
Define rotation frequency and criteria
Trigger rotation manually when needed
Supported Services
This system supports password rotation for various SaaS platforms, including:
AWS Access Key (Built-in)
AWS Cognito (Catalog)
Azure Client Secret (Built-in)
Cisco APIC (Catalog)
Cisco IOS XE (Built-in)
Cisco Meraki (Built-in)
Dummy (Catalog)
Elasticsearch API Key (Catalog)
Elasticsearch Service Account Token (Catalog)
Elasticsearch User (Catalog)
JFrog Access Token (Catalog)
JFrog User Password Rotation (Catalog)
Okta (Built-in)
OpenSearch User (Catalog)
Oracle Identity Domain User (Catalog)
REST (Built-in)
ServiceNow User (Catalog)
Snowflake (Built-in)
Splunk Token Rotation (Catalog)
Splunk User Password Rotation (Catalog)
Each service has specific setup requirements (such as API permissions, tokens, or secret formats). Ensure your service account is configured correctly before enabling rotation.
Requirements
To use SaaS Configuration Password Rotation, the following requirements must be met:
Gateway Requirements
PAM Gateway version 1.6 or newer
The Gateway must be online to select it during setup
Vault version 17.6 (Go-live: Feb 2026)
Folder Requirements
The SaaS Configuration record must be stored in the Shared Folder(s) assigned to the selected Gateway (This ensures the Gateway can access and rotate the credential.)
How It Works
SaaS Configuration uses your selected PAM Gateway to securely connect to the target service and update the password/secret. When rotation completes, Keeper updates the stored credential to keep your Vault up to date.
Rotation can be triggered by:
Time-based rotation (scheduled)
Manual rotation (run on demand)
Create & Configure SaaS Configuration
This guide walks you through creating a SaaS Configuration record and applying it to a PAM User for automated password rotation.
Step 1: Create a SaaS Configuration Record
In Keeper, click Create New
Select SaaS Configuration
Select an active Gateway
Only online Gateways are available to select.
Select a Plugin
The available plugins shown are based on the Gateway you selected.
If you don’t see the plugin you need, you may need to create or enable the plugin first.
Choose where to save the record
You must save the SaaS Configuration record in a Shared Folder associated with the selected Gateway.
Click Save
Step 2: Assign the SaaS Configuration to a PAM User
Open the target PAM User record → Edit
Navigate to Rotation Settings
Under Rotation Settings, select the SaaS Configuration record you created in Step 1
Within the Rotation Settings, you can schedule password rotations.
Click Save
Once assigned, Keeper will use that SaaS Configuration whenever the user’s password rotation is executed.
These actions can be managed through Keeper Commander.
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
If you are not a Keeper customer or do not have the required license, you can start a free KeeperPAM trial.
Features Included with KeeperPAM
With the purchase of the Privileged Access Manager add-on, the following features are included:
Secrets Manager with Unlimited API Calls
Unlimited Password Rotations
Unlimited Privileged Sessions / Connections
Unlimited Tunnels
Unlimited Remote Browser Isolation
Session Recordings and Playback
Discovery
Keeper Connection Manager (Self-Hosted)
PAM Audit and Reporting
What is the difference between KeeperPAM and Keeper Connection Manager (Self-Hosted)?
KeeperPAM is a cloud-native privileged access solution that requires only a lightweight gateway installation, while Keeper Connection Manager (KCM) is a fully self-hosted solution. For more information, visit this 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 ManagerAdd-Ons, to cover the 10 users that need PAM functionality.
MSPs
Keeper’s allows MSPs and their Managed Companies (MCs) to allocate Keeper licenses to their users and pay only for used licenses at the beginning of the following month.
KeeperPAM is a that MSPs can add or remove at any time for their Managed Companies.
Features available with the KeeperPAM Add-On are listed 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
KeeperPAM Add-On
Keeper Connection Manager Add-On
Both the Keeper Secrets Manager and Keeper Connection Manager Add-Ons are included as part of the Privileged Access Manager Add-On.
Upgrading from Keeper Secrets Manager Add-On
Upgrading to the Privileged Access Manager Add-On from the Keeper Secrets Manager Add-On will give you:
Access to new KeeperPAM Features
Unlimited API Calls
Upgrading from Keeper Connection Manager Add-On
Upgrading to the Privileged Access Manager Add-On from the Keeper Connection Manager Add-On will give you new KeeperPAM Features which includes accessing both the cloud and self-hosted KCM.
Ready to Upgrade?
To purchase, upgrade, or if you have any questions, contact your Keeper account manager or use our online form.
Web-based Applications, internal apps or cloud apps
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.
Configurations for your AWS environment are defined in the PAM Configurationsection of Keeper Secrets Manager. Keeper will use the inherited EC2 instance role where the Gateway is installed to authenticate with the AWS system and perform rotation. If instance roles are not defined, the AWS Access Key ID and Secret Key can be stored in the PAM Configuration record to authenticate and perform rotations.
Configurations for managed resources like EC2, RDS, and Directory Services are defined in the PAM Machine, PAM Database, and PAM Directoryrecord types. The following table shows the supported AWS managed resources with KeeperPAM and their corresponding PAM Record Type:
AWS Managed Resource
Corresponding Record Type
EC2
PAM Machine
RDS
PAM Database
Directory Service
PAM Directory
Configurations for directory users or IAM users are defined in the PAM Userrecord type.
Prerequisites
To successfully rotate IAM User accounts or EC2 local user accounts, the Keeper Gateway needs to have the necessary AWS role policies with the permissions for performing the password rotation.
If you are not using EC2 instance role policies, the following values are needed in the PAM Configuration:
Field
Description
Access Key ID
This is the Access Key ID from the desired Access Key found in the IAM User account
Set this field to USE_INSTANCE_ROLE if the gateway is deployed to an EC2 Instance that supports instance roles
Secret Access Key
This is the Secret Access Key from the desired Access Key found in the IAM User account
Set this field to USE_INSTANCE_ROLE if the gateway is deployed to an EC2 Instance that supports instance roles
The Keeper Gateway will always first attempt to use the EC2 instance role to authenticate and perform the rotation. If this fails or is not available on the machine, Keeper will use the Access Key ID and Secret Access Key stored in the PAM Configuration.
Setup Steps
At a high level, the following steps are needed to successfully rotate passwords on your AWS network:
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.
Assign a Secrets Manager Application to all of the shared folders that hold the PAM records
Install a Keeper Gateway and add it to the Secrets Manager application
Create a PAM Configuration with the AWS environment setting
Configure Rotation settings on the PAM User records
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.
Privileged Access Manager Policies
Secrets Manager
Policy
Definition
Commander CLI
Keeper Gateway
Policy
Definition
Commander CLI
Keeper Rotation
Policy
Definition
Commander CLI
Keeper Connection Manager (KCM)
Policy
Definition
Commander CLI
Keeper Tunnels
Policy
Definition
Commander CLI
Remote Browser Isolation (RBI)
Policy
Definition
Commander CLI
Discovery
Discovery is currently only available on Keeper Commander. The UI is coming soon.
Policy
Definition
Commander CLI
Legacy Policies
These policies are not required moving forward, but they exist for support of legacy features.
Policy
Definition
Commander CLI
Commander CLI
The CLI enterprise-role command can be used to set these policies through automation. The list of policies related to PAM functionality is listed below.
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:
The following diagram shows the AWS environment hierarchy:
EC2 IAM Role Policy
To create a EC2 IAM policy which supports PAM features such as password rotation and discovery, a role with the appropriate policy settings should be configured then attached to the EC2 instance running the Keeper Gateway.
For KeeperPAM to have the authority to rotate IAM users and RDS databases, the following inline role policy should be modified to meet your needs and ensure least privilege.
To ensure least privilege, the JSON policy should be modified based on which target resources that KeeperPAM will be managing through the "Action" and "Resource" attributes.
Follow these steps to create a new role and apply the policy:
Create role with JSON specified above, or click on IAM > Roles > Create Role > Select "AWS Service" with "EC2 use case".
Attach the policy JSON to the role.
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
IAM User Policy
Using EC2 instance role policy is preferred, however the AWS Access Key ID and Secret Access Key can be directly set in the PAM Configuration. The IAM Admin account needs to be created with the appropriate policy settings configured to access the target resource in AWS.
An sample policy is below.
To ensure least privilege, the JSON policy should be modified based on which target resources that KeeperPAM will be managing through the "Action" and "Resource" attributes.
The steps to create the access keys is below:
Create a new IAM user or select an existing user
Attach the policy to the user
Open the IAM user > Security credentials > Create access key
In addition to these policies, we recommend protecting the Gateway Configuration secrets .
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.
Generate a Configuration
From the Keeper Vault, go to Secrets Manager > Applications and select the application configured with your Gateway. Then select the Gateways tab and select "Provision Gateway".
Select the Gateway initialization method of "Configuration" and click Next.
Alternatively, you can generate a One-Time Access Token and then use the Keeper Gateway's "gateway ott-init" command:
In either case, you'll be provided with a base64 encoded configuration. Save this for the next step.
Create Secret in AWS Secrets Manager
From the AWS Console, go to the Secrets Manager and create a new secret.
Select "Other type of secret"
Select Plaintext and paste the entire base64 value there.
Click Next.
Enter a Secret Name and a description then click Next, Next and Store.
Assign Policy to Instance Role
The EC2 instance role needs to be assigned a policy which provides read access to the specific AWS Secrets Manager key. As an example:
Confirming Access
From the EC2 instance, the below command will confirm the policy has been applied:
Configuration of the Keeper Gateway
Docker Install Method
For Docker installations, remove the GATEWAY_CONFIG entry and add AWS_KMS_SECRET_NAME with the value containing the name of the secret from the AWS secrets manager.
Then update the service with the new environment:
Linux Install Method
Open the Keeper Gateway service unit file:
/etc/systemd/system/keeper-gateway.service
Modify the "ExecStart" line as seen below, replacing YourSecretName with your assigned name.
Apply changes to the service:
If there are any errors starting up, they can be seen through this command:
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
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:
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
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
Administrative Credential Record
The Admin Credential Record in the PAM Machine links the admin user to the PAM Machine record in your Keeper Vault. This admin user is used for performing password rotations and authenticating connections.
User Accounts can be configured on the PAM User record. Visit this for more information.
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
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 .
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
For Discovery, the following fields are required, otherwise they are optional:
Field
Description
Notes
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
Configuring PAM Features on PAM Record Types
After creating the PAM configuration, visit the following pages to:
Configure
Configure
Configure
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
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:
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
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
Administrative Credential Record
The Admin Credential Record in the PAM Machine links the admin user to the PAM Machine record in your Keeper Vault. This admin user is used for performing password rotations and authenticating connections.
User Accounts can be configured on the PAM User record. Visit this for more information on the PAM User.
Setting a Non Admin User as the Administrative Credential Record
If you prefer not to authenticate a connection using the admin credential, you can optionally designate a regular user of the resource as the admin credential.
Sharing PAM Machine Records
PAM Machine records can be shared with other Keeper users within your organization. However, the recipient must have the in place to utilize KeeperPAM features on the shared PAM records.
When sharing a PAM Machine record, the linked admin credentials will not be shared. For example, if the PAM Machine is configured with a Linux Machine, the recipient can connect to the Linux Machine on the PAM Machine record without having direct access to the linked credentials.
Learn more about
Service Management
Managing the credentials of Windows services and scheduled tasks
Overview
KeeperPAM Password Rotation is able to automatically manage the "log on" credentials for Windows services and scheduled tasks.
When rotation is performed for a specific PAM User record, the Keeper Gateway will update the credentials for all services and scheduled tasks on the associated PAM Machine, and restart the services. One PAM User record can be associated to any number of PAM Machine records, allowing you to update the services and scheduled tasks across a fleet of servers.
Prerequisites
This guide assumes the following tasks have already taken place:
are configured for your role
A Keeper Secrets Manager has been created
Your is online
Setup
Service account and scheduled task management works by associating a PAM User record with one or more PAM Machine records in the vault. This mapping tells the Keeper Gateway to reach into each machine and look up any services running as the user, updating the password and restarting the service.
Ensure that you are using a PAM Machine record to manage services and scheduled tasks on the resource. If you are using a different type of resource (Database, Directory, etc) you can create another resource which is a PAM Machine that is associated to the same PAM User.
Using Discovery
When running a , Keeper will automatically locate any services or scheduled tasks that require update when a password is rotated.
If you don't use Discovery, this can be managed directly through the Commander CLI interface using the pam action service commands.
Using the Commander CLI
Keeper Commander provides the necessary commands to associate services and scheduled tasks, such that password rotations will trigger an update and restart of the service.
Installing Commander
If you haven't set up Keeper Commander yet, please follow the .
Locate Gateway UID
Use the pam gateway list command to locate the Gateway UID which manages the machine containing the services and scheduled tasks. You'll need this for the next step.
Locate PAM Machine and PAM User UID
The PAM Machine and PAM User UIDs can be found in Commander by using the ls -l command inside a folder or by using the search command.
The UIDs can also be found in the Keeper Vault "Record Information" screen:
Services Management Commands
Use the pam action service command to instruct Keeper to update services and scheduled tasks on a particular machine, for a particular user, within a network.
Adding a Service / Task / IIS
To instruct Keeper to update and restart services and scheduled tasks on a particular machine, use the syntax below:
Removing a Service / Task / IIS
To instruct Keeper to remove the associations of services and scheduled tasks on a machine:
Listing all Mappings
To display the current mappings between Gateway, Machine and User accounts where services and tasks need to be managed, use the pam action service list command.
Triggering the service update
To perform a password rotation of a PAM User account, click on the Rotate button from the vault user interface.
To perform the rotation from Commander, run pam action rotate :
To view the status of the rotation job, check the Vault UI or run the pam action job-info command as instructed:
Troubleshooting
Service Restarts
Keeper will not start a service which is currently stopped. We will only restart any actively running services after updating the log on credential.
When troubleshooting a service credential update issue, please make sure of the following:
For a Windows server, ensure the operating system field is set to windows
Ensure that the Keeper Gateway can communicate to the PAM Machine via WinRM or SSH.
Check the Event Viewer > Windows Logs > Application events for any error messages
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 .
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
AWS RDS for Oracle
Rotating Admin/Regular AWS Oracle Database Users with Keeper
Overview
In this guide, you'll learn how to rotate passwords for AWS Oracle Database User and Admin accounts on your AWS environment using Keeper Rotation. RDS for Oracle is an AWS managed resource where the Oracle Admin Credentials are defined in the PAM Database record type and the configurations of the MySQL Users are defined in the PAM User record type.
For Amazon RDS, the AWS SDK will be used to rotate the password of Database Admin Accounts. To rotate the passwords of Regular Database Users, Keeper connects to the DB instance with the provided admin credentials and executes the necessary SQL statements to change the password.
Google Cloud
Password Rotation in the GCP Environment
Overview
In this section, you will learn how to rotate user credentials within the Google Cloud environment across various target systems and services.
secrets-manager app create "My Infrastructure"
mkdir -uf "My Infrastructure"
mkdir -sf -a "My Infrastructure/Resources"
mkdir -sf -a "My Infrastructure/Users"
secrets-manager share add --app "My Infrastructure" --secret <Resources folder UID>
secrets-manager share add --app "My Infrastructure" --secret <Users folder UID>
pam gateway new -n "My Demo Gateway" -a "My Infrastructure"
pam gateway new -n "My Demo Gateway" -a "My Infrastructure" -c b64
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.
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.
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.
The Keeper Gateway can communicate over WinRM or SSH to the target machine:
WinRM: Enabled and running on port 5986.
Verification: Run winrm get winrm/config to verify that WinRM is running. See WinRM setup page for installation help.
OR...
SSH: Enabled and running on port 22.
Verification: Run ssh [your-user]@[your-machine] -p 22 to verify that SSH is running.
Any Windows-based PAM Machine record being managed needs to have the operating system field set to windows
Ensure that you are using a PAM Machine record to manage services and scheduled tasks.
My Vault> pam gateway list
KSM Application Name (UID) Gateway Name Gateway UID Status
-------------------------- ------------ ---------------------- --------
My Application1 East Cost oVCr3n7qV8uARjwSqBQBBw ONLINE
My Application2 West Coast qSiGWa55QVaGEv3_xAO3UA ONLINE
My Application3 GovCloud 31t78gWKRQeY54l0u1sbMA ONLINE
My Application4 Tokyo 2XT9aKlYTLOyTnVlpny-dA ONLINE
My Vault> pam action service
pam command [--options]
Command Description
--------- ------------------------------------------
list List all mappings
add Add a user and machine to the mapping
remove Remove a user and machine from the mapping
pam action service add -g <Gateway_UID> -m <Machine_UID> -u <User_UID> -t service
pam action service add -g <Gateway_UID> -m <Machine_UID> -u <User_UID> -t task
pam action service add -g <Gateway_UID> -m <Machine_UID> -u <User_UID> -t iis
pam action service remove -g <Gateway_UID> -m <Machine_UID> -u <User_UID) -t service
pam action service remove -g <Gateway_UID> -m <Machine_UID> -u <User_UID) -t task
pam action service remove -g <Gateway_UID> -m <Machine_UID> -u <User_UID) -t iis
My Vault> pam action service list -g oVCr3n7qV8uARjwSqBQBBw
User Mapping
Local service user - testuser (pEFr_dJn5EAc3MT_v30DQw)
* Lureydemo.com Server (CrvdntH-f9mIcraY1InGiw) : Services, Scheduled Tasks
* Windows 2022 Server (U3fHEK2i7LIkWZAzANz2sA) : Services, Scheduled Tasks
My Vault> pam action job-info +dXjf690oGKgg== --gateway=oVCr3n7qV8uARjwSqBQBBw
Job id to check [+dXjf690oGKgg==]
Execution Details
-------------------------
Status : finished
Duration : 0:01:01.923147
Response Message : Rotation completed for record uid XXX with post-execution
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.
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
Connection Parameters
Connection-specific protocol settings which can vary based on the protocol type
See this for RDP protocol settings
We recommend specifying the Connection Port at a minimum. E.g. "3389" for RDP.
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
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
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
A Keeper Secrets Manager application has been created
A Keeper Rotation is already installed, running, and is able to communicate with your AWS Oracle Database
Your AWS environment is per our documentation
1. Set up a PAM Database Record
The PAM Database record contains the admin credentials and necessary configurations to connect to the Oracle RDS instance on AWS. Keeper Rotation will use these provided configurations to rotate passwords of regular database user accounts in the Oracle RDS instance. These provided admin credentials need to also have sufficient database permissions to successfully change the credentials of the database user accounts.
The following table lists all the required fields on the PAM Database Record:
Field
Description
Title
Keeper record title Ex: AWS Oracle Admin
Hostname or IP Address
The RDS Endpoint i.e. rdsdb.ckivswes.us-east-2.rds.amazonaws.com
Port
The RDS Port, for default ports see
i.e. 1521
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Login
Admin account username that will perform rotation
Note: Adding Provider Region and Database ID will enable managing the PAM Database Record through the SDK.
This PAM Database Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users
2. Set up PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields on the PAM Configuration Record:
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your Oracle RDS Instance
ApplicationFolder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the PAM User records, not the database resources.
AWS ID
A unique ID for this instance of AWS. This is for your reference and can be anything, but its recommended to be kept short
Ex: AWS-1
For more details on all the configurable fields in the PAM Configuration record, visit this page.
3. Set up PAM User Records
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your AWS environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields on the PAM User record:
Field
Description
Title
Keeper record title i.e. AWS DB User 1
Login
Case sensitive username of the account being rotated. If the user in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@HOST
Password
Account password is optional, rotation will set one if blank
Connect Database
Optional database that will be used when connecting to the database server.
For example: PostgreSQL requires a database and so this will default to template1
4. Configure Rotation on the PAM User records
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
KeeperPAM Record Types
Configurations for your GCP environment are defined in the PAM Configurationsection of Keeper Secrets Manager. Keeper will use the inherited service account where the Gateway is installed to authenticate with the GCP system and perform rotation.
Configurations for managed resources like Compute Engine, Cloud SQL, and Managed Microsoft AD are defined in the PAM Machine, PAM Database, and PAM Directoryrecord types. The following table shows the supported AWS managed resources with KeeperPAM and their corresponding PAM Record Type:
Google Managed Resource
Corresponding Record Type
Compute Engine VM
PAM Machine
Cloud SQL Instance
PAM Database
Managed Microsoft AD
PAM Directory
Google Workspace Principal
PAM User
Configurations for directory users, database users, or VM users are defined in the PAM Userrecord type.
Prerequisites
To successfully rotate Compute Cloud Resource User accounts or Google Workspace Principal accounts, the Keeper Gateway needs to have the necessary service account with the permissions for performing the password rotation.
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.
Records, Record Types and Resources
In Keeper, a record can be a password, file, passkey, or any number of possible record type templates. A record is always encrypted locally on the user's device with a record-level encryption key. All information held within a record is encrypted in the vault.
When working with Secrets Management and Privileged Access Management functionality, records can also represent Applications, Machines, Directories, Databases, Domain Controllers, Users and other infrastructure being managed.
Like any password record, these new record types can also be placed into private or shared folders, managed directly in the vault and controlled through policy enforcements.
Folders and Shared Folders
In the vault, records are placed into folders and shared folders. A typical and recommended setup looks something like this:
Private Folder
Shared Folder containing Resources
Shared Folder containing User accounts
The reason that we recommend splitting up Resources and User accounts is based on least privilege. In this configuration, the resources can be provisioned to a user without sharing access to the underlying credentials. The user accounts are in a separate folder and can remain private in this vault or shared to other privileged users as required.
A resource such as a Linux machine can be seen inside the resource folder below. The Administrative Credentials used for connecting to that resource are linked, but not directly embedded in the resource. This way, you can provide access to the resource without sharing the credential.
In this example, the linked Administrative Credential lives in the Users folder with separate permissions and folder privileges.
At the Shared Folder level, both human users and applications can be assigned with access rights. This allows least privilege enforcement across employees and machines.
The fastest way to understand the relationship between records, folders, applications and configurations is using the . This wizard instantly creates a sandbox environment where you can work with the different resources and vault records.
Application
A Secrets Manager Application is assigned to specific shared folders. Applications are associated to devices and Gateways for accessing the assigned records.
An Application and the associated devices and Gateways can only decrypt the records assigned to the folder. Keeper recommends implementing the principle of least privilege, ensuring applications are limited in their ability to access records from the vault.
Management of Applications is found in the Keeper Secrets Manager section of the vault. An example of an Application might be "Azure DevOps Pipeline" or "Azure AD Rotations" as seen in the screenshot below.
For more information on Applications:
Device
A Device is any endpoint that needs to access secrets associated with an Application. This can be a physical device, virtual device, or cloud-based device. Each Client device has a unique key to read and access the secrets.
A device can be initialized through the Applications section of the vault user interface.
For more information on Devices:
Gateway
The Keeper Gateway is a service that is installed on any Docker, Linux or Windows machine in order to execute password rotation, discovery, connection, tunneling or other privileged automation. The Gateway service can be installed in any remote or on-prem environment, powering a secure zero-trust connection.
Typically, a Keeper Gateway is deployed to each environment that is being managed. For example, if you are an MSP managing 500 client environments, you may deploy 500 Keeper Gateways.
The architecture of the Keeper Gateway deployments is based on your use case and can be reviewed with our implementation team.
Configuration
A PAM Configuration defines the target environment where a Keeper Gateway has been installed. This configuration supplies important secrets to the Gateway that can be used to manage the target infrastructure. For example, it can contain Azure client secrets or Tenant IDs.
The PAM Configuration data is stored as a record in the vault inside the specified "Application Folder". This way, the Gateway has the necessary permission to retrieve this information.
We recommend defining only one Configuration for each Gateway.
More information about PAM Configuration records:
PAM Resources
Inside the vault, records define the type of resources being managed. We call these "PAM Resources". Several new Record Types available in the vault are associated with a resource.
When creating a resource, you can select from various targets, such as Machine, Database, Directory, etc.
Visit the pages linked below to learn more about each PAM Resource:
PAM Record Type
Supported Assets
PAM Users
A special record type in the Keeper Vault called PAM User can be directly associated to any PAM Resource. The PAM User is used by the Keeper Gateway for establishing a connection, rotating a password, discovering accounts or running other privilege automation on a target resource.
A PAM User is linked to the PAM Resource in the "Credentials" section of the record. This linkage ensures that access to the resource does not directly allow access to the credential.
A PAM User record can be configured for on-demand and automatic rotation.
More information on PAM Users is found here:
Activating PAM Features
Now that you understand the basic structure of the vault, activating and utilizing PAM features is described in the below sections.
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
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
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 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:
PAM Database Record Type Fields
The following table lists all the configurable fields on the PAM Database Record Type:
Field
Description
Notes
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
Field
Description
Required
Below is an example of a PAM Database record with Connections and Tunnels activated.
Examples
Visit the following pages to set up:
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 on PAM Resource Record Types
When setting up Rotation in your Keeper Vault, you store the credentials of your assets involved in rotation on their corresponding . On these record types, you are able to .
The additional gateway configurations will be defined with these custom fields on the PAM Record Types. The Keeper Gateway will then adjust its behavior based on the defined configurations.
The following tables lists all the possible configurations with custom fields:
Custom Field Name
Type
Default Value
Description
Note:
The custom fields values are not case-sensitive.
Advanced Gateway Configuration with Custom Fields on PAM Configuration
When setting up Rotation in your Keeper Vault, you store essential information of your target infrastructure, settings and associated Keeper Gateway on the . On the PAM Configuration,
The additional gateway configurations will be defined with these custom fields on the PAM Configuration. 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
Adding Custom Fields on PAM Configuration
Custom Fields can only be added on the PAM Configuration with Keeper Commander
Custom Fields can be added on PAM Configuration with Keeper Commander. To add custom fields:
Log on to Keeper Commander
List all your PAM Configuration and get the UID of your PAM Configuration
Add the custom field to the PAM Configuration. The following example will add the custom field "Azure Authority FQDN" with value "login.microsoftonline.us" to the PAM Configuration:
For more information on adding custom fields with the record-update command, visit this .
The following command will allow you to view the custom field you set from step 3:
Note:
Custom fields on PAM Configurations can only be modified and viewed with Keeper Commander
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
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
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 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:
PAM Directory Record Type Fields
The following table lists all the configurable fields on the PAM Directory Record Type:
Field
Description
Notes
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
Field
Description
Required
Note: PAM User is only required to successfully configure connections and rotation, and not required for Tunnels.
Configuration Steps:
On the PAM Database record, navigate to the PAM Settings section
Select the PAM Configuration and Administrative Credential Record
To configure Keeper Connections and Keeper Tunnels settings, visit the following page:
The following screenshot is a PAM Directory Record with LDAPS rotation, RDP connections and LDAPS tunnels enabled:
Native MySQL
Rotating Local Network MySQL database accounts with Keeper Rotation
Overview
In this guide, you'll learn how to rotate Local MySQL Database User and/or Admin accounts within your local network using Keeper Rotation. For a high-level overview on the rotation process in the local network, visit this page.
Prerequisites
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your
Keeper Rotation is enabled for your
A Keeper Secrets Manager has been created
1. Set up a PAM Database Record
Keeper Rotation will use an admin credential linked from the PAM Database record to rotate credentials of other accounts in your local environment. These admin credentials need to have the sufficient permissions in order to successfully change the credentials of other accounts.
The following table lists all the required fields that needs to be filled on the PAM Database Record with your information:
Field
Description
2. Set up a PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields on the PAM Configuration Record:
Field
Description
3. Set up PAM User records
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your Local environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields on the PAM User record:
Field
Description
4. Configure Rotation on the PAM User records
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
Gateway on Linux Native
Instructions for installing Keeper Gateway on Linux with native packages
Overview
This document contains information on how to install, configure, and update your Keeper Gateway on Linux with native packages.
Prerequisites
Prior to proceeding with this document, make sure you .
For full capabilities, use Rocky Linux 9, RHEL 9 or Alma Linux 9.
If you cannot use one of these Linux flavors, please install using the
Installation
Install Command
Executing the following command will install the Keeper Gateway, and run it as a service:
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:
An alias gateway is also created in the same directory
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:
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:
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 .
If the Keeper Gateway is installed and running as a service, the gateway configuration file is stored in the following location:
If the Keeper Gateway is installed locally and not running as a service, the gateway configuration file is stored in the following location:
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:
If the Gateway is not running as a service, the log files are stored in the following location:
Verbose Logging
To add verbose debug logging, modify this file:
and add the -d flag to the "gateway start" command, e.g:
Apply changes to the service:
Tailing the Logs
Updating
Executing the following command will update the Keeper Gateway to the latest version:
Auto Update
Configure your Keeper Gateway installation to automatically check for updates, ensuring it stays up-to-date with the latest version.
Uninstalling
Executing the following command will uninstall the Keeper Gateway:
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.
The Keeper Gateway establishes outbound-only connections and does not require any inbound firewall rules. The following outbound connections must be allowed:
Destination Endpoint
Ports Needed
More Info
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:
Calculating and verifying the checksum:
Linux
PowerShell
GCP Principal User Password
Rotating Google Workspace user account passwords with Keeper
Overview
In this guide, you will learn how to rotate passwords for Google Workspace users. In Keeper, the PAM Configuration contains all of the information needed to rotate passwords. The record containing the Google Principal user accounts to be rotated are stored in the PAM User record.
Prerequisites
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your
Keeper Rotation is enabled for your
A Keeper Secrets Manager has been created
The Keeper Gateway uses Google Admin APIs to rotate the credentials defined in the PAM User records.
1. Create Shared Folder
In this folder, you’ll create records for the Google Principal accounts that you’ll rotate. You will create a PAM User record for each user that will be rotated.
Note: The target user to be rotated must be in a domain that the Google Workspace Administrator whose email is set on the PAM Configuration can manage.
Keeper Rotation uses the Google Admin API to rotate the PAM User records in your Google Workspace environment. The PAM User records need to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields on the PAM User record:
Field
Description
3. Set up PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
In the left menu of the vault, select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields on the PAM Configuration Record:
Field
Description
For more details on all the configurable fields in the PAM Configuration record, visit this .
4. Configure Rotation on the PAM User Records
Select the PAM User record(s) from Step 2, edit the record and open the "Password Rotation Settings".
Select "IAM User" as the rotation method, since this uses Google Admin APIs.
The "Rotation Settings" should use the PAM Configuration setup previously.
Select the desired schedule and password complexity.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
Azure
Password Rotation in the Azure Environment
Overview
In this section, you will learn how to rotate user credentials within the Azure network environment across various target systems. Rotation works on the devices configured and attached to the Azure Active Directory (Azure AD) which can also be your default directory.
KeeperPAM can rotate the password for Azure AD users, service accounts, local admin users, local users, managed services, databases and more.
KeeperPAM Record Types
Configurations for the Azure Active Directory are defined in the PAM Configuration section of Keeper Secrets Manager.
Configurations for the Azure AD joined devices are defined in the PAM Directory, PAM Machine, and PAM Database record types. The credentials and user accounts are defined in PAM User records. The following table shows the supported Azure AD joined devices with Keeper Rotation and their corresponding PAM Record Type:
Azure AD Joined Device
Corresponding PAM Record Type
Prerequisites for Rotation
Prior to rotating user credentials within your Azure environment, you need to make sure you have the following information and configurations in place:
All Azure AD joined devices that you want to use with Rotation need to be created and configured within your Azure Active Directory
To successfully configure and setup Rotation within your Azure Network, the following values are needed for your :
Field
Description
Make sure all the Azure services or Azure AD joined devices you plan on using for rotation have access to the Azure Active Directory.
Create a custom role to allow application to access/perform actions on various Azure resources. For more information see the document.
Setup Steps
At a high level, the following steps are needed to successfully rotate passwords on your Azure network:
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
Use Cases:
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
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:
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
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
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 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 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
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.
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
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-64 CPUs for full feature support and ease of management.
Platform
Compatibility
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, CPU and memory resources must be scaled accordingly.
Non-RBI Connections
For non-RBI connections, Keeper Gateway follows a predictable scaling model based on concurrent sessions.
General Sizing Guidelines (Non-RBI Sessions)
1 CPU core and 2 GB of memory for every 25 concurrent sessions
Non-RBI Concurrent Sessions
CPU Cores
Minimum RAM
RBI Connections
Remote Browser Isolation (RBI) sessions have significantly higher resource requirements compared to standard gateway connections.
Each RBI session launches a dedicated headless Chromium instance, which consumes substantially more memory than non-RBI sessions.
Estimated memory usage per RBI session: up to 800 MB
Memory consumption scales linearly with the number of concurrent RBI sessions
CPU requirements also increase depending on page complexity and user activity
General Sizing Guidelines (Non-RBI Sessions)
800 MB per RBI Connection
RBI Concurrent Sessions
CPU Cores
Minimum RAM
Recommendation
A minimum of 2 CPU cores and 8 GB of RAM is recommended for any deployment, even small environments.
Test Environments
For testing or sandbox environments, a minimum of 2 CPU cores, 8 GB of memory, and 10 GB of storage is required.
Production Environments
For production deployments, a minimum of 4 CPU cores and 16 GB of memory is required.
Scale CPU and memory resources based on the number of concurrent sessions, and refer to the sizing table above for guidance.
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
Click on Secrets Manager on the left side
Create a new Secrets Manager Application or select existing application
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.
Installation Methods
Based on your Operating System, refer to the corresponding guide on installing the Keeper Gateway:
Container Services:
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 .
Azure AD Users
Rotating Azure AD Admin and User passwords with Keeper
Overview
In this guide, you will learn how to rotate passwords for Azure AD users. In Keeper, the PAM Configuration contains all of the information needed to rotate passwords. The record containing the Azure AD user accounts to be rotated are stored in the PAM Userrecord.
The Keeper Gateway uses Azure APIs to rotate the credentials defined in the PAM User records.
See the for a high level overview and getting started with Azure
Prerequisites
This guide assumes the following tasks have already taken place:
are configured for your role
A Keeper Secrets Manager has been created
Your Azure environment is per our documentation
1. Set up PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for Azure.
Prior to setting up the PAM Configuration, make sure that:
A Keeper Secrets Manager has been created
A Keeper Rotation is already installed, running, and is provisioned in the Keeper Secrets Manager application you created.
We recommend installing the Keeper Gateway service in a machine within the Azure environment in order to rotate other types of targets.
In the left menu of the vault, select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the required fields that needs to be filled on the PAM Configuration Record with your information:
Field
Description
2. Set up one or more PAM User Records
Keeper Rotation uses the Azure Graph API to rotate the PAM User records in your Azure environment. The PAM User records need to be in a shared folder that is shared to the KSM application created in the pre-requisites.
The following table lists all the requiredfields that needs to be filled on the PAM User record with your information:
Field
Description
There should only be one PAM User record for each Azure AD user. Having multiple PAM User records with the same user/login will cause conflicts.
3. Configure Rotation on the PAM User Records
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select "IAM User" for the rotation method, since this uses Azure APIs.
The "Rotation Settings" should select the PAM Configuration setup previously.
Select the desired schedule and password complexity.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
Native Oracle
Rotating Local Network Oracle database accounts with Keeper Rotation
Overview
In this guide, you'll learn how to rotate Local Oracle Database User and/or Admin accounts within your local network using Keeper Rotation. For a high-level overview on the rotation process in the local network, visit this page.
Prerequisites
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your
Keeper Rotation is enabled for your
A Keeper Secrets Manager has been created
1. Set up a PAM Database Record
Keeper Rotation will use an admin credential linked to the PAM Database to rotate credentials of other accounts in your local environment. These admin credentials need to have the sufficient permissions in order to successfully change the credentials of other accounts.
The following table lists all the required fields that needs to be filled on the PAM Database record with your information:
Field
Description
2. Set up a PAM Configuration
If you already have a PAM Configuration for your Local environment, you can simply add the additional Resource Credentials required for rotating database users to the existing PAM Configuration.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields on the PAM Configuration Record:
Field
Description
3. Set up one or more PAM user records
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your Local environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields on the PAM User record:
Field
Description
4. Configure Rotation on the PAM User records
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
Native MariaDB
Rotating Local Network MariaDB database accounts with Keeper Rotation
Overview
In this guide, you'll learn how to rotate Local MariaDB User and/or Admin accounts within your local network using Keeper Rotation. For a high-level overview on the rotation process in the local network, visit this page.
Prerequisites
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your
Keeper Rotation is enabled for your
A Keeper Secrets Manager has been created
1. Set up a PAM Database Record
Keeper Rotation will use an admin credential linked to the PAM Database record to rotate credentials of other accounts in your local environment. These admin credentials need to have the sufficient permissions in order to successfully change the credentials of other accounts.
The following table lists all the required fields that needs to be filled on the PAM Database Record with your information:
Field
Description
2. Set up a PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields on the PAM Configuration Record:
Field
Description
3. Set up one or more PAM user records
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your Local environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields on the PAM User record:
Field
Description
4. Configure Rotation on PAM User records
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
IAM User Password
Rotating AWS IAM account passwords with Keeper
Overview
In this guide, you will learn how to rotate passwords for AWS IAM users. In Keeper, the PAM Configuration contains all of the information needed to rotate passwords. The record containing the AWS IAM user accounts to be rotated are stored in the PAM User record.
Prerequisites
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your
Keeper Rotation is enabled for your
A Keeper Secrets Manager has been created
The Keeper Gateway uses AWS APIs to rotate the credentials defined in the PAM User records.
1. Create Shared Folder
In this folder, you’ll create records for the AWS IAM accounts that you’ll rotate. You will create a PAM User record for each user that will be rotated.
Note: The target user to be rotated must have AWS Console access and at minimum have a temporary password set in the AWS Console before the password can be rotated.
2. Create PAM User Record(s)
Keeper Rotation uses the AWS API to rotate the PAM User records in your AWS environment. The PAM User records need to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields on the PAM User record:
Field
Description
3. Set up PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
In the left menu of the vault, select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields on the PAM Configuration Record:
Field
Description
For more details on all the configurable fields in the PAM Configuration record, visit this .
4. Configure Rotation on the PAM User Records
Select the PAM User record(s) from Step 2, edit the record and open the "Password Rotation Settings".
Select "IAM User" as the rotation method, since this uses AWS APIs.
The "Rotation Settings" should use the PAM Configuration setup previously.
Select the desired schedule and password complexity.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
Note: The user must have AWS Console access and at minimum have a temporary password set in the AWS Console before the password can be rotated.
macOS User
Rotating Local Mac User Accounts with Keeper Rotation
Overview
In this guide, you'll learn how to remotely rotate MacOS accounts via SSH using Keeper Rotation. For a high-level overview on the rotation process in the local network, visit this page.
Prerequisites
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your
Keeper Rotation is enabled for your
A Keeper Secrets Manager has been created
1. Set up a PAM Machine resource
Keeper Rotation will use the linked admin credential to rotate other accounts in your environment. This account does not need to be joined to a domain, or a full admin account, but the account needs to be able to successfully change passwords for other accounts.
PAM Directory Record Fields
Field
Description
2. Set up a PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
In the left menu of the vault, select "Secrets Manager", then select the "PAM Configurations" tab. Create a new configuration:
Field
Description
3. Set up one or more PAM user records
Keeper Rotation will use the linked credentials in the PAM Machine record to rotate the PAM User records in your environment.
PAM User Record Fields
Field
Description
4. Configure Rotation on the PAM User records
Select the PAM User record, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the "PAM Machine" credential setup previously.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
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
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
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 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:
PAM Machine Record Type Fields
The following table lists all the configurable fields on the PAM Machine Record Type:
Field
Description
Notes
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
Field
Description
Required
Below are a couple examples of PAM Machine records with Connections and Tunnels activated.
Examples
Visit the following pages to set up:
Gateway on Windows
Instructions for installing Keeper Gateway on Windows
Overview
This document contains information on how to install, configure, and update the Keeper Gateway on Windows.
Windows User
Rotating Windows User Accounts on Local Network
Overview
In this guide, you'll learn how to rotate Windows user accounts within your local network using Keeper Rotation. For a high-level overview on the rotation process in the local network, visit this .
Native MS SQL Server
Rotating Local Network Microsoft SQL Server database accounts with Keeper Rotation
Overview
In this guide, you'll learn how to rotate Local MS SQL Server Database User and/or Admin accounts within your local network using Keeper Rotation. For a high-level overview on the rotation process in the local network, visit this .
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.
Cloud SQL for MySQL
Rotating Admin/Regular AWS SQL Database Users with Keeper
Overview
In this guide, you'll learn how to rotate passwords for Google Cloud MySQL Database User and Admin accounts on your GCP environment using Keeper Rotation. Cloud SQL for MySQL is an GCP managed resource where the MySQL Admin Credentials are defined in the PAM Database record type and the configurations of the MySQL Users are defined in the PAM User record type.
To rotate the passwords of Regular Database Users, Keeper connects to the DB instance with the provided admin credentials and executes the necessary SQL statements to change the password.
Linux User
Rotating Linux User Accounts on Local Network
Overview
In this guide, you'll learn how to rotate Linux user accounts within your local network using Keeper Rotation, including both password-based and SSH Key-based credentials. For a high-level overview on the rotation process in the local network, visit this .
AWS RDS for MySQL
Rotating Admin/Regular AWS SQL Database Users with Keeper
Overview
In this guide, you'll learn how to rotate passwords for AWS MySQL Database User and Admin accounts on your AWS environment using Keeper Rotation. RDS for MySQL is an AWS managed resource where the MySQL Admin Credentials are defined in the PAM Database record type and the configurations of the MySQL Users are defined in the PAM User record type.
For Amazon RDS, the AWS SDK will be used to rotate the password of Database Admin Accounts. To rotate the passwords of Regular Database Users, Keeper connects to the DB instance with the provided admin credentials and executes the necessary SQL statements to change the password.
Native PostgreSQL
Rotating Local Network PostgreSQL database accounts with Keeper Rotation
Overview
In this guide, you'll learn how to rotate Local Postgres Database User and/or Admin accounts within your local network using Keeper Rotation. For a high-level overview on the rotation process in the local network, visit this .
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.
Cloud SQL for PostgreSQL
Rotating Admin/Regular AWS PostgreSQL Database Users with Keeper
Overview
In this guide, you'll learn how to rotate passwords for GCP PostgreSQL Database User and Admin accounts on your Google Cloud environment using Keeper Rotation. Cloud SQL for PostgreSQL is a GCP managed resource where the PostgreSQL Admin Credentials are defined in the PAM Database record type and the configurations of the PostgreSQL Users are defined in the PAM User record type.
To rotate the passwords of Regular Database Users, Keeper connects to the DB instance with the provided admin credentials and executes the necessary SQL statements to change the password.
AWS RDS for MariaDB
Rotating Admin/Regular AWS MariaDB Database Users with Keeper
Overview
In this guide, you'll learn how to rotate passwords for AWS MariaDB Database User and Admin accounts on your AWS environment using Keeper Rotation. RDS for MariaDB is an AWS managed resource where the MariaDB Admin Credentials are defined in the PAM Database record type and the configurations of the MySQL Users are defined in the PAM User record type.
For Amazon RDS, the AWS SDK will be used to rotate the password of Database Admin Accounts. To rotate the passwords of Regular Database Users, Keeper connects to the DB instance with the provided admin credentials and executes the necessary SQL statements to change the password.
Rotation Use Cases
Step by step guides for performing rotation on any target system
The setup and configuration of Keeper Rotation is defined by the use case. Keeper supports any cloud or on-prem environment.
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.
PAM Directory with Connection, Rotation and Tunnel Enabled
List of failover IPs for the directory, used for Discovery
A Keeper Rotation gateway is already installed, running, and is able to communicate to your MySQL database
mysql
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Title
Keeper record title Ex: dbadmin
Hostname or IP Address
Server address - doesn't need to be publicly routable
Port
For default ports, see port mapping
Ex: mysql=3306
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Administrative Credentials
Linked PAM User record that contains the username and password of the Admin account which will perform the rotation.
Title
Configuration name, example: MySQL LAN Configuration
Environment
Select: Local Network
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your MySQL database
Application Folder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the PAM User records, not the database resources.
Record Type
PAM User
Title
Keeper record title
Login
Case sensitive username of the db account being rotated. Example: msmith
Password
Account password is optional, rotation will set one if blank
Select the Gateway that is configured on the Keeper Secrets Manager application.
ApplicationFolder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the PAM User records.
GCP ID
A unique ID for this instance of Google Cloud. This is only for your reference and can be anything, but its recommended to be kept short
Ex: GCP-DepartmentName
The unique Application (client) ID assigned to your app by Azure AD when the application was registered
Client Secret
The client credentials secret for the Azure application. It’s random looking text.
Subscription ID
The UUID that identifies your subscription (i.e. Pay-As-You-GO) to use Azure services.
Tenant ID
The UUID of the Azure Active Directory
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Title
Configuration name, example: Azure AD Configuration
Environment
Select: Azure
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your Active Directory server from the pre-requisites
Application Folder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the admin accounts.
Azure ID
A unique ID for this instance of Azure. This is for your reference and can be anything, but its recommended to be kept short
Ex: Azure-1
Title
Keeper record title i.e. Azure User1
Login
Case sensitive username of the account being rotated. The username has to be in one of the following formats:
domain\usernameusername@domain
Password
Providing a password is optional. Performing a rotation will set one if this field is left blank.
A Keeper Rotation gateway is already installed, running, and is able to communicate to your Oracle database
oracle
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Title
Keeper record title Ex: dbadmin
Hostname or IP Address
Server address - doesn't need to be publicly routable
Port
For default ports, see port mapping
Ex: oracle=1521
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Administrative Credentials
Linked PAM User record that contains the username and password of the Admin account which will perform the rotation.
Title
Configuration name, example: Oracle LAN Configuration
Environment
Select: Local Network
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your Oracle database
Application Folder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the PAM User records, not the database resources.
Record Type
PAM User
Title
Keeper record title
Login
Case sensitive username of the db account being rotated. Example: msmith
Password
Account password is optional, rotation will set one if blank
A Keeper Rotation gateway is already installed, running, and is able to communicate to your MariaDB database
maridb or maridb-flexible
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Title
Keeper record title Ex: dbadmin
Hostname or IP Address
Server address - doesn't need to be publicly routable
Port
For default ports, see port mapping
Ex: mariadb=3306
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Administrative Credentials
Linked PAM User record that contains the username and password of the Admin account which will perform the rotation.
Title
Configuration name, example: MariaDB LAN Configuration
Environment
Select: Local Network
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your MariaDB database
Application Folder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the PAM User records, not the database resources.
Record Type
PAM User
Title
Keeper record title
Login
Case sensitive username of the db account being rotated. Example: msmith
Password
Account password is optional, rotation will set one if blank
A Keeper Rotation gateway is already installed, running, and is able to communicate via SSH to your MacOS device.
Linked PAM User record that contains the username and password (or SSH Key) of the Admin account which will perform the rotation.
Operating System
For Mac OS rotation, use: MacOS
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Record Type
PAM Machine
Title
My macOS User
Hostname or IP Address
IP address or hostname of the directory macOS device. Use localhost if the gateway is installed on the device. Examples: 10.10.10.10, MarysMacBook, localhost
Port
SSH port, typically: 22 - SSH is required for rotation.
Use SSL
Must be enabled
Title
Configuration name, example: MAC Rotation
Environment
Select: Local Network
Gateway
Select the Gateway that has SSH access to your MacOS devices
Application Folder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the PAM User records, not the machine resources.
Default Rotation Schedule
Optional
Record Type
PAM User
Title
Keeper record title
Login
Case sensitive username of the account being rotated. Example: msmith
Password
Account password is optional, rotation will set one if blank
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)
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.
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
Azure Authority FQDN
Text
Azure SDK Default
Overrides the Azure Active Directory authority endpoint used for authentication.
If not specified, the default authority configured in the Azure SDK is used (e.g., login.microsoftonline.com).
This field is only applicable to PAM configurations targeting Azure environments, including Azure Government.
Example: login.microsoftonline.us
Azure Graph Endpoint
Text
Azure SDK Default
Overrides the Microsoft Graph API base URL used by Azure integrations.
If not specified, the default Graph endpoint configured in the Azure SDK is used (e.g., https://graph.microsoft.com/v1.0).
This field is only applicable to PAM configurations targeting Azure environments, including Azure Government
Example: graph.microsoft.us/v1.0
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:
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 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:
If the Keeper Gateway is installed locally and not running as a service, the gateway configuration file is stored in the following location:
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:
If the gateway is not running as a service, the gateway log files are stored in the following location:
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
Updating
To update the Keeper Gateway, stop the service, install the latest version and then start the service.
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:
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:
To generate a log file during the installation process, use the following option and specify the desired log file path:
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:
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:
Uninstalling
To uninstall the service:
Uninstall Keeper Gateway from "Add and remove programs"
If desired, delete the private configuration .json file
The Keeper Gateway establishes outbound-only connections and does not require any inbound firewall rules. The following outbound connections must be allowed:
Destination Endpoint
Ports Needed
More Info
Keeper Cloudkeepersecurity.[x]
Endpoints:
US: .com
EU: .eu
AU: .com.au
TLS Port 443
Communicates with Keeper Cloud to access target infrastructure via native protocols (e.g., SSH, RDP)
Keeper Routerconnect.keepersecurity.[x]
Endpoints:
US: .com
EU: .eu
AU: .com.au
TLS Port 443
Communicates with Keeper Router to establish secure, real-time WebSocket connections
Keeper Stun/Turn Service
krelay.keepersecurity.[x]
Endpoints:
US: .com
EU: .eu
AU: .com.au
TCP and UDP opened on Port 3478
Outbound access to TCP and UDP ports 49152 through 65535
Facilitates secure and encrypted WebRTC 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:
A Keeper Secrets Manager application has been created
A Keeper Rotation is already installed and showing online
The Keeper Gateway can communicate over WinRM or SSH to the target machine:
WinRM: Enabled and running on port 5986.
Verification: Run winrm get winrm/config to verify that WinRM is running. See for installation help.
OR...
1. Set up a PAM Machine Record
Keeper Rotation will use an admin credential to rotate credentials of other accounts in your local environment. These admin credentials need to have the sufficient permissions in order to successfully change the credentials of other accounts.
In this guide, we will store the admin credentials in a PAM Machine Record.
The following table lists all the required fields that needs to be filled on the PAM Machine Record with your information:
Field
Description
Title
Name of the Record
ex: "Local Windows Admin"
Hostname or IP Address
Machine hostname or IP as accessed by the Gateway (internal) or "localhost"
Port
22 for SSH, 5985 (HTTP) or 5986 (HTTPS) for WinRM
Administrative Credentials
Linked PAM User record that contains the username and password (or SSH Key) of the Admin account which will perform the rotation.
The linked PAM User record with the admin credential needs to be in a shared folder that is accessible to the Keeper Gateway.
2. Set up a PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields on the PAM Configuration Record:
Field
Description
Title
Configuration name, example: Windows LAN Configuration
Environment
Select: Local Network
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has SSH access to your Windows devices
Application Folder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the PAM User records, not the machine resources.
3. Set up one or more PAM User records
Keeper Rotation will use the credentials in the PAM Machine record to rotate the PAM User records on your Local environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields on the PAM User record:
Field
Description
Record Type
PAM User
Title
Keeper record title
Login
Case sensitive username of the account being rotated. Example: msmith
Password
Account password is optional, rotation will set one if blank
Supported Username Formats
Note that Keeper will attempt to login to the remote system using the username exactly as supplied. If authentication fails, Keeper will then attempt to use the below variations:
Domain FQDN with backslash format: company.com\admin
4. Configure Rotation on the PAM User records
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Machine credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
Service Management
Keeper can automatically update the Windows service account "log on as" credentials for any Windows services running as the PAM User, and restart the service. Keeper will also update the credential of any scheduled task running as that user on the target machine.
To learn more and set up this capability, see the Service Management page.
A Keeper Secrets Manager application has been created
A Keeper Rotation is already installed, running, and is able to communicate to your MySQL database
If the Gateway is installed on a Linux or macOS server, install the
1. Set up a PAM Database Record
Keeper Rotation will use an admin credential linked to the PAM Database to rotate credentials of other accounts in your local environment. These admin credentials need to have the sufficient permissions in order to successfully change the credentials of other accounts.
The following table lists all the required fields that needs to be filled on the PAM Database record with your information:
Field
Description
Title
Keeper record title Ex: dbadmin
Hostname or IP Address
Server address - doesn't need to be publicly routable
Port
For default ports, see
Ex: mssql=1433
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Administrative Credentials
Linked PAM User record that contains the username and password of the Admin account which will perform the rotation.
2. Set up a PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields on the PAM Configuration Record:
Field
Description
Title
Configuration name, example: MSSQL LAN Configuration
Environment
Select: Local Network
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your MS SQL Server database
Application Folder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the PAM User records, not the database resources.
3. Set up one or more PAM User records
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your Local environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields on the PAM User record:
Field
Description
Record Type
PAM User
Title
Keeper record title
Login
Case sensitive username of the db account being rotated. Example: msmith
Password
Account password is optional, rotation will set one if blank
Connect Database
Optional database that will be used when connecting to the database server.
For example, MS SQL server requires a database and so this will default to master.
4. Configure Rotation on the PAM User records
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
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.
Windows Automatic Updates
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.
Prerequisites
This guide assumes the following tasks have already taken place:
A Keeper Secrets Manager application has been created
A Keeper Rotation is already installed, running, and is able to communicate with your GCP MySQL Database
Your GCP environment is per our documentation
1. Set up PAM Database Records
The PAM Database record contains the admin credentials and necessary configurations to connect to the MySQL instance on Google Cloud SQL. Keeper Rotation will use these provided configurations to rotate passwords of regular database user accounts in the MySQL Cloud SQL instance. These provided admin credentials need to also have sufficient database permissions to successfully change the credentials of the database user accounts.
The following table lists all the required fields on the PAM Database Record:
Field
Description
Title
Keeper record title Ex: GCP MySQL Admin
Hostname or IP Address
The Cloud SQL Endpoint
Port
The MySQL Port, for default ports see
i.e. 3306
Use SSL
Must be checked, performs SSL verification before connecting
Login
Admin account username that will perform rotation
This PAM Database Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users
2. Set up PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
In the left menu of the vault, select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields on the PAM Configuration Record:
Select the Gateway that is configured on the Keeper Secrets Manager application.
ApplicationFolder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the PAM User records.
GCP ID
A unique ID for this instance of Google Cloud. This is only for your reference and can be anything, but its recommended to be kept short
Ex: GCP-DepartmentName
For more details on all the configurable fields in the PAM Configuration record, visit this page.
3. Set up PAM User Records
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your Google Cloud environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields on the PAM User record:
Field
Description
Title
Keeper record title i.e. GCP DB User 1
Login
Case sensitive username of the account being rotated. If the user in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@HOST
Password
Account password is optional, rotation will set one if blank
4. Configure Rotation on the PAM User records
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
Prerequisites
This guide assumes the following tasks have already taken place:
A Keeper Secrets Manager application has been created
A Keeper Rotation is already installed, running, and is able to communicate via to your Linux Machine(s)
1. Set up a PAM Machine Record
Keeper Rotation will use an admin credential to rotate credentials of other accounts in your local environment. These admin credentials need to have the sufficient permissions in order to successfully change the credentials of other accounts.
In this guide, we will store the admin credentials in a PAM Machine Record.
The following table lists all the required fields that needs to be filled on the PAM Machine Record with your information:
Field
Description
Title
Name of the Record
ex: "Local Linux Admin"
Hostname or IP Address
Machine hostname or IP as accessed by the Gateway (internal) or "localhost"
Port
22 for SSH
Administrative Credentials
Linked PAM User record that contains the username and password (or SSH Key) of the Admin account which will perform the rotation.
The linked PAM User record with the admin credential needs to be in a shared folder that is accessible to the Keeper Gateway.
2. Set up a PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields on the PAM Configuration Record:
Field
Description
Title
Configuration name, example: Linux LAN Configuration
Environment
Select: Local Network
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has SSH access to your Linux devices
Application Folder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the PAM User records, not the machine resources.
3. Set up one or more PAM User records
Keeper Rotation will use the credentials in the PAM Machine record to rotate the PAM User records on your Local environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields on the PAM User record:
Field
Description
Record Type
PAM User
Title
Keeper record title
Login
Case sensitive username of the account being rotated. Example: msmith
Password
Account password is optional, rotation will set one if blank
Private PEM Key
SSH private key. This is only required if you are planning to rotate the PEM key instead of rotating the password.
4. Configure Rotation on the PAM User records
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Machine credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
SSH Key Rotation Notes
When rotating the private PEM Key credential on a target machine or user, Keeper will update the authorized_keys file on the machine with the new public key. The first time that a rotation occurs, the old public key is left intact in order to prevent system lockout. The second public key added to the file contains a comment that serves as an identifier for future rotations. For example:
By default, Keeper will not remove other keys from the .ssh/authorized_keys file since some providers will place in their own keys in order to control the virtual machine (ie Google Cloud Provider).
If the first rotation is successful, you can optionally delete the old public key entry in the authorized_keys file. On subsequent rotations, Keeper will update the line which contains the "keeper-security-xxx" comment.
Rotation will also create backup of the prior .ssh/authorized_keys inside of the .ssh directory.
For private key rotation, the new private key will be same algorithm and key size (bits) as the current private key. For example, if the current private key is ecdsa-sha2-nistp256 the new private key will be ecdsa-sha2-nistp256. This can be overridden by adding a custom text field, with the label Private Key Type , and setting the value to one support algorithms:
ssh-rsa - 4096 bits
ecdsa-sha2-nistp256 - ECDSA, 256 bits
ecdsa-sha2-nistp384 - ECDSA, 384 bits
ecdsa-sha2-nistp521 - ECDSA, 521 bits
ssh-ed2551
.This custom field can also be used if the current private key's algorithm cannot be detected.
To prevent private key rotation, a custom text field can be added to the PAM User record with the label Private Key Rotate. If the value of the field is TRUE, or the field doesn't exists, the private key will be rotated if it exists. If the value is FALSE, the private key will not be rotated.
For Linux user rotations, password-encrypted PEM files are not currently supported.
Administrative Credential - SSH key only accounts
When configuring a PAM User with only a private PEM key and no password as the admin credential for a machine resource, this user will execute all administrative operations such as password rotation. In this configuration, the admin account must be able to perform sudo operations without being prompted for a password.
If a password is required to execute sudo commands, rotations for non-admin credentials on that resource will fail—since the admin credential does not include a password. To ensure successful rotation, configure the PEM key only admin account to run sudo commands without a password prompt.
A Keeper Secrets Manager application has been created
A Keeper Rotation is already installed, running, and is able to communicate with your AWS MySQL Database
Your AWS environment is per our documentation
1. Set up PAM Database Records
The PAM Database record contains the admin credentials and necessary configurations to connect to the MySQL RDS instance on AWS. Keeper Rotation will use these provided configurations to rotate passwords of regular database user accounts in the MySQL RDS instance. These provided admin credentials need to also have sufficient database permissions to successfully change the credentials of the database user accounts.
The following table lists all the required fields on the PAM Database Record:
Field
Description
Title
Keeper record title Ex: AWS MySQL Admin
Hostname or IP Address
The RDS Endpoint i.e. rdsdb.ckivswes.us-east-2.rds.amazonaws.com
Port
The RDS Port, for default ports see
i.e. 3306
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Login
Admin account username that will perform rotation
Note: Adding Provider Region and Database ID will enable managing the PAM Database Record through the SDK.
This PAM Database Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users
2. Set up PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields on the PAM Configuration Record:
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your MySQL RDS Instance
ApplicationFolder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the admin accounts, not the databases.
AWS ID
A unique ID for this instance of AWS. This is for your reference and can be anything, but its recommended to be kept short
Ex: AWS-1
For more details on all the configurable fields in the PAM Configuration record, visit this page.
3. Set up PAM User Records
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your AWS environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields on the PAM User record:
Field
Description
Title
Keeper record title i.e. AWS DB User 1
Login
Case sensitive username of the account being rotated. If the user in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@HOST
Password
Account password is optional, rotation will set one if blank
4. Configure Rotation on the PAM User records
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
Prerequisites
This guide assumes the following tasks have already taken place:
A Keeper Secrets Manager application has been created
A Keeper Rotation is already installed, running, and is able to communicate to your Postgres database
1. Set up a PAM Database Record
Keeper Rotation will use an admin credential linked to the PAM Database to rotate credentials of other accounts in your local environment. These admin credentials need to have the sufficient permissions in order to successfully change the credentials of other accounts.
The following table lists all the required fields that needs to be filled on the PAM Database Record with your information:
Field
Description
Title
Keeper record title Ex: dbadmin
Hostname or IP Address
Server address - doesn't need to be publicly routable
Port
For default ports, see
Ex: postgresql=5432
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Administrative Credentials
Linked PAM User record that contains the username and password of the Admin account which will perform the rotation.
2. Set up a PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields on the PAM Configuration Record:
Field
Description
Title
Configuration name, example: Postgresql LAN Configuration
Environment
Select: Local Network
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your PostgreSQL database
Application Folder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the PAM User records, not the database resources.
3. Set up one or more PAM user records
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your Local environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields on the PAM User record:
Field
Description
Record Type
PAM User
Title
Keeper record title
Login
Case sensitive username of the db account being rotated. Example: msmith
Password
Account password is optional, rotation will set one if blank
Connect Database
Optional database that will be used when connecting to the database server.
For example: PostgreSQL requires a database and so this will default to template1.
4. Configure Rotation on the PAM User records
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit rights to a PAM User record has the ability to setup rotation for that 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)
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 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
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.
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
Prerequisites
This guide assumes the following tasks have already taken place:
A Keeper Secrets Manager application has been created
A Keeper Rotation is already installed, running, and is able to communicate with your GCP PostgreSQL Database
Your GCP environment is per our documentation
1. Set up a PAM Database Record
The PAM Database record contains the admin credentials and necessary configurations to connect to the PostgreSQL Cloud SQL instance on GCP. Keeper Rotation will use these provided configurations to rotate passwords of regular database user accounts in the PostgreSQL Cloud SQL instance. These provided admin credentials need to also have sufficient database permissions to successfully change the credentials of the database user accounts.
The following table lists all the required fields on the PAM Database Record:
Field
Description
Title
Keeper record title Ex: GCP PostgreSQL Admin
Hostname or IP Address
The RDS Endpoint
Port
The PostgreSQL Port, for default ports see
i.e. 5432
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Login
Admin account username that will perform rotation
This PAM Database Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users
2. Set up PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
In the left menu of the vault, select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields on the PAM Configuration Record:
Select the Gateway that is configured on the Keeper Secrets Manager application.
ApplicationFolder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the PAM User records.
GCP ID
A unique ID for this instance of Google Cloud. This is only for your reference and can be anything, but its recommended to be kept short
Ex: GCP-DepartmentName
For more details on all the configurable fields in the PAM Configuration record, visit this page.
3. Set up PAM User Records
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your GCP environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields on the PAM User record:
Field
Description
Title
Keeper record title i.e. GCP DB User 1
Login
Case sensitive username of the account being rotated. If the user in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@HOST
Password
Account password is optional, rotation will set one if blank
Connect Database
Optional database that will be used when connecting to the database server.
For example: PostgreSQL requires a database and so this will default to template1
4. Configure Rotation on the PAM User records
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
Prerequisites
This guide assumes the following tasks have already taken place:
A Keeper Secrets Manager application has been created
A Keeper Rotation is already installed, running, and is able to communicate with your AWS MariaDB Database
Your AWS environment is per our documentation
1. Set up PAM Database Record
The PAM Database record contains the admin credentials and necessary configurations to connect to the MariaDB RDS instance on AWS. Keeper Rotation will use these provided configurations to rotate passwords of regular database user accounts in the MariaDB RDS instance. These provided admin credentials need to also have sufficient database permissions to successfully change the credentials of the database user accounts.
The following table lists all the required fields on the PAM Database Record:
Field
Description
Title
Keeper record title Ex: AWS MariaDB Admin
Hostname or IP Address
The RDS Endpoint i.e. rdsdb.ckivswes.us-east-2.rds.amazonaws.com
Port
The RDS Port, for default ports see
i.e. 3306
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Login
Admin account username that will perform rotation
Note: Adding Provider Region and Database ID will enable managing the PAM Database Record through the SDK.
This PAM Database Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users
2. Set up PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields on the PAM Configuration Record:
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your MariaDB RDS Instance
ApplicationFolder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the PAM User records, not the database resources.
AWS ID
A unique ID for this instance of AWS. This is for your reference and can be anything, but its recommended to be kept short
Ex: AWS-1
For more details on all the configurable fields in the PAM Configuration record, visit this page.
3. Set up PAM User Records
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your AWS environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields on the PAM User record:
Field
Description
Title
Keeper record title i.e. AWS DB User 1
Login
Case sensitive username of the account being rotated. If the user in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@HOST
Password
Account password is optional, rotation will set one if blank
4. Configure Rotation on the PAM User records
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit rights to a PAM User record has the ability to setup rotation for that 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)
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 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
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.
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
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.
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 .
Next, click on the Add a certification or secret for Client credentials. On the next page, click on New client secret, give the client secret a Description, and select a desired Expires date, and click Add.
The page will refresh showing the secret Value. Copy the Value (not Secret ID) into the Keeper PAM Configuration "Client Secret" field. Save this value for later.
At this point, all the required the PAM Configuration fields should be filled in. You also have an Azure application that cannot do anything yet.
Assign Roles and Administrators
In order for the Azure tenant service principal/application to rotate Azure Active Directory users or Azure Active Directory Domain Service users, the application must be a assigned to an Administrative role.
From the Azure portal go to Home > Azure Active Directory > Roles and administrators, and click on the Administrative role to use (such as Privileged Authentication Administrator). The correct role depends on what privileges are needed for your use case. Custom roles can be used.
Global Administrator - It is not recommended to use a Global Administrator on a service principal. However, it will allow both administrator and user passwords to be rotated.
- Can change the password for any user, including a Global Administrator user.
- 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 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
Click Save.
When done, click Review + create, and click Create.
Once the role is created, it needs to be assigned to the Application (Service Principle). Click View in the Details column.
A panel will appear on the right side of the screen. Click Assignments, and then Add assignment.
Enter in the new role's name in the search bar on the Role tab, then double click it to select it. Move to the Members tab. Click Select members. In the panel that opens, enter the name of the Azure application, select the current application, and click Select.
Go to the Review + assign tab click Review + assign.
At this point, you have created the necessary roles and applications within your Azure environment.
PAM Features
The "PAM Features Allowed" and "Session Recording Types Allowed" sections in the PAM Configuration allow owners to enable or disable KeeperPAM features for resources managed through the PAM configuration:
Field
Description
Configuring PAM Features on PAM Record Types
After creating the PAM configuration, visit the following pages to:
Configure
Configure
Configure
Override Default Azure SDK Endpoints
Certain Azure environments, such as Azure Government or other sovereign clouds, use different authentication and Microsoft Graph endpoints than Azure commercial (azure.com). The default Azure SDK endpoints can be configured via custom fields on the KeeperPAM configuration record, enabling password rotation to function correctly in non-commercial Azure environments. For more information on configuring these custom fields, visit the following .
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)
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
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
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
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
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
Security Benefits:
Ensures credentials are never re-used for future sessions
Protects against credential theft during access periods
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
Configuration Options:
Required approvers based on resource sensitivity
Approval timeouts and escalations
Working hours restrictions
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
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 .
Cloud SQL for SQL Server
Rotating Admin/Regular AWS SQL Server Database Users with Keeper
Overview
In this guide, you'll learn how to rotate passwords for Google Cloud SQL Server Database User and Admin accounts on your Google Cloud environment using Keeper Rotation. Cloud SQL for SQL Server is an GCP managed resource where the SQL Server Admin Credentials are defined in the PAM Database record type and the configurations of the SQL Server Users are defined in the PAM User record type.
To rotate the passwords of Regular Database Users, Keeper connects to the DB instance with the provided admin credentials and executes the necessary SQL statements to change the password.
Prerequisites
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your
Keeper Rotation is enabled for your
A Keeper Secrets Manager has been created
1. Set up a PAM Database Record
The PAM Database record contains the admin credentials and necessary configurations to connect to the SQL Server Cloud SQL instance on GCP. Keeper Rotation will use these provided configurations to rotate passwords of regular database user accounts in the SQL Server Cloud SQL instance. These provided admin credentials need to also have sufficient database permissions to successfully change the credentials of the database user accounts.
The following table lists all the required fields on the PAM Database Record:
Field
Description
This PAM Database Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users
2. Set up PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
In the left menu of the vault, select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields on the PAM Configuration Record:
Field
Description
For more details on all the configurable fields in the PAM Configuration record, visit this .
3. Set up PAM User Records
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your GCP environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields on the PAM User record:
Field
Description
4. Configure Rotation on the PAM User records
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
Gateway on Azure Container App
Azure Container Apps (ACA) provides a serverless, managed platform for the Keeper Gateway, offering native High Availability (HA) and built-in secret encryption.
Overview
This document contains information on how to install, configure, and update your Keeper Gateway on an Azure Container App. The Keeper Gateway container is built upon the base image of Rocky Linux 9 and it is hosted in DockerHub.
Prerequisites
Azure Environment Requirements
An active Azure Subscription.
Azure CLI with the containerapp extension.
A Gateway Configuration string from the Keeper Vault.
Docker Hub Authentication
To avoid anonymous pull rate limits in Azure (which often result in 429 Too Many Requests ), you must have:
Docker Hub Account: A registered account at .
Personal Access Token: A Token generated via Account Settings > Security with Read Only permissions
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
Environment Setup
The Container App Environment is the secure boundary for your Gateways.
Secrets Management Options
Choose one of the following methods to manage your GATEWAY_CONFIG.
Option A: Internal Managed Secrets
Option B: Azure Key Vault
Store Secret: Store your config in Key Vault
Deploy with Identity: Create the app with a system-assigned identity.
Grant Access: Give the app permission to read the secret.
Reference Secret: Link the Key Vault secret to the app.
Assign the secret to the registry
Enable Shared Memory
The Keeper Gateway requires expanded shared memory (/dev/shm) for session recording. This must be applied via a YAML update after the initial creation.
Export Configuration
az containerapp show -n <APP_NAME> -g <RESOURCE_GROUP> -o yaml > keeper-app.yaml
Edit the YAML
Locate the template section and add the volumes and volumeMounts blocks.
Apply the Update
az containerapp update -n <APP_NAME> -g <RESOURCE_GROUP> --yaml keeper-app.yaml
Operational Commands
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 Endpoint
Ports Needed
More Info
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.
Managed Microsoft AD User
Rotating Google Cloud Managed Microsoft AD Service accounts with Keeper
Overview
In this guide, you will learn how to rotate User Accounts of a Google Cloud Managed Microsoft AD service using Keeper Rotation. The Active Directory Service is an AWS managed resource where the Directory Service admin credentials are linked to the PAM Directory record type and the configurations of the AD Users are defined in the PAM User record type.
User Account passwords will be rotated using LDAP and, in order to successfully rotate, server-side LDAPS must be configured and the Directory Admin, defined in the PAM Directory record type, must be using a SSL Connection.
Prerequisites
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your
Keeper Rotation is enabled for your
A Keeper Secrets Manager has been created
1. Set up a PAM Directory Record
Keeper Rotation will use the linked admin credentials of your AWS Managed Directory Service to rotate passwords of Domain Service's directory accounts. These admin credentials can also be used to rotate the passwords of the Directory admin.
The following table lists all the required fields on the PAM Directory Record:
Field
Description
This PAM Directory Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users.
2. Set up PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
In the left menu of the vault, select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields on the PAM Configuration Record:
Field
Description
For more details on all the configurable fields in the PAM Configuration record, visit this .
3. Set up one or more PAM User Records
Keeper Rotation will use the credentials in the PAM Directory record to rotate the PAM User records on your GCP environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields on the PAM User record:
Field
Description
4. Configure Rotation on the PAM User records
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Directory credential setup from Step 1.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
Troubleshooting
Getting the Distinguished Names of GCP Managed Directory Service Users
The following windows command can be used to get the distinguished name of the Directory user:
If the command does not exist, you need to import the appropriate module with:
Native MongoDB
Rotating Local Network MongoDB database accounts with Keeper Rotation
Overview
In this guide, you'll learn how to rotate Local MongoDB User and/or Admin accounts within your local network using Keeper Rotation. For a high-level overview on the rotation process in the local network, visit this page.
Prerequisites
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your
Keeper Rotation is enabled for your
A Keeper Secrets Manager has been created
1. Set up a PAM Database Record
Keeper Rotation will use an admin credential linked to the PAM Database to rotate credentials of other accounts in your local environment. These admin credentials need to have the sufficient permissions in order to successfully change the credentials of other accounts.
The following table lists all the required fields that needs to be filled on the PAM Database Record with your information:
Field
Description
2. Set up a PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields on the PAM Configuration Record:
Field
Description
3. Set up one or more PAM User records
Keeper Rotation will use the credentials linked from the PAM Database record to rotate the PAM User records on your local environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields on the PAM User record:
Field
Description
4. Configure Rotation on the PAM User records
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
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 linked from other resources.
PAM Record Type
Supported Account Types
Azure VM User Accounts
Rotating local and remote user accounts on Azure Virtual Machines with Keeper
Overview
In this guide, you'll learn how to rotate Azure Virtual Machine local and remote user accounts within the Azure environment using KeeperPAM.
Azure SQL
Rotating Admin/Regular Azure SQL Database Users with Keeper
Overview
In this guide, you'll learn how to rotate passwords for Azure SQL Database Users and Admin accounts on your Azure environment using Keeper Rotation. Azure SQL is an Azure managed resource where the SQL Admin Credentials are defined in the PAM Database record type and the configurations of the SQL Users are defined in the PAM User record type.
For Azure Managed SQL database, the Azure SDK will be used to rotate the password of Database Admin Accounts. To rotate the passwords of Regular Database Users, Keeper connects to the DB instance with the linked admin credentials and executes the necessary SQL statements to change the password.
Azure PostgreSQL - Single or Flexible Database
Rotating Admin/Regular Azure PostgreSQL Single or Flexible Database Users with Keeper
Overview
In this guide, you'll learn how to rotate passwords for Azure PostgreSQL Database Users and Admin accounts on your Azure environment using KeeperPAM. Azure PostgreSQL is an Azure managed resource where the PostgreSQL Admin Credentials are defined in the record type and the configurations of the PostgreSQL Users are defined in the record type.
For Azure Managed PostgreSQL database, the Azure SDK will be used to rotate the password of Database Admin Accounts. To rotate the passwords of Regular Database Users, Keeper connects to the DB instance with the provided admin credentials and executes the necessary SQL statements to change the password.
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:
AWS RDS for PostgreSQL
Rotating Admin/Regular AWS PostgreSQL Database Users with Keeper
Overview
In this guide, you'll learn how to rotate passwords for AWS PostgreSQL Database User and Admin accounts on your AWS environment using Keeper Rotation. RDS for PostgreSQL is an AWS managed resource where the PostgreSQL Admin Credentials are defined in the PAM Database record type and the configurations of the PostgreSQL Users are defined in the PAM User record type.
For Amazon RDS, the AWS SDK will be used to rotate the password of Database Admin Accounts. To rotate the passwords of Regular Database Users, Keeper connects to the DB instance with the provided admin credentials and executes the necessary SQL statements to change the password.
Managed Microsoft AD User
Rotating AWS Managed Microsoft AD Service accounts with Keeper
Overview
In this guide, you will learn how to rotate Admin and User Accounts of an AWS Managed Microsoft AD service using Keeper Rotation. The Active Directory Service is an AWS managed resource where the Directory Service admin credentials are linked to the PAM Directory record type and the configurations of the AD Users are defined in the PAM User record type.
For Amazon Managed Active Directory Services, the AWS SDK will be used to rotate the password of Directory Admins. User Account passwords will be rotated using LDAP and, in order to successfully rotate, server-side LDAPS must be configured and the Directory Admin, defined in the
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.
Azure MariaDB Database
Rotating Admin/Regular Azure MariaDB Database Users with Keeper
Overview
In this guide, you'll learn how to rotate passwords for Azure MariaDB Users and Admin accounts on your Azure environment using KeeperPAM. Azure MariaDB is an Azure managed resource where the MariaDB Admin Credentials are defined in the record type and the configurations of the MariaDB Users are defined in the record type.
For Azure Managed MariaDB database, the Azure SDK will be used to rotate the password of Database Admin Accounts. To rotate the passwords of Regular Database Users, Keeper connects to the DB instance with the provided admin credentials and executes the necessary SQL statements to change the password.
AWS RDS for SQL Server
Rotating Admin/Regular AWS SQL Server Database Users with Keeper
Overview
In this guide, you'll learn how to rotate passwords for AWS SQL Server Database User and Admin accounts on your AWS environment using Keeper Rotation. RDS for SQL Server is an AWS managed resource where the SQL Server Admin Credentials are defined in the PAM Database record type and the configurations of the SQL Server Users are defined in the PAM User record type.
For Amazon RDS, the AWS SDK will be used to rotate the password of Database Admin Accounts. To rotate the passwords of Regular Database Users, Keeper connects to the DB instance with the provided admin credentials and executes the necessary SQL statements to change the password.
#!/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
Optional database that will be used when connecting to the database server.
For example, MS SQL server requires a database and so this will default to master.
Optional database that will be used when connecting to the database server.
For example, PostgreSQL requires a database and so this will default to template1.
Optional database that will be used when connecting to the database server.
For example, PostgreSQL requires a database and so this will default to template1.
Database ID
The AWS DB instance ID
Database Type
postgresql
Provider Region
The region your Amazon RDS instance is using. i.e us-central1
Service Account Key
Copy the JSON text of the service account key of the Gateway
Google Workspace Administrator Email
The email address for a Workspace administrator account that can be used to manage passwords for GCP Principals.
A Keeper Rotation gateway is already installed, running, and is able to communicate with your GCP SQL Server Database
If the Gateway is installed on a Linux or macOS server, install the Microsoft ODBC driver
Your AWS environment is configured per our documentation
Admin account password
Connect Database
Optional database that will be used when connecting to the database server.
For example, MS SQL server requires a database and so this will default to master.
Database ID
The AWS DB instance ID
Database Type
mssql
ProviderRegion
The region your Amazon RDS instance is using. i.e us-central1
Copy the JSON text of the service account key of the Gateway
Google Workspace Administrator Email
The email address for a Workspace administrator account that can be used to manage passwords for GCP Principals.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Title
Keeper record title Ex: GCP SQL Server Admin
Hostname or IP Address
The SQL Server Endpoint
Port
The SQL Server Port, for default ports see port mapping
i.e. 1433
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Select the Gateway that is configured on the Keeper Secrets Manager application.
ApplicationFolder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the PAM User records.
GCP ID
A unique ID for this instance of Google Cloud. This is only for your reference and can be anything, but its recommended to be kept short
Ex: GCP-DepartmentName
Title
Keeper record title i.e. GCP DB User 1
Login
Case sensitive username of the account being rotated. If the user in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@HOST
Password
Account password is optional, rotation will set one if blank
Connect Database
Optional database that will be used when connecting to the database server.
For example, MS SQL server requires a database and so this will default to master.
A Keeper Rotation gateway is already installed, running, and is able to communicate to your MongoDB Database
Optional database that will be used when connecting to the database server.
For example, MongoDB requires a database and so this will default to admin.
Database Type
mongodb
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Title
Keeper record title Ex: dbadmin
Hostname or IP Address
Server address - doesn't need to be publicly routable
Port
For default ports, see port mapping
Ex: mongodb=27017
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Administrative Credentials
Linked PAM User record that contains the username and password of the Admin account which will perform the rotation.
Title
Configuration name, example: MongoDB LAN Configuration
Environment
Select: Local Network
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your MongoDB database
Application Folder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the PAM User records, not the database resources.
Record Type
PAM User
Title
Keeper record title
Login
Case sensitive username of the db account being rotated. Example: msmith
Password
Account password is optional, rotation will set one if blank
Connect Database
Optional database that will be used when connecting to the database server.
For example: MongoDB requires a database and so this will default to admin.
A Keeper Rotation gateway is already installed, running, and is able to communicate with your Google Cloud Directory Services
Your Google Cloud environment is configured per our documentation
Directory Service Admin Account's Distinguished Name (DN).
Example: CN=jsmith,OU=Cloud,DC=example,DC=comNote: If DN is not provided, the following format will be used:
Given domain name is example.com:
CN=<user>,CN=Users,DC=example,DC=com
Domain Name
The Directory DNS Name
Note: This is required if using Login instead of Distinguished Name
Directory ID
Directory Service's Identifier i.e d-##########
Directory Type
Directory Service Directory type, defaults to Active Directory if left blank.
Provider Region
Google Cloud region name i.e. us-east1
Copy the JSON text of the service account key of the Gateway
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Title
Name of the Record i.e. AD Domain Service
Hostname or IP Address
The Directory DNS Name i.e. ad.pam.test
Port
636 for LDAPS
Use SSL (checkbox)
Must be checked
Administrative Credentials
PAM User providing the directory service admin account and password i.e. Admin
Note: Either Login and Domain Name or Distinguished Name is required. Distinguished Name is preferred.
Select the Gateway that is configured on the Keeper Secrets Manager application.
ApplicationFolder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the PAM User records.
GCP ID
A unique ID for this instance of Google Cloud. This is only for your reference and can be anything, but its recommended to be kept short
Ex: GCP-DepartmentName
Title
Keeper record title i.e. AWS Directory User1
Login
Username of the Directory Service's user account
Password
Account password is optional, rotation will set one if blank
DistinguishedName
Directory Service User Account's Distinguished Name (DN)
az keyvault secret set --vault-name <VAULT_NAME> --name "DOCKER-TOKEN" --value "<YOUR_DOCKER_HUB_PAT>"
az keyvault secret set --vault-name <VAULT_NAME> --name "GATEWAY-CONFIG" --value "<YOUR_BASE64_CONFIG>"
az containerapp create \
--name <APP_NAME> \
--resource-group <RESOURCE_GROUP> \
--environment <ENVIRONMENT_NAME> \
--image keeper/gateway:latest \
--cpu 2.0 --memory 8Gi \
--system-assigned \
--registry-server index.docker.io \
--registry-username <DOCKER_HUB_USER> \
--registry-password <Enter your Docker PAT, which starts with dckr_pat_...>
--env-vars "ACCEPT_EULA=Y"
PRINCIPAL_ID=$(az containerapp show -n <APP_NAME> -g <RESOURCE_GROUP> --query identity.principalId -o tsv)
az role assignment create --assignee $PRINCIPAL_ID --role "Key Vault Secrets User" --scope /subscriptions/<SUB_ID>/resourceGroups/providers/Microsoft.KeyVault/vaults/<VAULT_NAME>
az containerapp secret set -n <APP_NAME> -g <RESOURCE_GROUP> \
--secrets "docker-password-kv=keyvaultref:https://<VAULT_NAME>.vault.azure.net/secrets/DOCKER-TOKEN,identityref:system" \
"gateway-config-kv=keyvaultref:https://<VAULT_NAME>.vault.azure.net/secrets/GATEWAY-CONFIG,identityref:system"
az containerapp registry set
-n <APP_NAME> \
-g <RESOURCE_GROUP> \
--server index.docker.io \
--username <DOCKER_HUB_USER> \
--password "secretref:gateway-config-kv"
template:
containers:
- name: <APP_NAME>
image: keeper/gateway:latest
env:
- name: GATEWAY_CONFIG
secretRef: gateway-config-kv # Use name from Option A or B
volumeMounts:
- mountPath: /dev/shm
volumeName: shm-volume
volumes:
- name: shm-volume
storageType: EmptyDir
Just-In-Time Ephemeral Account Creation during PAM Sessions
Just-In-Time Role Elevation during Privileged Sessions
Just-In-Time Access with Keeper Privilege Manager
Time-Limited Access
Workflow and Requests for Approval
PAM User
Local Windows accounts, Domain accounts, Active Directory users, IAM users, database accounts, SaaS accounts, Linux accounts, SSH Private Keys
What is a PAM User
KeeperPAM User records define a specific account inside another PAM resource. PAM Machines, PAM Databases, PAM Directories and PAM Remote Browser records link to a PAM User.
Features Available
The PAM User resource supports the following features:
On-demand and scheduled password rotation
PAM Scripts for privilege automation
Persistent sharing to users and teams
Sharing with time-limited access
Auto-rotation after share revocation
Creating a PAM User
Prior to creating a PAM User, make sure you have already created a PAM Configuration and a PAM Resource such as a Machine, Database, Directory or Browser.
To create a PAM User:
Click on Create New
Depending on your use case, click on "Rotation", "Tunnel", or "Connection"
On the prompted window:
Select "New Record"
Select the Shared Folder you want the record to be created in
Specify the Title
Select "User" for the Target
Click "Next" and complete all of the required information.
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 below.
When connecting to Windows machines that are domain-joined:
For domain-joined systems, always use the UPN format ([email protected]) as it is more modern, DNS-reliant, and avoids NetBIOS issues.
Reserve DOMAIN\user for older systems or mixed environments where UPN isn't supported.
Note that Keeper will attempt to login to the remote system using the username exactly as supplied. If authentication fails, Keeper will then attempt to use the below variations:
Domain FQDN with backslash format: company.com\admin
SSH Key Passphrase
When the PAM User record is storing an SSH key, the PEM-encoded private key is added to the "Private Key" field. If the SSH key file is encrypted, you can create a custom field with the title of "Passphrase" which stores the SSH key passphrase.
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
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 .
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, Azure managed resources, and Google Workspace principals. In this case, only the PAM Configuration is required since it contains the necessary credentials.
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, Azure and GCP managed resources, Keeper uses Instance Role permission of the Gateway, or specific PAM Configuration secrets to perform the rotation with APIs.
For Google Cloud managed resources, Keeper uses the Service Account permissions of the Gateway.
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
Commander CLI
The Keeper Commander CLI provides specialized automation tools to create PAM User records, perform rotations, share credentials to team members, and deliver credentials through one-time share links for new employee onboarding.
A Keeper Secrets Manager application has been created
Your Azure environment is configured per our documentation
A Keeper Rotation is already installed
The Gateway can communicate to the target Windows machine using or
PowerShell is available on all Windows machines and bash on all Linux targets
1. Set up PAM Machine Records
Keeper can rotate any local user account on either the Gateway machine or any other machine on the network. A PAM Machine record should be created for every machine. This PAM Machine record will be associated to a linked administrative credential that has the rights to change passwords for users on the machine.
Once a PAM Machine record is created for every machine, a PAM User record needs to be created for each user account that will be rotated.
The following table lists all the requiredfields that needs to be filled on the PAM Machine records.
Field
Description
Title
Name of the Record e.g. Windows Machine 1
Hostname or IP Address
Machine hostname or IP as accessed by the Gateway, e.g. 10.0.1.4
Port
Typically 5985 or 5986 for WinRM, 22 for SSH
Private PEM Key
Required for SSH if not using a password
Operating System
The VM Operating System: Windows or Linux
2. Set up PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
Make sure the following items are completed first:
A Keeper Secrets Manager application has been created
A Keeper Rotation gateway is already installed, running, and is provisioned in the Keeper Secrets Manager application you created.
PAM Machine records have been created for each target machine
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields that needs to be filled on the PAM Configuration.
Field
Description
Title
Configuration name, example: Azure Demo
Environment
Select: Azure Network
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to the machine configured from step 1
Application Folder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the admin accounts, not the machines.
Azure ID
A unique ID for this instance of Azure. This is for your reference and can be anything, but its recommended to be kept short
Ex: Azure-prod
For more details on all the configurable fields in the PAM Configuration record, visit this page.
3. Set up PAM User records
Keeper Rotation will use the credentials linked from the PAM Machine record to rotate the credentials of accounts referenced by the PAM User records.
The following table lists all the requiredfields that need to be filled on the PAM User record:
Field
Description
Title
Keeper record title i.e. Local User1
Login
Case sensitive username of the account being rotated. The username has to be in one of the following formats:
domain\usernameusername@domain
Password
Account password is optional, rotation will set one if blank
4. Configure Rotation on the PAM User records
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Machine admin credential specific to this user's machine.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
Keeper can automatically update the Windows service account "log on as" credentials for any Windows services running as the PAM User, and restart the service. Keeper will also update the credential of any scheduled task running as that user on the target machine.
To learn more and set up this capability, see the Service Management page.
See the Azure Overview for a high level overview and getting started with Azure
Prerequisites
This guide assumes the following tasks have already taken place:
A Keeper Secrets Manager application has been created
Your Azure environment is configured per our documentation
Your is online
The Keeper Gateway is able to communicate with your Azure SQL Server Database
If the Gateway is installed on a Linux or macOS server, install the
1. Set up a PAM Database Record
The PAM Database record links to admin credentials and contains the necessary configurations to connect to the SQL Server on Azure. Keeper Rotation will use these provided configurations to rotate passwords of regular database user accounts in the Azure SQL Server instance. These provided admin credentials need to also have sufficient database permissions to successfully change the credentials of the database user accounts.
The following table lists all the required fields on the PAM Database Record:
Field
Description
Title
Keeper record title Ex: Azure SQL Admin
Hostname or IP Address
The Database Server name i.e testdb-sql.mssql.database.azure.com
Port
For default ports, see
Ex: 1433
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Administrative Credentials
PAM User providing the Admin account username and password that will perform rotation. If the admin in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@SERVERNAME
Note: Adding Provider Group, Provider Region, and Database ID will enable managing the PAM Database Record through the Azure SDK.
This PAM Database Record with the linked admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users.
2. Set up PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields on the PAM Configuration Record:
Field
Description
Title
Configuration name, example: Azure DB Configuration
Environment
Select: Azure Network
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your Azure SQL database from the pre-requisites
ApplicationFolder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the PAM User records.
Azure ID
A unique ID for this instance of Azure. This is for your reference and can be anything, but its recommended to be kept short
Ex: Azure-Prod
For more details on all the configurable fields in the PAM Configuration record, visit this page.
3. Set up one or more PAM User records
Keeper Rotation will use the linked credentials in the PAM Database record to rotate the PAM User records on your Azure environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields on the PAM User record:
Field
Description
Title
Keeper record title i.e. Azure DB User1
Login
Case sensitive username of the account being rotated. If the user in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@SERVERNAME
Password
Account password is optional, rotation will set one if blank
Connect Database
Optional database that will be used when connecting to the database server.
For example, MS SQL server requires a database and so this will default to master.
4. Configure Rotation on the PAM User records
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
See the Azure Overview for a high level overview and getting started with Azure
Prerequisites
This guide assumes the following tasks have already taken place:
A Keeper Secrets Manager application has been created
Your Azure environment is configured per our documentation
Your is online
Your Keeper Gateway is able to communicate with the Azure Managed PostgreSQL database
1. Set up a PAM Database Record
The PAM Database record links to the admin credentials and necessary configurations to connect to the PostgreSQL Server on Azure. Keeper Rotation will use these provided configurations to rotate passwords of regular database user accounts in the Azure PostgreSQL Server instance. These provided admin credentials need to also have sufficient database permissions to successfully change the credentials of the database user accounts.
The following table lists all the required fields on the PAM Database Record:
Field
Description
Title
Keeper record title Ex: Azure PostgreSQL Admin
Hostname or IP Address
The Database Server name i.e testdb-psql.postgresql.database.azure.com
Port
For default ports, see
i.e. 5432
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Administrative Credentials
PAM User admin account username that will perform rotation. If the Admin account in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@HOST
Note: Adding Provider Group, Provider Region, and Database ID will enable managing the PAM Database Record through the Azure SDK.
This PAM Database Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users.
2. Set up PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment..
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields on the PAM Configuration Record:
Field
Description
Title
Configuration name, example: Azure DB Configuration
Environment
Select: Azure Network
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your Azure PostgreSQL database from the pre-requisites
ApplicationFolder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the PAM User records.
Azure ID
A unique ID for this instance of Azure. This is for your reference and can be anything, but its recommended to be kept short
Ex: Azure-Prod
For more details on all the configurable fields in the PAM Configuration record, visit this page.
3. Set up one or more PAM User records
Keeper Rotation will use the linked credentials in the PAM Database record to rotate the PAM User records on your Azure environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields on the PAM User record:
Field
Description
Title
Keeper record title i.e. Azure PostgreSQL User1
Login
Case sensitive username of the account being rotated. If the user in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@SERVERNAME
Password
Account password is optional, rotation will set one if blank
Connect Database
Optional database that will be used when connecting to the database server.
For example: PostgreSQL requires a database and so this will default to template1
4. Configure Rotation on the PAM User records
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
RBI (Chromium) session traffic to target web servers
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:
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 - Bypass list for excluded hosts
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
--proxy-url
Complete proxy URL with optional credentials
http://proxy.company.com:8080
--proxy-host
Proxy server hostname or IP address
proxy.company.com
--proxy-port
Proxy server port number
8080
--proxy-username
Authentication username (if required)
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):
A Keeper Secrets Manager application has been created
A Keeper Rotation is already installed, running, and is able to communicate with your AWS PostgreSQL Database
Your AWS environment is per our documentation
1. Set up a PAM Database Record
The PAM Database record contains the admin credentials and necessary configurations to connect to the PostgreSQL RDS instance on AWS. Keeper Rotation will use these provided configurations to rotate passwords of regular database user accounts in the PostgreSQL RDS instance. These provided admin credentials need to also have sufficient database permissions to successfully change the credentials of the database user accounts.
The following table lists all the required fields on the PAM Database Record:
Field
Description
Title
Keeper record title Ex: AWS PostgreSQL Admin
Hostname or IP Address
The RDS Endpoint i.e. rdsdb.ckivswes.us-east-2.rds.amazonaws.com
Port
The RDS Port, for default ports see
i.e. 5432
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Login
Admin account username that will perform rotation
Note: Adding Provider Region and Database ID will enable managing the PAM Database Record through the SDK.
This PAM Database Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users
2. Set up PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields on the PAM Configuration Record:
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your PostgreSQL RDS Instance
ApplicationFolder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the PAM User records, not the database resources.
AWS ID
A unique ID for this instance of AWS. This is for your reference and can be anything, but its recommended to be kept short
Ex: AWS-1
For more details on all the configurable fields in the PAM Configuration record, visit this page.
3. Set up PAM User Records
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your AWS environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields on the PAM User record:
Field
Description
Title
Keeper record title i.e. AWS DB User 1
Login
Case sensitive username of the account being rotated. If the user in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@HOST
Password
Account password is optional, rotation will set one if blank
Connect Database
Optional database that will be used when connecting to the database server.
For example: PostgreSQL requires a database and so this will default to template1
4. Configure Rotation on the PAM User records
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
PAM Directory
record type, must be using a SSL Connection.
Prerequisites
This guide assumes the following tasks have already taken place:
A Keeper Secrets Manager application has been created
A Keeper Rotation is already installed, running, and is able to communicate with your AWS Directory Services
Your AWS environment is per our documentation
1. Set up a PAM Directory Record
Keeper Rotation will use the linked admin credentials of your AWS Managed Directory Service to rotate passwords of Domain Service's directory accounts. These admin credentials can also be used to rotate the passwords of the Directory admin.
The following table lists all the required fields on the PAM Directory Record:
Field
Description
Title
Name of the Record i.e. AD Domain Service
Hostname or IP Address
The Directory DNS Name i.e. ad.pam.test
Port
636 for LDAPS
Use SSL (checkbox)
Must be checked
Administrative Credentials
PAM User providing the directory service admin account and password i.e. Admin
Note: Either Login and Domain Name or Distinguished Name is required. Distinguished Name is preferred.
Note: Adding Provider Region and Directory ID will enable managing the PAM Directory Record through the AWS SDK, which is preferred.
This PAM Directory Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users.
2. Set up PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields on the PAM Configuration Record:
Field
Description
Title
Configuration name, example: AWS AD Configuration
Environment
Select: AWS
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your Active Directory server from the pre-requisites
Application Folder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the admin accounts, not the machines.
AWS ID
A unique ID for this instance of AWS. This is for your reference and can be anything, but its recommended to be kept short
Ex: AWS-1
For more details on all the configurable fields in the PAM Configuration record, visit this page.
3. Set up one or more PAM User Records
Keeper Rotation will use the credentials in the PAM Directory record to rotate the PAM User records on your AWS environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields on the PAM User record:
Field
Description
Title
Keeper record title i.e. AWS Directory User1
Login
Username of the Directory Service's user account
Password
Account password is optional, rotation will set one if blank
DistinguishedName
Directory Service User Account's Distinguished Name (DN)
4. Configure Rotation on the PAM User records
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Directory credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
Troubleshooting
Getting the Distinguished Names of AWS Managed Directory Service Users
The following windows command can be used to get the distinguished name of the Directory user:
If the command does not exist, you need to import the appropriate module with:
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.
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:
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.
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.
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
See the Azure Overview for a high level overview and getting started with Azure
Prerequisites
This guide assumes the following tasks have already taken place:
A Keeper Secrets Manager application has been created
Your Azure environment is configured per our documentation
Your is online
Your Keeper Gateway is able to communicate with the Azure Managed MariaDB database
1. Set up a PAM Database Record
The PAM Database record links to the admin credentials and necessary configurations to connect to the MariaDB server on Azure. Keeper Rotation will use these provided configurations to rotate passwords of regular database user accounts in the Azure MariaDB Server instance. These provided admin credentials need to also have sufficient database permissions to successfully change the credentials of the database user accounts.
The following table lists all the required fields on the PAM Database Record:
Field
Description
Title
Keeper record title Ex: Azure MariaDB Admin
Hostname or IP Address
The Database Server name i.e testdb-mariadb.mariadb.database.azure.com
Port
For default ports, see
Ex: mariadb=3306
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Administrative Credentials
PAM User admin account username that will perform rotation. If the admin in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@SERVERNAME
Note: Adding Provider Group, Provider Region, and Database ID will enable managing the PAM Database Record through the Azure SDK.
This PAM Database Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users.
2. Set up PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields on the PAM Configuration Record:
Field
Description
Title
Configuration name, example: Azure DB Configuration
Environment
Select: Azure Network
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your Azure MariaDB database from the pre-requisites
ApplicationFolder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the PAM User records.
Azure ID
A unique ID for this instance of Azure. This is for your reference and can be anything, but its recommended to be kept short
Ex: Azure-Prod
For more details on all the configurable fields in the PAM Configuration record, visit this page.
3. Set up one or more PAM User records
Keeper Rotation will use the linked credentials in the PAM Database record to rotate the PAM User records on your Azure environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields on the PAM User record:
Field
Description
Title
Keeper record title i.e. Azure MariaDB User1
Login
Case sensitive username of the account being rotated. If the user in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@SERVERNAME
Password
Account password is optional, rotation will set one if blank
4. Configure Rotation on the PAM User records
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
A Keeper Secrets Manager application has been created
A Keeper Rotation is already installed, running, and is able to communicate with your AWS SQL Server Database
If the Gateway is installed on a Linux or macOS server, install the
Your AWS environment is per our documentation
1. Set up a PAM Database Record
The PAM Database record contains the admin credentials and necessary configurations to connect to the SQL Server RDS instance on AWS. Keeper Rotation will use these provided configurations to rotate passwords of regular database user accounts in the SQL Server RDS instance. These provided admin credentials need to also have sufficient database permissions to successfully change the credentials of the database user accounts.
The following table lists all the required fields on the PAM Database Record:
Field
Description
Title
Keeper record title Ex: RDS SQL Server Admin
Hostname or IP Address
The RDS Endpoint i.e. rdsdb.ckivswes.us-east-2.rds.amazonaws.com
Port
The RDS Port, for default ports see
i.e. 1433
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Login
Admin account username that will perform rotation
Note: Adding Provider Region and Database ID will enable managing the PAM Database Record through the SDK.
This PAM Database Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users
2. Set up PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields on the PAM Configuration Record:
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your SQL Server RDS Instance
ApplicationFolder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the PAM User records, not the database resources.
AWS ID
A unique ID for this instance of AWS. This is for your reference and can be anything, but its recommended to be kept short
Ex: AWS-1
For more details on all the configurable fields in the PAM Configuration record, visit this page.
3. Set up PAM User Records
Keeper Rotation will use the credentials in the PAM Database record to rotate the PAM User records on your AWS environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields on the PAM User record:
Field
Description
Title
Keeper record title i.e. AWS DB User 1
Login
Case sensitive username of the account being rotated. If the user in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@HOST
Password
Account password is optional, rotation will set one if blank
Connect Database
Optional database that will be used when connecting to the database server.
For example, MS SQL server requires a database and so this will default to master.
4. Configure Rotation on the PAM User records
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
Google Compute Virtual Machine User
Rotating Google Compute Virtual Machine accounts with Keeper
In this guide, you will learn how to rotate Google Compute Virtual Machine (VM) Accounts on your Google Cloud Environment using Keeper Rotation. The Compute VM is an GCP managed resource where the Google Compute VM Admin Credentials are linked to the PAM Machine record and the identity of the Google Compute VM Users are defined in the PAM User record type.
For Google Compute VM Accounts, normal operating system commands are used to change the password. Keeper will connect to the target machine and send command-line commands to change the password.
Prerequisites
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your
Keeper Rotation is enabled for your
A Keeper Secrets Manager has been created
1. Set up PAM Machine Records
Keeper can rotate any local user account on either the Gateway machine or any other machine on the network. A PAM Machine record should be created for every machine. This PAM Machine record should link to an administrative credential that has the rights to change passwords for users on the machine.
Once a PAM Machine record is created for every machine, a PAM User record needs to be created for each local user account that will be rotated.
Keeper will use the referenced admin credential to rotate the password or SSH key of AWS Virtual Machine users in your AWS environment. These admin credentials need to have the sufficient permissions in order to successfully change the credentials of these user accounts.
If you are running a rotation on a PAM Machine record which also happens to be the same machine running the Keeper Gateway, Keeper will attempt to rotate the password or SSH key for the account using the keeper-gw user. Assuming that keeper-gw has sudoers privilege, it will be able to perform rotations on the local Gateway machine.
The following table lists all the requiredfields on the PAM Machine record:
Field
Description
This PAM Machine Record with the linked admin credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users.
2. Set up PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
In the left menu of the vault, select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields on the PAM Configuration Record:
Field
Description
For more details on all the configurable fields in the PAM Configuration record, visit this .
3. Set up PAM User Records
Keeper will use the credentials linked from the PAM Machine record to rotate the PAM User records in your Google Cloud environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields that need to be filled on the PAM User record:
Field
Description
4. Configure Rotation on the Record - GCP VM User
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Machine credential setup from Step 1.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
SSH Key Rotation Notes
When rotating the private PEM Key credential on a target machine or user, Keeper will update the authorized_keys file on the machine with the new public key. The first time that a rotation occurs, the old public key is left intact in order to prevent system lockout. The second public key added to the file contains a comment that serves as an identifier for future rotations. For example:
By default, Keeper will not remove other keys from the .ssh/authorized_keys file since some providers will place in their own keys in order to control the virtual machine (ie Google Cloud Provider).
If the first rotation is successful, you can optionally delete the old public key entry in the authorized_keys file. On subsequent rotations, Keeper will update the line which contains the "keeper-security-xxx" comment.
Rotation will also create backup of the prior .ssh/authorized_keys inside of the .ssh directory.
For private key rotation, the new private key will be same algorithm and key size (bits) as the current private key. For example, if the current private key is ecdsa-sha2-nistp256 the new private key will be ecdsa-sha2-nistp256. This can be overridden by adding a custom text field, with the label Private Key Type , and setting the value to one support algorithms:
ssh-rsa - 4096 bits
ecdsa-sha2-nistp256 - ECDSA, 256 bits
ecdsa-sha2-nistp384 - ECDSA, 384 bits
.This custom field can also be used if the current private key's algorithm cannot be detected.
To prevent private key rotation, a custom text field can be added to the PAM User record with the label Private Key Rotate. If the value of the field is TRUE, or the field doesn't exists, the private key will be rotated if it exists. If the value is FALSE, the private key will not be rotated.
For Linux user rotations, password-encrypted PEM files are not currently supported.
Administrative Credential - SSH key only accounts
When configuring a PAM User with only a private PEM key and no password as the admin credential for a machine resource, this user will execute all administrative operations such as password rotation. In this configuration, the admin account must be able to perform sudo operations without being prompted for a password.
If a password is required to execute sudo commands, rotations for non-admin credentials on that resource will fail—since the admin credential does not include a password. To ensure successful rotation, configure the PEM key only admin account to run sudo commands without a password prompt.
EC2 Virtual Machine User
Rotating AWS EC2 Virtual Machine accounts with Keeper
In this guide, you will learn how to rotate AWS EC2 Virtual Machine (VM) Accounts on your AWS Environment using Keeper Rotation. The EC2 VM is an AWS managed resource where the EC2 VM Admin Credentials are linked to the PAM Machine record and the identity of the EC2 VM Users are defined in the PAM User record type.
For EC2 VM Accounts, normal operating system commands are used to change the password. Keeper will connect to the target machine and send command-line commands to change the password.
Prerequisites
This guide assumes the following tasks have already taken place:
Keeper Secrets Manager is enabled for your
Keeper Rotation is enabled for your
A Keeper Secrets Manager has been created
1. Set up PAM Machine Records
Keeper can rotate any local user account on either the Gateway machine or any other machine on the network. A PAM Machine record should be created for every machine. This PAM Machine record should link to an administrative credential that has the rights to change passwords for users on the machine.
Once a PAM Machine record is created for every machine, a PAM User record needs to be created for each local user account that will be rotated.
Keeper will use the referenced admin credential to rotate the password or SSH key of AWS Virtual Machine users in your AWS environment. These admin credentials need to have the sufficient permissions in order to successfully change the credentials of these user accounts.
If you are running a rotation on a PAM Machine record which also happens to be the same machine running the Keeper Gateway, Keeper will attempt to rotate the password or SSH key for the account using the keeper-gw user. Assuming that keeper-gw has sudoers privilege, it will be able to perform rotations on the local Gateway machine.
The following table lists all the requiredfields on the PAM Machine record:
Field
Description
This PAM Machine Record with the linked admin credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users.
2. Set up PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
Make sure the following items are completed:
A Keeper Secrets Manager has been created
A Keeper Rotation is already installed, running, and is provisioned in the Keeper Secrets Manager application you created.
PAM Machine records have been created for each target machine
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields that needs to be filled on the PAM Configuration.
Field
Description
For more details on all the configurable fields in the PAM Configuration record, visit this .
3. Set up PAM User Records
Keeper will use the credentials linked from the PAM Machine record to rotate the PAM User records in your AWS environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields that need to be filled on the PAM User record:
Field
Description
4. Configure Rotation on the Record - AWS VM User
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Machine credential setup from Step 1.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
SSH Key Rotation Notes
When rotating the private PEM Key credential on a target machine or user, Keeper will update the authorized_keys file on the machine with the new public key. The first time that a rotation occurs, the old public key is left intact in order to prevent system lockout. The second public key added to the file contains a comment that serves as an identifier for future rotations. For example:
By default, Keeper will not remove other keys from the .ssh/authorized_keys file since some providers will place in their own keys in order to control the virtual machine (ie Google Cloud Provider).
If the first rotation is successful, you can optionally delete the old public key entry in the authorized_keys file. On subsequent rotations, Keeper will update the line which contains the "keeper-security-xxx" comment.
Rotation will also create backup of the prior .ssh/authorized_keys inside of the .ssh directory.
For private key rotation, the new private key will be same algorithm and key size (bits) as the current private key. For example, if the current private key is ecdsa-sha2-nistp256 the new private key will be ecdsa-sha2-nistp256. This can be overridden by adding a custom text field, with the label Private Key Type , and setting the value to one support algorithms:
ssh-rsa - 4096 bits
ecdsa-sha2-nistp256 - ECDSA, 256 bits
ecdsa-sha2-nistp384 - ECDSA, 384 bits
.This custom field can also be used if the current private key's algorithm cannot be detected.
To prevent private key rotation, a custom text field can be added to the PAM User record with the label Private Key Rotate. If the value of the field is TRUE, or the field doesn't exists, the private key will be rotated if it exists. If the value is FALSE, the private key will not be rotated.
For Linux user rotations, password-encrypted PEM files are not currently supported.
Administrative Credential - SSH key only accounts
When configuring a PAM User with only a private PEM key and no password as the admin credential for a machine resource, this user will execute all administrative operations such as password rotation. In this configuration, the admin account must be able to perform sudo operations without being prompted for a password.
If a password is required to execute sudo commands, rotations for non-admin credentials on that resource will fail—since the admin credential does not include a password. To ensure successful rotation, configure the PEM key only admin account to run sudo commands without a password prompt.
Azure MySQL - Single or Flexible Database
Rotating Admin/Regular Azure MySQL Single or Flexible Database Users with Keeper
Overview
In this guide, you'll learn how to rotate passwords for Azure MySQL Database Users and Admin accounts on your Azure environment using Keeper Rotation. Azure MySQL is an Azure managed resource where the MySQL Admin Credentials are defined in the PAM Database record type and the configurations of the MySQL Users are defined in the PAM User record type.
For Azure Managed MySQL database, the Azure SDK will be used to rotate the password of Database Admin Accounts. To rotate the passwords of Regular Database Users, Keeper connects to the DB instance with the provided admin credentials and executes the necessary SQL statements to change the password.
See the for a high level overview and getting started with Azure
In 2024, Azure is going to sunset the non-flexible MySQL managed services. Most likely the term flexible will be removed. See:
Prerequisites
This guide assumes the following tasks have already taken place:
are configured for your role
A Keeper Secrets Manager has been created
Your Azure environment is per our documentation
1. Set up a PAM Database Record
The PAM Database record links to the admin credentials and necessary configurations to connect to the MySQL Server on Azure. Keeper Rotation will use these provided configurations to rotate passwords of regular database user accounts in the Azure MySQL Server instance. These provided admin credentials need to also have sufficient database permissions to successfully change the credentials of the database user accounts.
The following table lists all the required fields on the PAM Database Record:
Field
Description
Note: Adding Provider Group, Provider Region, and Database ID will enable managing the PAM Database Record through the Azure SDK.
This PAM Database Record with the admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users.
2. Set up PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
If you are creating a new PAM Configuration, login to the Keeper Vault and select "Secrets Manager", then select the "PAM Configurations" tab, and click on "New Configuration".
The following table lists all the requiredfields on the PAM Configuration Record:
Field
Description
For more details on all the configurable fields in the PAM Configuration record, visit this .
3. Set up one or more PAM User records
Keeper Rotation will use the linked credentials in the PAM Database record to rotate the PAM User records on your Azure environment. The PAM User credential needs to be in a shared folder that is shared to the KSM application created in the prerequisites.
The following table lists all the requiredfields on the PAM User record:
Field
Description
4. Configure Rotation on the PAM User records
Select the PAM User record(s) from Step 3, edit the record and open the "Password Rotation Settings".
Select the desired schedule and password complexity.
The "Rotation Settings" should use the PAM Configuration setup previously.
The "Resource Credential" field should select the PAM Database credential setup from Step 1.
Any user with edit rights to a PAM User record has the ability to setup rotation for that record.
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
Additionally, in order to enable Google Workspace user password changes, the service account also needs:
Domain-wide delegation enabled in Google Workspace Admin Console
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
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)
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
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
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:
Verify the service account has domain-wide delegation enabled
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:
Regenerate the service account key in GCP Console
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
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
Additional Resources
Active Directory
Rotating Active Directory user accounts remotely using KeeperPAM
Overview
In this guide, you'll learn how to remotely rotate Active Directory user accounts using KeeperPAM.
Prerequisites
This guide assumes the following tasks have already taken place:
are configured for your role
A Keeper Secrets Manager has been created
Your is online
1. Set up a PAM User Record
Keeper Rotation will use the credentials in this PAM User record to rotate other accounts in your directory. This account does not need to be a domain admin account, but needs to be able to successfully change passwords for other accounts.
The PAM User record needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users.
PAM User Record Fields
Field
Description
2. Set up a PAM Configuration
A associates an environment with a Keeper Gateway and credentials. If you don't have a PAM Configuration set up yet for this use case, create one.
Field
Description
3. Set up PAM User records
KeeperPAM will use the credentials linked from the PAM User record to rotate other PAM User records in your environment. The PAM User credential needs to be saved in a shared folder that is assigned to the secrets manager application. In the example below, the AD user demouser can be rotated.
PAM User Record Fields
Field
Description
If you don't know the user's DN, the following PowerShell command can be used to find it:
4. Configure Rotation on the Record
Select the PAM User record, edit the record and open the Password Rotation Settings.
Any user with edit rights to a PAM User record and allowing rotation has the ability to set up rotation for that record.
The "Rotation" should be of type IAM User.
The "PAM Configuration" field should point to the Active Directory PAM Configuration created in step 2.
Select the desired schedule and password complexity.
Troubleshooting
An easy way to test if LDAP is properly configured is to run 'LDP.exe' and test the connection. If this connection succeeds, then Keeper Rotation should also succeed.
Testing with a Self-Signed Cert
For the purpose of testing an Active Directory user account rotation with Keeper, it is necessary to ensure that the LDAPS connection is active and using a valid certificate. If you are just testing and don't have a production certificate, the instructions below provide you with a self-signed cert.
Using a self-signed certificate with AD is only for testing purposes, do not use in production
1
Create a cert
From PowerShell running as an administrator, create a self-signed cert. Note that the subject name and alternate names of the certificate must match with the server hostname. In this example, the primary name is XYZ123.company.local with alternate names company.local and company.
Gateway on Azure Container Instance
Instructions for installing Keeper Gateway on an Azure Container Instance
Overview
This document contains information on how to install, configure, and update your Keeper Gateway on an Azure Container Instance. The Keeper Gateway container is built upon the base image of Rocky Linux 9 and it is hosted in .
Active Directory or OpenLDAP User
Rotating Active Directory or OpenLDAP user accounts remotely using KeeperPAM
Overview
In this guide, you'll learn how to remotely rotate Active Directory or OpenLDAP user accounts using KeeperPAM.
Directory Service Admin Account's Distinguished Name (DN).
Note: If DN is not provided, the following format will be used:
Given domain name is example.com:
CN=<user>,CN=Users,DC=example,DC=com
Domain Name
The Directory DNS Name
Note: This is required if using Login instead of Distinguished Name
Directory ID
Directory Service's Identifier i.e d-##########
Directory Type
Directory Service Directory type, defaults to Active Directory if left blank.
Provider Region
AWS region name i.e. us-east-1
Access Key ID
Set this field to USE_INSTANCE_ROLE if you are using EC2 role policy (default). Otherwise use a specific Access Key ID.
Access Secret Key
Set this field to USE_INSTANCE_ROLE if you are using EC2 role policy (default). Otherwise use a specific Access Key ID.
Region Names
List of AWS region names, one per line
Example:
us-east-1
us-east-2
Optional database that will be used when connecting to the database server.
For example, MS SQL server requires a database and so this will default to master.
Database ID
Name of the Azure Database Server i.e. testdb-sql
Database Type
mssql
Provider Group
Azure Resource group name
Provider Region
Azure Resource region i.e. East US
Client ID
The unique Application (client) ID assigned to your app by Azure AD when the application was registered
Client Secret
The client credentials secret for the Azure application
Subscription ID
The UUID that identifies your subscription (i.e. Pay-As-You-GO) to use Azure services.
Optional database that will be used when connecting to the database server.
For example, PostgreSQL requires a database and so this will default to template1.
Database ID
Name of the Azure Database Server i.e. testdb-psql
Database Type
postgresql or postgresql-flexible
Provider Group
Azure Resource group name
Provider Region
Azure Resource region i.e. East US
Client ID
The unique Application (client) ID assigned to your app by Azure AD when the application was registered
Client Secret
The client credentials secret for the Azure application
Subscription ID
The UUID that identifies your subscription (i.e. Pay-As-You-GO) to use Azure services.
Optional database that will be used when connecting to the database server.
For example, PostgreSQL requires a database and so this will default to template1.
Database ID
The AWS DB instance ID
Database Type
postgresql
Provider Region
The region your Amazon RDS instance is using. i.e us-east-2
Access Key ID
Set this field to USE_INSTANCE_ROLE if you are using EC2 role policy (default). Otherwise use a specific Access Key ID.
Access Secret Key
Set this field to USE_INSTANCE_ROLE if you are using EC2 role policy (default). Otherwise use a specific Secret Access Key.
Optional database that will be used when connecting to the database server.
For example, MS SQL server requires a database and so this will default to master.
Database ID
The AWS DB instance ID
Database Type
mssql
ProviderRegion
The region your Amazon RDS instance is using. i.e us-east-2
Access Key ID
Set this field to USE_INSTANCE_ROLE if you are using EC2 role policy (default). Otherwise use a specific Access Key ID.
Access Secret Key
Set this field to USE_INSTANCE_ROLE if you are using EC2 role policy (default). Otherwise use a specific Secret Access Key.
Your Keeper Gateway is able to communicate with the Azure MySQL Server Database
Name of the Azure Database Server i.e. testdb-sql
Database Type
mysql or mysql-flexible
Provider Group
Azure Resource group name
Provider Region
Azure Resource region i.e. East US
The unique Application (client) ID assigned to your app by Azure AD when the application was registered
Client Secret
The client credentials secret for the Azure application
Subscription ID
The UUID that identifies your subscription (i.e. Pay-As-You-GO) to use Azure services
Tenant ID
The UUID of the Azure Active Directory
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Title
Keeper record title Ex: Azure MySQL Admin
Hostname or IP Address
The Database Server name i.e testdb-sql.mysql.database.azure.com
Port
For default ports, see port mapping
Ex: mysql=3306
Use SSL
Check to perform SSL verification before connecting, if your database has SSL configured
Administrative Credentials
PAM User admin account username and password that will perform rotation. If the Admin account in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@HOST
Title
Configuration name, example: Azure DB Configuration
Environment
Select: Azure Network
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to your Azure MySQL database from the pre-requisites
ApplicationFolder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the PAM User records.
Azure ID
A unique ID for this instance of Azure. This is for your reference and can be anything, but its recommended to be kept short
Ex: Azure-Prod
Title
Keeper record title i.e. Azure DB User1
Login
Case sensitive username of the account being rotated. If the user in the DB user table is in a Host other than %, add the Host value to the user name as USERNAME@SERVERNAME
Password
Account password is optional, rotation will set one if blank
A Keeper Rotation gateway is already installed, running, and is able to communicate via SSH or WinRM with your target Google Compute Virtual Machine(s).
Your Google Cloud environment is configured per our documentation
For WinRM, if selected, will use SSL mode port 5986. Ignored for SSH.
Copy the JSON text of the service account key of the Gateway
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
ecdsa-sha2-nistp521 - ECDSA, 521 bits
ssh-ed2551
Title
Name of the Record i.e GCP Linux 1
Hostname or IP Address
Machine hostname or IP as accessed by the Gateway
Port
Typically 5985 or 5986 for WinRM, 22 for SSH.
Administrative Credentials
Linked PAM User record that contains the username and password (or SSH key) of the Admin account.
Select the Gateway that is configured on the Keeper Secrets Manager application.
ApplicationFolder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the PAM User records.
GCP ID
A unique ID for this instance of Google Cloud. This is only for your reference and can be anything, but its recommended to be kept short
Ex: GCP-DepartmentName
Title
Keeper record title i.e. GCP Machine1 compute-user
Login
Case sensitive username of the user account being rotated, e.g. compute-user.
Password
This is only required if the user logs in with a password. If the password is left blank, performing a rotation will set one.
Private PEM Key
SSH private key. This is only required if you are planning to rotate the PEM key instead of rotating the password.
Password Rotation Settings on Google Cloud Compute Instance User
SSL Verification
Service Account Key
A Keeper Rotation gateway is already installed, running, and is able to communicate via SSH or WinRM with your target AWS Virtual Machine(s).
Your AWS environment is configured per our documentation
For WinRM, if selected, will use SSL mode port 5986. Ignored for SSH.
Set this field to USE_INSTANCE_ROLE if you are using EC2 role policy (default). Otherwise use a specific Access Key ID.
Secret Access Key
Set this field to USE_INSTANCE_ROLE if you are using EC2 role policy (default). Otherwise use a specific Secret Access Key.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
ecdsa-sha2-nistp521 - ECDSA, 521 bits
ssh-ed2551
Title
Name of the Record i.e AWS Linux 1
Hostname or IP Address
Machine hostname or IP as accessed by the Gateway
Port
Typically 5985 or 5986 for WinRM, 22 for SSH.
Administrative Credentials
Linked PAM User record that contains the username and password (or SSH key) of the Admin account.
Operating System
The VM Operating System, i.e Windows or Linux
Title
Configuration name, example: AWS VM Configuration
Environment
Select: AWS
Gateway
Select the Gateway that is configured on the Keeper Secrets Manager application and has network access to the machine configured from step 1
Application Folder
Select the Shared folder where the PAM Configuration will be stored. We recommend placing this in a shared folder with the admin accounts, not the machines.
AWS ID
A unique ID for this instance of AWS. This is for your reference and can be anything, but its recommended to be kept short
Ex: AWS-1
Title
Keeper record title i.e. AWS Machine1 ec2-user
Login
Case sensitive username of the user account being rotated, e.g. ec2-user.
Password
This is only required if the user logs in with a password. If the password is left blank, performing a rotation will set one.
Private PEM Key
SSH private key. This is only required if you are planning to rotate the PEM key instead of rotating the password.
The Keeper Gateway is able to connect to your Active Directory via LDAPS (port 636)
Enter the domain or IP address of your Active Directory domain.
Port
Enter 636 (LDAPS). 389 LDAP is not supported for rotations.
Use SSL
Ensure this checkbox is checked.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
2
Install the cert
This script will locate the cert in the personal section of the certificate manager and copy it into the trusted domains. Replace the company parameter in the first line of this script with the domain in step 1.
3
Restart NTDS
After restarting the NTDS service, the certificate should be installed.
4
Check the connectivity
Run 'LDP.exe' and make sure that you're able to connect to the local domain over port 636 with SSL enabled.
Connect using LDP.exe
Record Type
PAM User
Title
Keeper record title
Login
The username of the Active Directory admin. The format of the username depends on the target system and type of service.
Examples:
Administrator [email protected]
Password
Password of the admin user on the Active Directory.
Distinguished Name
Full Distinguished Name (DN) of the admin user on the Active Directory.
Title
Configuration name, example: My Active Directory
Environment
Select: Domain Controller
Gateway
Select the Gateway that has access to your directory server
Application Folder
Select the Shared folder that contains the PAM User record created in step 1.
Administrative Credential
Select the PAM User record created in step 1.
Record Type
PAM User
Title
Keeper record title, e.g. AD User - demouser
Login
Username of the account being rotated. The format of the username depends on the target system and type of service.
Examples:
demouser
[email protected]
Password
Account password is optional. In most cases, a password rotation will not require the existing password to be present. However there are some scenarios and protocols which may require it.
Distinguished Name
The LDAP DN for the user, e.g.
CN=Demo User,CN=Users,DC=lureydemo,DC=local
Example of Active Directory account password rotation
PAM User scheduled rotations
Testing and LDAP connection with LDP.exe
Hostname or IP Address
Prerequisites
Azure Environment Requirements
Resource Group: A dedicated resource group.
Virtual Network (VNet): A VNet with a dedicated subnet for the gateway.
Subnet Delegation: The designated subnet must be delegated to Microsoft.ContainerInstance/containerGroups .
Subscription Permissions: Contributor access to create Container Instances and Network resources.
Docker Hub Authentication
To avoid anonymous pull rate limits in Azure (which often result in 429 Too Many Requests or Manifest Unknown errors), you must have:
Docker Hub Account: A registered account at hub.docker.com.
Personal Access Token: A Token generated via Account Settings > Security with Read Only permissions
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
Deployment Manifest
A Docker Compose file is provided through the Vault UI. This file can be used to build a Deployment Manifest file. Save this file as keeper-gateway.yml . An example of a Deployment Manifest is below:
Required Parameters
Parameter
Description
<AZURE_REGION>
The Azure region where your VNet and Target VMs reside.
<GATEWAY_INSTANCE_NAME>
A unique name for this container group in Azure.
<DOCKER_HUB_USERNAME>
Your Docker Hub ID (required for production pull limits).
<DOCKER_HUB_PAT_TOKEN>
The Personal Access Token generated in Docker Hub.
<YOUR_BASE64_CONFIG_STRING>
The configuration string generated from the Keeper Vault when generating a Gateway
<SUBSCRIPTION_ID>
Your 36-character Azure Subscription ID.
We use emptyDir for /dev/shm to meet shared memory requirements without managing external storage. This storage is ephemeral. If you delete or update the ACI deployment, this data is wiped. This is acceptable for the Gateway because it syncs its state and recordings to the Keeper Cloud.
In Azure Container Instances (ACI), seccomp and AppArmor are not used because ACI uses Hyper-V isolation by default.
Deployment
Once the YAML file is prepared, upload the file and execute the following commands via the Azure CLI to start the service.
Create the Container Group
Verify the Service
Logging
Gateway Service Management
In an Azure Container Instance (ACI) environment, management is performed via the Azure CLI or the Azure Portal.
Service Control
Starting the Service Deploying the manifest automatically starts the service. If the container is stopped:
Stopping the Service To temporarily halt the Gateway:
Restarting the Service Required after making configuration changes to the YAML manifest:
Connecting to the Gateway Container
For debugging network connectivity or verifying internal environment variables, you can establish an interactive bash session:
Updating the Gateway
To update your production instance to the latest version:
Pull and Restart: ACI will automatically pull the :latest image tag upon restart if the image policy allows, but the most reliable method is to re-run the creation command:
Debugging & Health Checks
Verbose Logging
If you need to enable debug logs for troubleshooting rotation failures or tunnel issues, add the following to the environmentVariables section of your YAML:
Health Checks
To monitor the operational status of the Gateway for load balancing or automated failover, you can configure Liveness Probes. This ensures Azure automatically restarts the container if the Gateway service becomes unresponsive.
Scaling and High Availability
Before deploying additional containers, you must configure the Gateway for scaling and high availability.
After logging into Keeper Commander, get a list of gateways from this command:
Run the following command for the gateway being configured for scaling:
<GATEWAY_UID> is the UID of the Gateway you are scaling.
<MAX_INSTANCES> is the maximum number of Gateway instances you want to allow.
Example: The following example allows up to 5 Gateway instances to run concurrently:
For further information on gateway scaling and high availability
In Azure ACI, scaling is horizontal. You deploy multiple independent container groups using the exact same GATEWAY_CONFIG
To add a second instance, duplicate your YAML file and rename the container group and the YAML file.
Upload your new YAML file and run the deployment command
Each instance will automatically join the existing pool.
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 Endpoint
Ports Needed
More Info
Keeper Cloudkeepersecurity.[x]
Endpoints:
US: .com
EU: .eu
AU: .com.au
TLS Port 443
Communicates with Keeper Cloud to access target infrastructure via native protocols (e.g., SSH, RDP)
Keeper Routerconnect.keepersecurity.[x]
Endpoints:
US: .com
EU: .eu
AU: .com.au
TLS Port 443
Communicates with Keeper Router to establish secure, real-time WebSocket connections
Keeper Stun/Turn Service
krelay.keepersecurity.[x]
Endpoints:
US: .com
EU: .eu
AU: .com.au
TCP and UDP opened on Port 3478
Outbound access to TCP and UDP ports 49152 through 65535
Facilitates secure and encrypted WebRTC 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.
The Keeper Gateway is able to communicate via LDAPS (port 636) or LDAP (port 389) to your directory.
1. Set up a PAM Directory credential
Keeper Rotation will use the linked admin credential to rotate other accounts in your directory. This account does not need to be a domain admin account, but needs to be able to successfully change passwords for other accounts.
The linked admin credential needs to be in a shared folder that is shared to the KSM application created in the pre-requisites. Only the KSM application needs access to this privileged account, it does not need to be shared with any users.
PAM Directory record
PAM Directory Record Fields
Field
Description
Record Type
PAM Directory
Title
Keeper record title
Hostname or IP Address
IP address, hostname or FQDN of the directory server. Examples: 10.10.10.10, dc01.mydomain.local
Port
636 - LDAPS is required for rotation on Active Directory.
LDAP over port 389 is insecure and should be avoided.
Use SSL
Must be enabled for use with Active Directory
2. Set up a PAM Configuration
Note: You can skip this step if you already have a PAM Configuration set up for this environment.
A PAM Configuration associates an environment with a Keeper Gateway and credentials. If you don't have a PAM Configuration set up yet for this use case, create one.
Field
Description
Title
Configuration name, example: My Active Directory
Environment
Select: Local Network
Gateway
Select the Gateway that has access to your directory server
Application Folder
Select the Shared folder that contains the PAM Directory record
Other fields
Depends on your use case. See the section.
3. Set up PAM User records
KeeperPAM will use the credentials linked from the "PAM Directory" record to rotate other "PAM User" records in your environment. The PAM User credential needs to be saved in a shared folder that is assigned to the secrets manager application. In the example below, the AD user demouser can be rotated.
Example of Active Directory account password rotation
PAM User Record Fields
Field
Description
Record Type
PAM User
Title
Keeper record title, e.g. AD User - demouser
Login
Username of the account being rotated. The format of the username depends on the target system and type of service.
Examples:
demouser
[email protected]
Password
Account password is optional. In most cases, a password rotation will not require the existing password to be present. However there are some scenarios and protocols which may require it.
Distinguished Name
Required for Active Directory and OpenLDAP directories.
The LDAP DN for the user, e.g.
CN=Demo User,CN=Users,DC=lureydemo,DC=local
If you don't know the user's DN, the following PowerShell command can be used to find it:
4. Configure Rotation on the Record
Select the PAM User record, edit the record and open the "Password Rotation Settings".
Any user with edit rights to a PAM User record and enforcement policies allowing rotation has the ability to set up rotation for that record.
PAM User scheduled rotations
The "Rotation" should be of type "General".
The "PAM Resource" field should select the "PAM Directory" credential setup previously.
Select the desired schedule and password complexity.
Upon saving, the rotation button will be enabled and available to rotate on demand, or via the selected schedule.
Troubleshooting
An easy way to test if LDAP is properly configured is to run 'LDP.exe' and test the connection. If this connection succeeds, then Keeper Rotation should also succeed.
Testing and LDAP connection with LDP.exe
Testing with a Self-Signed Cert
For the purpose of testing an Active Directory user account rotation with Keeper, it is necessary to ensure that the LDAPS connection is active and using a valid certificate. If you are just testing and don't have a production certificate, the instructions below provide you with a self-signed cert.
Using a self-signed certificate with AD is only for testing purposes, do not use in production
1
Create a cert
From PowerShell running as an administrator, create a self-signed cert. Note that the subject name and alternate names of the certificate must match with the server hostname. In this example, the primary name is XYZ123.company.local with alternate names company.local and company.
2
Install the cert
This script will locate the cert in the personal section of the certificate manager and copy it into the trusted domains. Replace the company parameter in the first line of this script with the domain in step 1.
3
Restart NTDS
After restarting the NTDS service, the certificate should be installed.
4
Check the connectivity
Run 'LDP.exe' and make sure that you're able to connect to the local domain over port 636 with SSL enabled.
Production LDAPS Certification
For production deployments, KeeperPAM requires LDAPS with a certificate issued by a trusted Certificate Authority (CA).
Refer to the following table for the supported LDAPS certificates:
Certificate Issuer Type
Description
Enterprise Internal Certificate Authority (CA)
Certificates are issued and managed by an internal PKI (such as Microsoft AD CS). This requires centralized certificate lifecycle management and is common in large enterprises, but may be less desirable in environments with many independently administered domains.
Public Certificate Authority (CA)
Certificates are issued by a trusted public Certificate Authority (e.g., DigiCert, GlobalSign, Entrust). This avoids the need for internal PKI infrastructure and is often preferred in environments with multiple domains or decentralized administration.
Server Authentication
The certificate must include the Server Authentication extended key usage to support LDAPS. This is a standard requirement for secure LDAP connections and applies regardless of the issuing CA.
Domain Controller FQDN
The certificate must be issued to the fully qualified domain name (FQDN) of the Domain Controller to prevent TLS validation errors. This may require individual certificates per Domain Controller in multi-DC environments.
Self-signed certificates are supported for testing only and are not recommended for production use.
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:
The following tables provides more details on each configurable fields in the PAM Configuration record regardless of the environment you choose:
Field
Description
Notes
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
AWS Environment
Field
Description
Notes
See additional information on
Azure Environment
Field
Description
Notes
See additional information on
Google Cloud Environment
Coming soon in Q4 2025
Field
Description
Notes
See additional information on
Domain Controller Environment
Field
Description
Required
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
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 9 and it is hosted in .
Gateway on AWS ECS
Instructions for installing Keeper Gateway on an AWS ECS
Overview
This document contains information on how to install, configure, and update your Keeper Gateway on an AWS ECS. The Keeper Gateway container is built upon the base image of Rocky Linux 9 and it is hosted in .
Rotation Overview
Quick start guide to Keeper Password Rotation
Prerequisites
An active license is required in order to use the features available with KeeperPAM. This license is available for both business and enterprise customers.
# Get the cert we just created
$cert = Get-ChildItem -Path "Cert:\LocalMachine\My" | Where-Object {$_.Subject -like "*company*"}
$thumbprint = ($cert.Thumbprint | Out-String).Trim()
# Copy to NTDS through registry
$certStoreLoc = 'HKLM:/Software/Microsoft/Cryptography/Services/NTDS/SystemCertificates/My/Certificates'
if (!(Test-Path $certStoreLoc)) {
New-Item $certStoreLoc -Force
}
Copy-Item -Path HKLM:/Software/Microsoft/SystemCertificates/My/Certificates/$thumbprint -Destination $certStoreLoc
# Copy to Trusted Root store
$rootStore = New-Object System.Security.Cryptography.X509Certificates.X509Store([System.Security.Cryptography.X509Certificates.StoreName]::Root, 'LocalMachine')
$rootStore.Open('ReadWrite')
$rootStore.Add($cert)
$rootStore.Close()
You will be provided with an installation command to paste into your Linux host.
2
Run the Installation Command
On your Linux host, navigate to your desired working directory and execute the copied installation command.
The installation command will:
Install Docker and Docker Compose (if needed)
3
Start the Service
Ensure that you are located in the folder where the docker-compose.yml, docker-seccomp.json and gateway-apparmor-profile files are saved.
Option 2: Manual Docker Installation
If you prefer to set up the Docker environment yourself, follow the instructions below.
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:
The shm_size is a critical parameter. We recommend maximizing this value to at least half of the available server memory. Production gateways should have as much memory and CPU allocated as possible. When using remote browser isolation sessions, Chromium uses a lot of memory for each process.
The only required environment variable setting is GATEWAY_CONFIG which is the resulting base64-encoded configuration provided by Keeper when creating a Gateway.
2
Seccomp File
The file called docker-seccomp.json needs to be downloaded and placed in the same folder as your Docker Compose file.
or:
3
AppArmor Profile (Required for Ubuntu/Debian distributions)
This step is required
4
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:
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:
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
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
Ensure the binary path for ExecStart and ExecStop are correct
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 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:
Enabling this option allows you to establish a Connection to the host. For example, to open an SSH connection:
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:
The Keeper Gateway establishes outbound-only connections and does not require any inbound firewall rules. The following outbound connections must be allowed:
Destination Endpoint
Ports Needed
More Info
Keeper Cloudkeepersecurity.[x]
Endpoints:
US: .com
EU: .eu
AU: .com.au
TLS Port 443
Communicates with Keeper Cloud to access target infrastructure via native protocols (e.g., SSH, RDP)
Keeper Routerconnect.keepersecurity.[x]
Endpoints:
US: .com
EU: .eu
AU: .com.au
TLS Port 443
Communicates with Keeper Router to establish secure, real-time WebSocket connections
Keeper Stun/Turn Service
krelay.keepersecurity.[x]
Endpoints:
US: .com
EU: .eu
AU: .com.au
TCP and UDP opened on Port 3478
Outbound access to TCP and UDP ports 49152 through 65535
Facilitates secure and encrypted WebRTC 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.
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.
Internet Access: The ECS host must have an outbound route to Keeper's endpoints via an Internet Gateway (IGW) or NAT Gateway. See the Gateway Network Configuration page.
Instance Type: You must use an EC2 instance type with at least 8GB of RAM available. See sizing recommendations.
Gateway scaling set to maximum instances: See below and .
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
Download the Docker-compose YAML and save the Base64 configuration token.
AWS Infrastructure Setup
Create the Gateway Security Group
Navigate to EC2 > Security Groups > Create security group.
Choose "Store a new secret": Click the button to start the creation process.
Select Secret Type:
Choose "Other type of secret".
Enter the Secret Value:
Switch to the "Plaintext" tab.
Delete any existing curly braces {} and paste your Base64 Configuration Token.
Encryption Key: Leave this as aws/secretsmanager
Click Next
Configure Secret Metadata:
Secret name: Enter a descriptive name, such as keeper/gateway-config.
Store the Secret: Skip the optional rotation settings and click Store.
Copy the Secret ARN: Once saved, click on your new secret and copy the Secret ARN, we will require this later
Example Format:arn:aws:secretsmanager:us-east-1:012345678901:secret:keeper/gateway-config-abc123
Create IAM Roles
ECS Instance Role
This role allows the EC2 instance to talk to the ECS cluster and enables AWS Systems Manager (SSM) for remote troubleshooting.
Navigate to IAM > Roles > Create role.
Select trusted entity: AWS Service.
Service or use case: EC2.
Add permissions (Attach these 2 Managed Policies):
AmazonEC2ContainerServiceforEC2Role
AmazonSSMManagedInstanceCore
Role name: [INSTANCE_ROLE_NAME] (e.g., ecsInstanceRole).
Create role.
Task Execution Role
This role is used by the ECS Agent to pull the image and decrypt the secret before the app starts
Navigate to IAM > Roles and click Create role.
Trusted entity type: Select AWS service.
Service or use case: Select Elastic Container Service.
Use Case: Search for and check:
AmazonECSTaskExecutionRolePolicy
Click Next.
Role name: e.g ecsgateway-execution-role.
Click Create role.
Add the Inline Policy for Secrets:
Find and click on your new ecsgateway-execution-role.
Click Add permissions > Create inline policy.
Click Review policy, name it KeeperSecretAccess, and click Create policy.
Task Role
This role is used by the application while it's running to manage your AWS resources.
Navigate to IAM > Roles and click Create role.
Trusted entity type: Select AWS service.
Service or use case: Select Elastic Container Service, then Elastic Container Service Task. Click Next.
Add permissions: Click Next (we will add a custom policy instead).
Role name: e.g ecsgateway-task-role. Click Create role.
Add the Inline Policy for Resource Management:
Click on the new ecsgateway-task-role.
Click Add permissions > Create inline policy.
Create the ECS Cluster
Navigate to ECS > Clusters > Create cluster.
Cluster name: [CLUSTER_NAME].
Select Fargate and Self-managed instances
Provisioning method: On demand
Container instance Amazon Machine Image (AMI): Amazon Linux 2023
Instance type: t3.large.
EC2 instance role: Select the ECS instance role you previously created
Desired Capacity: Set minimum 1 and desired maximum
Network settings: Select your VPC, Subnet and Security Group
Create: Click Create
Creating the Task Definition
Open the ECS Console: Navigate to Amazon Elastic Container Service > Task Definitions.
Start Creation: Click Create new task definition and select Create new task definition with JSON
Paste & Edit: Paste the following template. Ensure sizing of CPU and memory meets your needs.
Parameters
Update the sizing to your required Gateway size.
privileged: true: Required for Remote Browser Isolation (RBI). Chromium needs elevated permissions to manage the "sandboxed" browser namespaces.
sharedMemorySize: 2048: Docker only gives 64MB of shared memory; modern web pages require at least 2GB to render without crashing.
secrets block: This maps the GATEWAY_CONFIG environment variable to your AWS Secrets Manager ARN. The ECS agent handles the decryption automatically at runtime.
network Use bridge Mode to allow the container to share the host's networking stack for internal VPC discovery, but if your instances are in a private subnet, ensure your VPC Route Table directs outbound traffic to a NAT Gateway for secure internet connectivity to the Keeper Cloud and use awsvpc in the JSON.
Deploy & Verify
Create the ECS Service
The Service ensures that your Task Definition stays running.
Open the ECS Console: Go to Clusters and select your cluster (e.g., Keeper-Cluster).
Create Service: Under the Services tab, click Create.
Environment Configuration:
Compute options: Select Launch type.
Launch type: Select EC2.
Deployment Configuration:
Family: Select the ecsgatewaytask you created.
Revision: Select the latest revision.
Servicename: keeper-gateway-service.
Desired tasks: Set to 1.
Networking:
Security Group:
If Bridge Mode: Networking settings are inherited from the EC2 host. Skip SG selection in this wizard.
Review and Create: Click Create.
Scaling and High Availability
Before deploying additional containers, you must configure the Gateway for scaling and high availability. Match this to your maximum defined instances in your Cluster configuration.
After logging into Keeper Commander, get a list of gateways from this command:
Run the following command for the gateway being configured for scaling:
<GATEWAY_UID> is the UID of the Gateway you are scaling.
<MAX_INSTANCES> is the maximum number of Gateway instances you want to allow.
Example: The following example allows up to 5 Gateway instances to run concurrently:
For further information on gateway scaling and high availability
The Keeper Gateway establishes outbound-only connections and does not require any inbound firewall rules. The following outbound connections must be allowed:
Destination Endpoint
Ports Needed
More Info
Keeper Cloudkeepersecurity.[x]
Endpoints:
US: .com
EU: .eu
AU: .com.au
TLS Port 443
Communicates with Keeper Cloud to access target infrastructure via native protocols (e.g., SSH, RDP)
Keeper Routerconnect.keepersecurity.[x]
Endpoints:
US: .com
EU: .eu
AU: .com.au
TLS Port 443
Communicates with Keeper Router to establish secure, real-time WebSocket connections
Keeper Stun/Turn Service
krelay.keepersecurity.[x]
Endpoints:
US: .com
EU: .eu
AU: .com.au
TCP and UDP opened on Port 3478
Outbound access to TCP and UDP ports 49152 through 65535
Facilitates secure and encrypted WebRTC 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.
Enforcement policies for KeeperPAM password rotation are managed in the Keeper Admin Console under Admin > Roles > Enforcement Policies > Privileged Access Manager.
KeeperPAM Enforcement Policies
For Password Rotation capabilities, enable the necessary policies:
Enforcement Policy
Commander Enforcement
Definition
Can create applications and manage secrets
Allow users to create a Secrets Manager Application
Can create, deploy and manage Keeper Gateways
Allow users to deploy and manage a Keeper Gateway
Can configure rotation settings
Allow users to set up rotation on a PAM User record
Can configure rotation settings (legacy setting)
Rotation can also be enabled on the Keeper Commander CLI using the enterprise-role command:
Deploy a Keeper Gateway
If you haven't yet created a Keeper Gateway yet, 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). We have also posted a page describing how to create a sandbox environment in just a few steps:
When you use the Gateway using the Create New > Gateway feature, Keeper will automatically create the Secrets Manager Application, Shared Folders and PAM Configuration. In the Secrets Manager section of the vault, you'll see the Application assigned to Shared Folders and also assigned to the Gateway.
Application Setup
Application associated to Gateway
Create a PAM User record
A PAM user record holds a privileged account credential, password or private key. For steps on creating a PAM User, follow this page. The example below shows a PAM User record for an admin password on a Windows server. The PAM User record is added to a Shared Folder containing user accounts.
Creating a PAM User record
Create a PAM Resource
A PAM Resource represents a Machine, Database or Directory.
Create new Machine, Database or Directory
Configure rotation settings
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 .
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, Azure managed resources, and Google Workspace principals. In this case, only the PAM Configuration is required since it contains the necessary credentials.
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, Azure and GCP managed resources, Keeper uses Instance Role permission of the Gateway, or specific PAM Configuration secrets to perform the rotation with APIs.
For Google Cloud managed resources, Keeper uses the Service Account permissions of the Gateway.
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
Record Types for Rotation
The rotation of credentials is restricted to the PAM User record type.
In previous versions of Keeper, rotation was permitted on PAM Machine, PAM Database and PAM Directory records. In the latest version of KeeperPAM, you will be prompted to separate the PAM Resources from the PAM User. See the Record Linking documentation for more info.
When you have activated Keeper Secrets Manager or KeeperPAM, the following new record types will be available to users:
PAM User
Contains a login / password, private key, or both.
PAM Directory
Information about your on-prem or cloud-based directory
PAM Database
Self-hosted or managed cloud-based databases such as MySQL, SQL Server, etc.
PAM Machine
Windows, Linux, macOS machines on-prem or in the cloud
PAM Remote Browser
Remote browser isolation to protect web-based applications
All 5 record types can be added in the Vault, placed in folders, and shared like any other Keeper records.
When rotation is activated, within the Secrets Manager screen of the vault you'll see a section called PAM Configurations. A PAM Configuration is an object which is contains the following:
Environment
Local Network, AWS or Azure
Keeper Gateway
Service which you install into your on-prem or cloud infrastructure
Application Folder
Shared Folder which contains the Secrets Manager application and associated records
Administrative Credentials
Keeper record which contains privileged credentials for performing rotation and discovery.
Customers may have any number of PAM Configurations, Applications and Gateways.
docker compose pull
nohup docker compose up -d keeper-gateway &
df -h
docker image prune -a
WARNING! This will remove all images without at least one container associated to them.
Are you sure you want to continue? [y/N] y
Deleted Images:
...
Total reclaimed space: 4.8GB
pam gateway new -n "<Gateway Name>" -a <Application Name or UID> -c b64
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
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
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
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
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
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
For the most up-to-date list of available plugins and integration examples, regularly check the .
AWS Access Keys - Amazon Web Services credential rotation
Azure Client Secrets - Microsoft Azure application secrets
Cisco IOS XE - Network device management
Cisco Meraki - Cloud-managed networking
Snowflake Account
The account. It’s is the subdomain of the URL.
Yes
REST Method
The HTTP Method to use. The default is POST. Valid values are: POST, PUT.
No
Region Name
Region name. This can be left blank unless GovCloud. A value is required for GovCloud.
No
AWS Clean Keys
Remove old Access Keys. If not set, will default to ‘All’
All - Will remove all the access keys.
Oldest - Will remove the oldest access key if both Access Key slots are filled.
Replace - Will replace the Access Key used in the Vault record. If there are two Access Keys, the other will not be removed.
No
Azure Tenant ID
The Directory (tenant) ID of the Azure Entra ID. This for both the admin and target application.
No
Azure Admin Application ID
The Application (client) ID for the Administrative app which is performing the rotation (NOT the target).
No
Azure Admin Client Secret
This is the Secret value for the administrative application.
No
Azure Authority
Special URL for MSAL to request tokens.
No
Azure Graph Endpoint
Special URL for Azure Graph scope.
No
Azure Clean Keys
Remove old Access Keys upon every rotation.
All - Will remove all the secrets.
Replace - Will replace the secret used in the Vault record.
No
Choose Microsoft Graph
Select Application permissions
Search and select:
Application.ReadWrite.All
Click Add permissions
Then click Grant admin consent for the tenant
Hostname
Hostname or IP of the web service.
Yes
Verify SSL
Verfiy server’s SSL certificate. Default is FALSE.
No
Network ID
The Network ID.
If blank, an attempt will be made to find the network id. If the customer has only one organization, and only one network in that organization, it will use that network id.
No
Verify SSL
Verfiy server’s SSL certificate. Default is FALSE.
No
Monitor rotation logs for failures or authentication issues
Regularly review and update SaaS rotation assignments
Test individual SaaS configurations before associating with multiple users
Enterprise Support: Contact your Keeper representative for assistance with custom integrations
SaaS Type
Okta
Yes
Active
Activate/Deactivate a SaaS rotation. The default is active.
No
Okta URL
The URL to customer login portal. Where users login in.
Yes
Okta Token
The API token created on the Security → API → Tokens admin page.
SaaS Type
Snowflake
Yes
Active
Activate/Deactivate a SaaS rotation. The default is active.
No
Snowflake Admin User
An admin username
Yes
Snowflake Admin Password
The password for the admin username.
SaaS Type
REST
Yes
Active
Activate/Deactivate a SaaS rotation. The default is active.
No
REST Url
URL to the web service.
Yes
REST Token
A header Bearer token. This must be static. It cannot be generated.
SaaS Type
AWS Access Key
Yes
Active
Activate/Deactivate a SaaS rotation. The default is active.
No
AWS Access Key ID for the Administrative role
Admin Access Key ID
No
AWS Secret Access Key for the Administrative role
Admin Secret Access Key
SaaS Type
Azure Client Secret
Yes
Active
Activate/Deactivate a SaaS rotation. The default is active.
No
Azure Target Object ID
The target Azure Entra ID application. This is the object ID of the application which is being rotated.
Yes
Expiry Days
The number of days before the secret expires. Default if 365 days.
SaaS Type
Cisco IOS XE
Yes
Active
Activate/Deactivate a SaaS rotation. The default is active.
No
Admin Username
The administrator’s username.
Yes
Admin Password
The administrator’s password.
SaaS Type
Cisco Meraki
Yes
Active
Activate/Deactivate a SaaS rotation. The default is active.
No
Admin Email
The administrator’s email address
Yes
API Key
The API Key generated in the admin’s profile, in the API access section.
# Login to your vault
keeper shell
# List available SaaS types for your gateway
pam action saas config --gateway "My Gateway" --list
# Create a new SaaS configuration (example for Okta)
pam action saas config --gateway "My Gateway" --plugin "Okta" --shared-folder-uid FOLDER_UID --create
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 provide the following benefits:
Allow load balancers to automatically remove unhealthy instances from rotation and add them back when they recover.
Integrate with monitoring systems (Prometheus, Nagios, Datadog, etc.) to provide automated alerting and dashboards showing gateway health across your infrastructure.
Enable automated monitoring scripts and orchestration tools to detect failures and trigger recovery procedures without human intervention.
The health check service is disabled by default. You must activate it as documented in the next sections.
Simple Health Check Configuration
The below configuration enables a basic health check service on the binary and Docker installation methods. More is also available as documented below.
Activating Health Check - Binary Install method
Start the gateway with health check enabled:
Only after the gateway is running with health check enabled, you can check its health:
If you get an error like "Could not connect to health check server", it means you haven't enabled the health check properly.
If you see "Exception No such command 'keeper-gateway.exe'", you're using the wrong command syntax. Always use "gateway" as the command name.
Activating Health Check - Docker Install method
Modify the docker-compose.yml file to enable health checks:
Add KEEPER_GATEWAY_HEALTH_CHECK_ENABLED
Add the healthcheck section with the desired check intervals
After changing the docker-compose file, pick up the changes and restart the container:
If the container name is keeper-gateway, a one-line bash command to find the service status can be found like this:
If you don't know the container name, this script will give it to you:
Here's an example of checking the health with a bash command:
The below complete bash script can be added to your watchdog services to check service status and automatically restart the container if it's unhealthy. Replace /path/to/ with the proper path.
To schedule this health check on a Linux system, it can be added to the cron
Add to the crontab to watch every minute...
Advanced Healthcheck Configuration Examples
The below section provides detailed configuration for customization of the health checks in different environments.
Configuration
Start Command
CLI Health Check
Curl Health Check
Output Format Examples
Output Format
CLI Command
Description
Troubleshooting Commands
Issue
Test Command
Expected Result
Error Messages and Troubleshooting
The CLI health check provides detailed error messages to help diagnose issues:
Authentication Errors (HTTP 401)
Connection Errors
SSL Certificate Errors
Implementation
The Gateway health check is implemented using , 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
CLI Health Check
You can check the gateway's health from the command line:
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):
For JSON format output (matching the HTTP endpoint format):
If your health check server is using SSL:
If your health check server requires authentication:
If your health check server is running on a non-default port:
If your health check server is running on a different host:
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
Command Line Arguments
When starting the gateway, you can also use these command line arguments:
Command line arguments take precedence over environment variables when both are specified.
Example Commands
Basic health check with default settings:
Custom port and authentication token:
Bind to all interfaces (only in secure environments):
Enable SSL with certificate and key:
Complete example with all options:
Usage
When enabled, the HTTP health check endpoint will be available at:
Or with SSL:
Response Format
The endpoint returns:
HTTP 200 if the gateway is healthy
HTTP 503 if the gateway is not healthy
JSON response with details:
The response includes:
status: Overall health status ("healthy" or "unhealthy")
message: Human-readable description of the status
details: Detailed information about the gateway
Example Responses
Healthy Gateway:
Unhealthy Gateway:
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:
Authentication: When KEEPER_GATEWAY_HEALTH_CHECK_AUTH_TOKEN is set, requests must include the token in the Authorization header:
SSL/TLS: When SSL is enabled, all communication is encrypted. You must provide a valid certificate and private key.
Localhost binding: The server binds to localhost only by default, not exposing the endpoint over the network.
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:
Docker-Specific Configuration Requirements
When running Keeper Gateway inside Docker, special configuration may be 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
Generate a Self-Signed Certificate
Test the Endpoint from the Host
Example Linux Configuration
Or using command line arguments:
Self-Signed SSL Certificates
For testing or internal use, you can generate self-signed certificates to enable SSL/TLS encryption:
Or using command line arguments:
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:
#!/bin/bash
LOGFILE="/path/to/keeper-watchdog.log"
# Find running container matching keeper-gateway
CONTAINER_NAME=$(docker ps --filter "status=running" --format "{{.Names}} {{.Image}}" | grep keeper-gateway | awk '{print $1}')
if [ -z "$CONTAINER_NAME" ]; then
echo "$(date): No running keeper-gateway container found." >> "$LOGFILE"
else
# Get health status
HEALTH=$(docker inspect --format='{{.State.Health.Status}}' "$CONTAINER_NAME")
if [ "$HEALTH" != "healthy" ]; then
echo "$(date): $CONTAINER_NAME is $HEALTH. Restarting..." >> "$LOGFILE"
docker restart "$CONTAINER_NAME"
else
echo "$(date): $CONTAINER_NAME is healthy." >> "$LOGFILE"
fi
fi
# Trim log file to last 100 lines
tail -n 100 "$LOGFILE" > "$LOGFILE.tmp" && mv "$LOGFILE.tmp" "$LOGFILE"
crontab -e
* * * * * /path/to/watchdog.sh
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
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
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
--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
