Advanced Keeper Gateway Configurations
This section will cover additional configurations to modify the Keeper Gateway's default behavior.
The following are supported configurations for the Keeper Gateway:
Storing and protecting the Keeper Gateway Configuration using AWS KMS
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 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.
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.
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.
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.
The EC2 instance role needs to be assigned a policy which provides read access to the specific AWS Secrets Manager key. As an example:
From the EC2 instance, the below command will confirm the policy has been applied:
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:
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:
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.
When setting up Rotation in your Keeper Vault, you store the credentials of your assets involved in rotation on their corresponding PAM Record Types. On these record types, you are able to create custom fields.
The additional gateway configurations will be defined with these custom fields on the PAM Record Types. The Keeper Gateway will then adjust its behavior based on the defined configurations.
The following tables lists all the possible configurations with custom fields:
Shell
Text
None
Allows you to specify a custom shell path that the Gateway will use when executing rotation and post-rotation scripts. This gives you control over the environment in which these scripts run.
Example Value: C:\MY\SHELL
NOOP
Text
False
Allows you to control whether the Gateway performs the primary rotation operation or proceeds directly to execution of the post-rotation script.
If set to True
the Gateway will skip the rotation process and proceed directly in executing the post-rotation script(s).
Example Value: True
Kerberos
Text
False
Specifically designed for WinRM connections using Kerberos authentication.
By default, the Gateway automatically decides whether to use Kerberos based on certain rules, and If these conditions are met, the Gateway will attempt to use Kerberos for WinRM. However, if you encounter issues with this automatic detection, setting this field to True
will override the default behavior and force the Gateway to use Kerberos for WinRM.
Example Value: True
Private Key Type
Text
ssh-rsa
Gateway Version 1.3.4+
This custom field pertains to the type or algorithm of the private key stored in a record.
When adding a private key to a record, users do not need to take any additional action regarding its type or algorithm. The system is designed to automatically recognize and use the same algorithm as the existing private key during the rotation process. If the algorithm in use is ECDSA, the key size will also be preserved during the rotation.
Available Options if needed to overwrite the key type:
ssh-rsa
(Note: 4096 bits)
ssh-dss
(Note: 1024 bit, obsolete) ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
ssh-ed25519
Private Key Rotate
Text
True
Gateway Version 1.3.4+
TRUE
- (Default) If the custom field doesn't exist, the private key will be rotated if it exists.
FALSE
- The private key won't be rotated, even if it exists. Users should pick this if they wish to retain the private key in the record without any rotations.
Note:
The custom fields values are not case-sensitive.