Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Security and encryption model of the Keeper Router
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.
In traditional or legacy privileged access products, the customer is responsible for installing on-prem software which is difficult to manage and configure in a cloud environment. In Keeper's model, a hosted service (called a Gateway) is installed into the customer's environment which establishes an outbound secure connection to the Keeper Router, enabling bi-directional communication to the Keeper cloud without any network configuration. Keeper Router makes cloud access to on-prem infrastructure easy and secure by utilizing WebSockets for the inbound requests.
With Keeper, WebSockets are established between the end-user device (e.g. Web Vault) and the Keeper Router using the user's current session token. The session token is verified by the Keeper Router to authenticate the session. All encrypted payloads sent to the Keeper Router are wrapped by a 256-bit AES transmission key in addition to TLS, to protect against MITM attacks. The transmission key is generated on the end-user device and transferred to the server using ECIES encryption via the Router's public EC key.
When a user on their Web Vault or Desktop App triggers a password rotation, discovery job or remote connection, the message flow is the following:
Upon installation of the Gateway, it authenticates with the Keeper Cloud using a hashed One Time Access Token one time. The client signs the payload and registers a Client Device Public Key with the server on the first authentication. After the first authentication, subsequent requests are sent to the Keeper Router and signed with the Client Device Private Key.
The Gateway establishes an authenticated WebSocket connection using the Client Device Private Key and ECDSA signature.
The Vault sends a message to the Keeper Router with a command to execute (rotation, tunnel, discovery, connection) and authenticates the command using the user's active session token.
The Vault only transmits command and control messages, for example: Rotate UID XXX
. No secret information is communicated between Vault and Router. The Router authenticates the command using the session token of the record's rotation configuration to validate the user's request.
The Router relays the command to the destination gateway through the existing WebSocket connection.
The Gateway retrieves secrets, admin credentials, record details and other private data by using Keeper Secrets Manager APIs. API requests to the Keeper Cloud are sent with a Client Device Identifier and a request body that is signed with the Client Device Private Key. The server checks the ECDSA signature of the request for the given Client Device Identifier using the Client Public Key of the device. The Client Device decrypts the ciphertext response from the server with the Application Private Key, which decrypts the Record Keys and Shared Folder Keys. The Shared Folder Keys decrypt the Record Keys, and the Record Keys decrypt the individual Record secrets.
The Gateway uses Keeper Secrets Manager "update" commands to update the user's vault with any password or discovery job updates.
After a rotation or discovery job is complete, the Gateway informs the Router that the job is complete. ARAM event logs are triggered by the Router.
The Keeper Router architecture is Zero Knowledge, and Keeper's infrastructure never has the ability to access or decrypt any of the customer's stored vault data.
The Router consists of two logical deployments that work together - the Head and the Workers.
The Router is hosted in Keeper’s AWS cloud environment, isolated to each of the global regions (US, EU, CA, AUS, JP, and US Gov).
The Head is not exposed to the internet, and performs the following functions:
Synchronization of global state between Workers
Inter-worker communication
Scheduling of events (e.g. rotation, discovery and connection requests)
The Workers connect to the Head via WebSocket and also use REST API calls to retrieve information. The Workers perform the following functions:
Communication with Gateways
Communication with Keeper end-user applications
Communication with Keeper backend API
Communication with Head
Workers are scaled and load balanced in each Keeper environment. Access to the Keeper Router is established through a common URL pattern in each region:
US: https://connect.keepersecurity.com
EU: https://connect.keepersecurity.eu
AU: https://connect.keepersecurity.com.au
CA: https://connect.keepersecurity.ca
JP: https://connect.keepersecurity.jp
US GOV: https://connect.keepersecurity.us
The end-user device will always communicate through the same Router instance. When the end-user vault connects to the Router system, a communication exchange is performed to ensure that the vault is communicating to the desired gateway. Once the Gateway communication is established, a Cookie is stored locally on the user's browser which expires automatically in 7 days. This Cookie is only used to establish a sticky session with the target Router instance, and does not contain any secret information.
Each Gateway device is associated with a unique UID. The Gateway UID is stored within an encrypted “PAM Configuration” record in the administrator's vault. This way, the Keeper vault record knows which Gateway must be used to perform the requested rotation, discovery or connection features.
Security and encryption model of the Keeper Gateway service
The Keeper Gateway is a service that is installed on-premise in order to execute rotation, discovery and connection tasks. The Keeper Gateway communicates outbound to the Keeper Router using WebSockets and Keeper Secrets Manager zero-knowledge protocols.
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.
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.
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.
The Docker installation method passes in the configuration through an environment variable in the Docker Compose file.
If Gateway is started as a user:
Config file: ~/.keeper/gateway-config.json
Logs folder: ~/.keeper/log
If Gateway is running as a service:
User: keeper-gateway-service
Config file: /etc/keeper-gateway/gateway-config.json
Logs folder: /var/log/keeper-gateway
If the Gateway is started via Command Line
Logs location: C:\Users\[USER NAME]\.keeper\logs\
Config File location: C:\Users\[USER NAME]\.keeper\gateway-config.json
If Gateway is started as a Windows Service
Logs location: C:\ProgramData\KeeperGateway\
Config File location: C:\ProgramData\KeeperGatewayPrivate\
Note: This folder can only be accessed by the user who installed the Gateway Service.
Access to the KSM configuration file allows a user to retrieve any associated secrets from Keeper. To prevent unauthorized access, this configuration file is only readable by the installing user and administrative accounts. On a Windows server, the Windows System account is used to run the service by default, and also has access to the KSM configuration.
In AWS environments, the configuration can be protected with the AWS KMS.
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 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.
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.
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.
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.
Security and encryption model of Connections and Tunnels
KeeperPAM provides the capability to establish cloud and on-prem privileged sessions, create tunnels, establish direct infrastructure access and secure remote database access.
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.
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.
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.
Features included with the PAM License
In order to enable and use KeeperPAM, the following are required:
Keeper Business or Keeper Enterprise License
Privileged Access Manager Add-On
A minimum of 5 seats
A Keeper Business or Keeper Enterprise License is required to purchase the KeeperPAM add-on.
If you are not a Keeper customer or do not have the required license, you can start a free enterprise license trial. The enterprise trial will also include the Privileged Access Manager Add-on.
With the purchase of the Privileged Access Manager add-on, the following features are included:
Secrets Manager - Unlimited API Calls
Password Rotation
Connections
Tunnels
Remote Browser Isolation
Session Recordings and Playback
Discovery
Keeper Connection Manager (Self-Hosted)
PAM Audit and Reporting
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.
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:
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
For example, if an organization has 100 Enterprise users and needs PAM functionality for only 10 of them, they would purchase:
100 Keeper Enterprise Licenses for users who only need the enterprise features.
10 Privileged Access Manager Add-Ons, to cover the 10 users that need PAM functionality.
Features available with the KeeperPAM Add-On are listed here.
For existing customers, the following existing Add-ons can be upgraded to the Privileged Access Manager Add-On:
Keeper Secrets Manager Add-On
Keeper Connection Manager Add-On
Both the Keeper Secrets Manager and Keeper Connection Manager Add-Ons are included as part of the Privileged Access Manager Add-On.
Upgrading 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 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.
To purchase, upgrade, or if you have any questions, contact your Keeper account manager or use our online form.
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Technical details on the KeeperPAM platform architecture
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:
Quickly and easily get started with a pre-configured PAM setup in your vault
To learn some KeeperPAM basics, we have created a wizard that is integrated into the Vault Preview. If you select the Docker install method, this wizard will create all the necessary vault records, configurations and a customized Docker Compose file for quickly standing up a sandbox environment.
Login to the Keeper Vault Preview version. If the policies are active, you'll see a Secrets Manager tab on the left side.
Click on Create New > Gateway
Enter a name for the project, such as "My Infrastructure Demo"
Select Docker for the gateway
Select "Create with example records"
Click Next
After the wizard is finished, immediately download the provided docker-compose.yml
and docker-seccomp.json
files.
Set up a Linux VM in any target environment which supports Docker, such as an Amazon Linux 2 instance or similar.
If necessary, Install Docker per the Docker installation instructions.
Transfer the 2 files from Step 2 to any Linux instance.
Run "docker-compose up" from the folder where the files are saved.
The wizard will create the following in your vault:
A folder containing Resources and Users in separate shared folders
A MySQL database
A Linux machine with VNC connection to the desktop UI
A Linux machine with SSH connection using an SSH Key
A Linux machine with SSH connection using a password
A Linux machine with RDP connection to the desktop UI
A Remote Browser Isolation session to bing.com
A Secrets Manager Application and PAM Configuration with all PAM features enabled
A Keeper Gateway ready to initialize
Below are screenshots of the Quick Start Wizard from start to finish.
KeeperPAM is a modern, cloud-based Privileged Access Manager
KeeperPAM is a next-gen privileged access management solution that secures and manages access to critical resources, including servers, web apps, databases and workloads.
KeeperPAM consolidates enterprise password management, secrets management, connection management, zero-trust network access, remote browser isolation and an cloud-based access control plane in one unified product.
To learn more about KeeperPAM or sign up for a trial:
This documentation is broken out into 3 sections:
Additional documentation on the Keeper platform can be found here:
KeeperPAM is a cloud-native privileged access solution that requires only a lightweight gateway installation, while Keeper Connection Manager (KCM) is a fully self-hosted solution.
KeeperPAM works through outbound-only connections with zero-knowledge encryption, eliminating the need for inbound firewall rules or direct line-of-sight to resources. In contrast, KCM is fully hosted by the customer with control over the authentication, database, web server, reverse proxy and session recordings.
In summary, KeeperPAM is designed for organizations embracing cloud transformation and zero-trust security, while KCM serves specialized use cases requiring full infrastructure control, such as classified environments or those with specific compliance requirements like PIV/CAC authentication.
Several new and exciting capabilities of KeeperPAM are now available in Preview:
Zero-trust connections launched from the Vault
Tunnels established from the Desktop App for ZTNA
Sharing connections without exposing credentials
Sharing tunnels on a time-limited basis
Built-in SSH Agent for use with and without tunneling
Launching remote browser isolation sessions
Session recording and playback
File transfer with drag-and-drop
Splitting credentials between PAM Resources and PAM Users
Discovery of resources
All new Keeper Gateway setup wizard
Docker-based deployment of the Keeper Gateway
Role-based enforcement policies covering PAM use cases
Event reporting of all PAM activity with SIEM integration
Unified with the Keeper Vault: Keeper PAM features integrates directly with the Keeper Vault, offering a centralized, secure platform for managing credentials, connections, and privileged access.
Zero-Knowledge Security: Built on a zero-knowledge architecture, KeeperPAM ensures that only the end user can access their data, with no visibility or access for Keeper itself.
Agentless Deployment: With a simplified setup process, KeeperPAM requires only the deployment of a single gateway in each target environment, using agentless protocols to manage infrastructure.
Credential-less Sharing: Users can securely share access to connections without exposing passwords, enhancing both security and usability
Before jumping into the KeeperPAM advanced capabilities, we require that you first set up your Keeper Enterprise or Keeper MSP license and set up your basic environment.
Check out the Keeper Enterprise documentation
Deploy the Keeper Vault to your employees
If you are an existing customer, your customer success team can activate KeeperPAM in your account.
For technical questions during the Preview period, you can also email pam@keepersecurity.com which routes to our engineers.
Learn about the new KeeperPAM Preview
Launch the Quick Start: Sandbox
Deep dive into the Getting Started guide for KeeperPAM
Accessing the new KeeperPAM platform in Preview
The KeeperPAM Preview offers customers early access to test and prepare for the upcoming official launch. During the preview period, we are releasing weekly updates that include bug fixes, performance improvements, and new features.
Preview features are accessed using the links below.
Mac (.dmg) - Download
Mac (.pkg) - Download
Windows (.appx) - Download
Windows (.msix) - Download
Windows (.msi) - Download
Linux (.rpm) - Download
Linux (.deb) - Download
Note: the Desktop App preview does not auto-update. On Windows computers, a new version of the preview version requires a full uninstall and re-install of Keeper. This does not affect stored data.
GOV: Not available for preview, use commercial environment
Follow the below steps to start using the new KeeperPAM Preview.
If you are not a Keeper customer or do not have the required license, you can start a free trial from our website.
From the Admin Console Preview, ensure that your Keeper Secrets Manager subscription is active. If you have never started a trial of Secrets Manager, you can click on Start Free Trial from the "Secrets Manager" tab.
From the Admin Console Preview, enable the corresponding PAM Enforcement Policies.
Login to the Admin Console Preview for your region.
Under Admin > Roles, create a new role for PAM or modify an existing role
Go to Enforcement Policies and open the "Privileged Access Manager" section.
Enable all the PAM enforcement policies to use the new features.
Assign yourself or your test user account to this role.
This assumes you are an existing customer with Keeper Secrets Manager and you have a Gateway already deployed for testing. The Preview version of the Keeper Gateway is required to support the new features. Depending on the operating system, features available will differ.
Download the new installer preview version: 64-bit Installer (preferred) or 32-bit Installer
You'll be asked to confirm uninstalling the previous Gateway, this is OK
Ensure the "Enter one-time access token" selection is NOT selected
To update an existing Gateway on Linux:
Use the basic docker-compose.yml
file as shown below:
If you are replacing an existing Gateway, you can pull the old base64 configuration string from /etc/keeper-gateway/gateway-config.json
on Linux or C:\ProgramData\KeeperGateway\config\gateway-config.json
on Windows.
Download the file called docker-seccomp.json
and place it in the same folder as your Docker Compose file.
If you have never set up a Keeper Gateway, please follow the step by step guide in the Getting Started section of this documentation. A new Quick Start Wizard is available to instantly create a sandbox for testing out a few of the connection types.
PAM Features differ between Linux, Docker and Windows versions of the Keeper Gateway.
For a full range of features, use the Docker installation method, or Linux installation method on Rocky Linux or RHEL8.
We recommend setting up a Keeper Gateway using the new Quick Start Sandbox. This provides a customized Docker Compose file that provides an instant sandbox for testing.
Please email us at pam@keepersecurity.com with your feedback and we'll assist you with any questions or 1:1 configuration help.
Setting up a basic Remote Browser Isolation record for protecting web-based applications
KeeperPAM remote browser records ensure safe access to internal and cloud apps via a protected browser inside the vault. This browser is shown from the Keeper Gateway to the Keeper Vault, isolating the session for zero-trust access.
This quick guide extends the sandbox that you created in the Quick Start Wizard to add a remote browser isolation resource in the vault.
Below are screenshots of the Remote Browser Isolation setup from start to finish.
Getting Started with KeeperPAM fundamentals
Keeper Password Rotation architecture diagram and data flow
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.
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.
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.
The Keeper Relay is infrastructure in Keeper's cloud that is responsible for establishing encrypted WebRTC connections between the end-user vault interface and the customer-hosted Keeper Gateway service.
Keeper's Backend API is the endpoint which all Keeper client applications communicate with. Client applications encrypt data locally and transmit encrypted ciphertext to the API in a Protocol Buffer format.
Keeper hosted infrastructure that manages timing and logistics around scheduled rotation of credentials across the target infrastructure.
The Management console used to set and enforce policies across all Keeper components.
The end-user interface for managing the vault, rotating passwords, running discovery jobs, creating connections and managing tunnels.
Keeper user performs action (rotation, connection, tunneling, discovery) from the Vault interface, Admin Console, Commander CLI or other endpoint application.
Keeper Gateway establishes an outbound WebSocket connection to the Keeper Router, receives the requests to perform the action.
The Vault Client application establishes a WebRTC connection to the customer's hosted Keeper Gateway.
The Keeper Gateway pulls the necessary secrets from the vault using Keeper Secrets Manager APIs.
The Keeper Gateway performs the action on the target infrastructure (such as rotating a credential) 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 receive push notifications indicating that new data is available for syncing.
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.
Security and encryption model of the Keeper Vault
Keeper's platform is built with End-to-End Encryption (E2EE) across all devices and endpoints.
Data stored in the platform is encrypted locally and encrypted in transit between the user's devices
Information exchanged between Keeper users is encrypted from vault-to-vault
Data at rest is encrypted with multiple layers, starting with AES-256 encryption at the record level
Data in transit is encrypted with TLS and additional layers of transmission encryption which protects against access MITM, service providers and untrusted networks.
A full and detailed disclosure of all encryption related to data at rest, data in transit, cloud architecture and certifications can be found on the Keeper Enterprise Encryption Model page.
A video covering this model is below.
Secrets Manager Applications with KeeperPAM
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.
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
When creating an application, a one-time access token for the first Device is provided. This one-time access token is supplied to the 3rd party system, Keeper Secrets Manager SDK, Keeper Secrets Manager CLI or other device which needs to access information from the vault.
After creating the application, it is managed from the Secrets Manager screen. You can then assign additional devices or Keeper Gateways.
Applications can be added to new or existing Shared Folders.
Edit the Shared Folder to assign the application.
By assigning the Application to shared folders, the application's devices can send Keeper Secrets Manager API requests to the Keeper vault to access and manage the records assigned. There are many use cases where a device can use Keeper Secrets Manager APIs to communicate with the Keeper vault. Below are a few examples.
Keeper Gateways are created and associated to an application. To create a new Gateway, open the application and click on the "Gateways" tab. Select "Provision Gateway" to create a Gateway.
Alternatively, Keeper provides a wizard that creates several components at once, and automatically links everything together. From the main vault screen, select "Create New" then "Gateway".
The "Project Name" is used to create a PAM Configuration, Gateway, Application and optionally a set of example folders and records.
Role-based enforcement policy settings for KeeperPAM
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.
From the Admin Console Preview, enable the corresponding PAM Enforcement Policies.
Login to the Admin Console Preview for your region.
Under Admin > Roles, create a new role for PAM or modify an existing role.
Go to Enforcement Policies and open the "Privileged Access Manager" section.
Enable all the PAM enforcement policies to use the new features.
Can create applications and manage secrets
Allow users to create and manage KSM application
Can create, deploy, and manage Keeper Gateways
Allow users to create, setup, and manage Keeper Gateways
Can configure rotation settings
Allow users to configure Rotation settings on PAM User and PAM Configuration Record Types
Can rotate credentials
Allow users to rotate credentials on PAM User Record Types
Can configure connection and session recording
Allow users to configure Connection and Session Recordings settings on PAM Machine, PAM Directory, PAM Database and PAM Configuration Record Types
Can launch connections
Allow users to launch connections on PAM Machine, PAM Directory, PAM Database Record Types
Can view session recordings
Allow users to view Session Recordings
Can configure tunnel settings
Allow users to configure Tunnel settings on PAM Machine, PAM Directory, PAM Database and PAM Configuration Record Types
Can start tunnels
Allow users to start tunnels on PAM Machine, PAM Directory, PAM Database Record Types
Can configure remote browsing and session recording
Allow users to configure Remote Browser and Session Recordings settings on PAM Remote Browsing and Configuration Record Types
Can launch remote browsing
Allow users to launch remote browsing on PAM Remote Browsing Record Types
Can view RBI session recordings
Allow users to view RBI Session Recordings
Discovery is currently only available on Keeper Commander. The UI is coming soon.
Can run discovery
Allow users to run discovery
These policies are not required moving forward, but they exist for support of legacy features.
Legacy allow rotation
Allow users to perform password rotation
The Keeper Commander CLI enterprise-role
command can be used to set these policies through automation. The list of policies related to PAM functionality is listed below.
Keeper Secrets Manager Devices with KeeperPAM
A Device can be any machine, application or endpoint that has the ability to communicate with the Keeper platform, authenticate and decrypt data that has been provisioned.
Applications have any number of devices associated. Each device has a unique identifier so that it can be tightly controlled and managed. Devices authenticate and decrypt data using a API and encryption model as defined in the Keeper Secrets Manager Security & Encryption model page.
See the Security & Encryption Model of a Device
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".
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.
The One-Time Access Token is an encryption key used by a device for only one authentication to the cloud. After that, a local configuration is created with all of the necessary keys for subsequent authentications and decryption of the resulting vault ciphertext. The Keeper Secrets Manager SDKs and many out of the box integrations utilize this method.
One additional feature of this method is that you can optionally lock down API requests to a specific IP address. The IP address allowed to transact is based on the IP as seen by Keeper's cloud infrastructure.
The Configuration file method of creating a device is useful for tools and integrations where all of the secrets need to be provided at runtime. Most of the CI/CD integration methods use this pre-built configuration file.
For more information about the contents of a Keeper Secrets Manager configuration:
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
secrets-manager client add --app [APP NAME OR UID] --unlock-ip
Options:
--name [CLIENT NAME] : Name of the client (Default: Random 10 characters string)
--first-access-expires-in-min [MIN] : First time access expiration (Default 60, Max 1440)
--access-expire-in-min [MIN] : Client access expiration (Default: no expiration)
--unlock-ip : Does not lock IP address to first requesting device
--count [NUM] : Number of tokens to generate (Default: 1)
--config-init [json, b64 or k8s] : Initialize configuration string from a one-time token
Example:
See more details on the secrets-manager Commander CLI command
KeeperPAM migration of records to new linked format
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.
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.
Understanding the Keeper Vault structure and organization for KeeperPAM
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.
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.
In the vault, records are placed into folders and shared folders. A typical and recommended setup looks something like this:
Private Folder
Shared Folder containing Resources
Shared Folder containing User accounts
The reason that we recommend splitting up Resources and User accounts is based on least privilege. In this configuration, the resources can be provisioned to a user without sharing access to the underlying credentials. The user accounts are in a separate folder and can remain private in this vault or shared to other privileged users as required.
A resource such as a Linux machine can be seen inside the resource folder below. The Administrative Credentials used for connecting to that resource are linked, but not directly embedded in the resource. This way, you can provide access to the resource without sharing the credential.
In this example, the linked Administrative Credential lives in the Users folder with separate permissions and folder privileges.
At the Shared Folder level, both human users and applications can be assigned with access rights. This allows least privilege enforcement across employees and machines.
The fastest way to understand the relationship between records, folders, applications and configurations is using the Quick Start Wizard. This wizard instantly creates a sandbox environment where you can work with the different resources and vault records.
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:
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:
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.
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:
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:
Windows, Linux, macOS devices, VMs, EC2 instances, Azure VMs, Network devices and other operating systems.
MySQL, PostgreSQL, SQL Server, MongoDB, MariaDB, Oracle
Active Directory, Azure AD, OpenLDAP
Web-based Applications, self-hosted apps, cloud apps, any http or https target.
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:
Now that you understand the basic structure of the vault, activating and utilizing PAM features is described in the below sections.
Instructions for installing Keeper Gateway on Windows
This document contains information on how to install, configure, and update the Keeper Gateway on Windows.
The default installation location is the following:
We recommend that the Keeper Gateway is installed as a service.
After selecting the installation location, you will be prompted with the following:
Setup Options Details:
Install Windows service - Installs the gateway as a window service
Start Windows service - if checked, start the Keeper Gateway service immediately after installation
If "Use service account" is specified you will be prompted to enter the valid credentials of the desired service account:
After clicking "Next", click "Install" in the prompted screen to successfully install the Keeper Gateway.
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"
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:
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:
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
To upgrade, stop the service, install the latest version and then start the service.
Back up your gateway-config.json
configuration file
Uninstall Keeper Gateway from "Add and remove programs"
Install Keeper Gateway (do not select "Enter a Keeper One-Time Access Token")
Configure your Keeper Gateway installation to automatically check for updates, ensuring it stays up-to-date with the latest version.
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 generated for your Keeper Gateway installation.
Existing Configuration: If you have previously installed Keeper Gateway and wish to use the existing configuration, you can bypass the token entry by using:
The following other options may be used:
Installation Log File: To generate a log file during the installation process, use the following option and specify the desired log file path:
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.
To enable the Auto Updater feature, allowing Keeper Gateway to automatically check for and apply updates, use the following option:
To uninstall the service:
Uninstall Keeper Gateway from "Add and remove programs"
If desired, delete the private configuration .json file
Installation and setup of the Keeper Gateway
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.
The Keeper Gateway offers different feature capabilities based on the underlying operating system and hardware. We recommend using Docker on a Linux or Windows host with x86 CPUs for full feature support and ease of management.
Note: EL9 which includes Rocky Linux 9 and RHEL 9 support is coming soon.
For optimal performance, we recommend a minimum of 2 CPUs, 2GB of RAM, and 500MB of disk space for any Keeper Gateway device. However, actual system requirements vary based on the number of simultaneous user sessions and the types of connections being established. As the volume of simultaneous connections grows, scaling CPU and memory resources becomes essential. In particular, remote browser isolation (RBI) launches a headless Chromium instance for each session. If you anticipate a high number of RBI sessions, ensure the system is scaled to meet these demands.
The Gateway only establishes outbound-only connections to the Keeper cloud over TLS port 443, and communicates to target infrastructure through native protocols (SSH, RDP, etc).
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 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.
Click on Secrets Manager on the left side
Create a new Secrets Manager Application or select existing application
Click on the "Gateways" tab and click "Provision Gateway"
Select Docker, Linux or Windows install method
Install the Keeper Gateway using the provided method
During the creating of a Keeper Gateway using a one-time token method for Linux and Windows, you have the choice to select "Lock external WAN IP Address of device for initial request". This will additionally IP lock the Gateway in addition to the authentication and encryption built into the service.
Based on your Operating System, refer to the corresponding guide on installing the Keeper Gateway:
Creating a Keeper Gateway
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.
A new Gateway deployment can be created by clicking on Create New > Gateway from the . We have also posted a page describing how to create a sandbox environment in just a few steps.
In the Keeper Web Vault or Desktop App user interface of the Preview version, create a Shared Folder. This Shared Folder will contain the PAM resource records.
Navigate to the "Secret Managers" tab on the left and click on "Create Application" to create a KSM application
In the prompted window:
Enter the name of your KSM application
Choose the Shared Folder
Set the Record Permissions for Application to "Can Edit"
Click on "Generate Access Token" and then click on "OK"
You can safely ignore the first One-Time Access Token generated for the newly created KSM application. When creating a Keeper Gateway device, a different One-Time Access Token will be created.
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
Instructions for installing Keeper Gateway on Docker
This document contains information on how to install, configure, and update your Keeper Gateway on Docker. The Docker container is built upon the base image of Rocky Linux 8 and it is hosted in .
For full PAM capabilities, use a Linux host with a x86 AMD processor.
A Linux host with a x86 AMD processor
Docker and Docker Compose installed
Note: your install may use "docker compose
" or "docker-compose
"
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
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 only required environment variable setting is GATEWAY_CONFIG which is the resulting base64-encoded configuration provided when creating a Gateway device.
When running the Preview version of the Keeper Gateway, you'll see the output in the logs like below:
On the Vault UI in the Secrets Manager > Applications > Gateways screen, the Gateway will show Online.
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 debug is enabled, restart the service with docker compose restart
Executing the following command will update the Keeper Gateway container to the latest Preview and restart the service:
Adding the "restart" 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 .service
file in /etc/systemd/system/keeper-gateway.service
NOTE:
Replace /home/ec2-user
with the path to your docker-compose.yml
Replace ec2-user
user with your user running Docker
Replace docker
group with your defined group
Then enable the service:
Instructions for installing and configuring the Auto Updater for the Keeper Gateway.
Automatic updates of the Keeper Gateway can be enabled on Linux and Windows installations through Keeper's Auto Updater feature. The Auto Updater makes periodic checks to update your Keeper Gateway to the latest version.
By default, the Auto Updater is disabled when installing the Keeper Gateway
We recommend enabling the Auto Updater to ensure you receive the most recent security and functionality enhancements. The Auto Updater verifies all Keeper Gateway downloads by checking the GPG signature of hash value, which are then utilized to checksum each file.
Ensure that you have administrative privileges on the system.
Version 1.4.0 or later of Keeper Gateway is required.
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:
Replace /path/to/your/docker-compose-directory
with the directory containing your docker-compose.yml
.
The set -e
ensures the script exits if any command fails.
Make the script executable:
Edit the crontab:
Add a line to schedule the script. For example, to run it every day at 3 AM:
Execute the following command to download and run the KeeperPAM Preview installer with auto update enabled.
The --autoupdate
parameter activates the auto updater in addition to the 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:
Download and run the latest version of the Gateway installer.
During installation, check the box "Enable automatic updates".
This setup option will create a new Task Scheduler task for updating the Gateway.
Existing Gateway
Open a command prompt as Administrator.
Install Auto Updater with the following Keeper Gateway command:
Verify Installation (Optional)
Open a command prompt as Administrator.
Verify that Auto Updater has been installed successfully by executing the following Keeper Gateway command:
Ensure that you have administrative privileges on the system.
Version 1.4.0 or later of Keeper Gateway is required.
Check the Auto Updater status by executing the following Keeper Gateway command:
Open a command prompt as Administrator
Check the Auto Updater status by executing the following Keeper Gateway command:
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.
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.
Ensure that you have administrative privileges on the system.
Version 1.4.0 or later of Keeper Gateway is required.
Remove Auto Updater by executing the following Keeper Gateway command:
Remove Auto Updater with the following steps:
Open a command prompt as Administrator.
Remove Auto Updater with the following Keeper Gateway command:
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.
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.
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.
Instructions for installing Keeper Gateway on Linux
This document contains information on how to install, configure, and update your Keeper Gateway on Linux.
For full capabilities, use Rocky Linux 8, RHEL 8 or Alma Linux 8.
Executing the following command will install the Keeper Gateway Preview version, and run it as a service:
Replace XXXXX with the One-Time Access Token provided from creating the Keeper Gateway
The gateway will be installed in the following location:
An alias gateway
is also created in the same directory
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.
The following commands can be executed to start, restart, or stop the Keeper Gateway as a service:
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:
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:
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
Executing the following command will upgrade the Keeper Gateway preview to the latest version:
Configure your Keeper Gateway installation to automatically check for updates, ensuring it stays up-to-date with the latest version.
Executing the following command will uninstall the Keeper Gateway preview version:
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 will be a that MSPs can add or remove at any time for their Managed Companies.
Prior to proceeding with this document, make sure you .
Download the new installer preview version: or
Upon installation of the service, select "Enter a Keeper One-Time Access Token" and supply the token provided by when you on the Vault. After installation, the service will automatically start up and register with the Keeper cloud.
Use service account - If checked, use the , otherwise the account installing the gateway will be used
Turn on debug logging - Enable on the gateway log files
The final step prior to successfully installing the Keeper Gateway as service is to enter the Token:
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 .
Login to the Keeper Web Vault or Desktop App ( Required)
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 .
A new Gateway deployment can be created by clicking on Create New > Gateway from the .
DockerHub listing:
Quick reference for
Prior to proceeding with this document, make sure you .
If you cannot use one of these Linux flavors, please install using the
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 .