Google Cloud Key Management Encryption
Protect Secrets Manager connection details with Google Cloud Key Management

Keeper Secrets Manager integrates with Google Cloud Key Management in order to provide encryption for Keeper Secrets Manager configuration files. With this integration, you can protect connection details on your machine while taking advantage of Keeper's zero-knowledge encryption of all your secret credentials.
Features
Encrypt and Decrypt your Keeper Secrets Manager configuration files with Google Cloud Key Management.
Protect against unauthorized access to your Secrets Manager connections.
Requires only minor changes to code for immediate protection. Works with all Keeper Secrets Manager SDK functionality.
Prerequisites
To configure Google Cloud Key Management with Keeper Security, you need a service account key file (.json).
Key structure that is supported by this integration is projects/<project_name>/locations/<location_name>/keyRings/<key_ring_name>/cryptoKeys/<key_name>/cryptoKeyVersions/<key_version>
Support the Java/Kotlin Secrets Manager SDK.
Required GCP package
google-cloud-kmsGCP KMS key needs
ENCRYPTandDECRYPTpermissions.
Note: v1.1.0+ requires Node.js 22 or later. Earlier Node.js versions are no longer supported.
Supports the JavaScript Secrets Manager SDK
@google-cloud/kmsis bundled — no separate install required.GCP KMS key needs the following IAM permissions on the service account:
Cloud KMS CryptoKey Encrypter
Cloud KMS CryptoKey Decrypter
Cloud KMS CryptoKey Public Key Viewer (required for asymmetric keys)
Cloud KMS Viewer (provides
cloudkms.cryptoKeys.get, required for key introspection on initialization)
Note: v1.1.0+ requires Python 3.9+. Users on Python 3.6–3.8 should pin to
keeper-secrets-manager-storage-gcp-kms<1.1.0.
Supports the Python Secrets Manager SDK
Requires
google-cloud-kmspackage and these permissionsCloud KMS CryptoKey Encrypter
Cloud KMS CryptoKey Decrypter
Cloud KMS CryptoKey Public Key Viewer
Cloud KMS Viewer (provides
cloudkms.cryptoKeys.get, required for key introspection on initialization)
Supports the .Net Secrets Manager SDK
Requires Google.Apis.CloudKMS.v1
GCP KMS key needs
ENCRYPTandDECRYPTpermissions.
Setup
1. Install Module
Setting up project using Gradle or Maven
Gradle
Maven
The Secrets Manager Google Cloud Key Management module can be installed using npm
The Secrets Manager Google Cloud Key Management module can be installed using pip
The Secrets Manager Google Cloud Key Management module can be installed using dotnet nuget package manager.
2. Configure GCP KMS Connection
To enable secure authentication with Google Cloud Platform (GCP), generate a Service Account key in JSON format. This credential file will serve as the authentication mechanism for interacting with GCP services programmatically.
Python v1.1.0+: The service account must have the Cloud KMS Viewer IAM role (cloudkms.cryptoKeys.get) in addition to the Encrypter/Decrypter roles. Without it, GCPKeyValueStorage raises a permission error on initialization. See the Python Prerequisites tab for the full required role list.
3. Add GCP KMS Storage to Your Code
Once GCP connection has been configured, you can use the GCP KMS integration to encrypt and decrypt the KSM configuration. Tell the Secrets Manager SDK to use GCP KMS as storage.
Using GCP KMS Integration
Once set up, the Secrets Manager GCP KMS integration supports all Secrets Manager SDK functionality. Your code will need to be able to access the GCP KMS keys in order to manage the encryption and decryption of the KSM configuration file. Using Specified Connection credentials
To do this, create GcpKeyValueStorage instance and use this in SecretManagerOptions constructor.
The GcpKeyValueStorage will require the name of the Secrets Manager configuration file , gcp credential file and key details of Cloud Key Management.
To do this, use GCPKeyValueStorage as your Secrets Manager storage in the SecretsManager constructor.
The storage will require an keyConfig , gcpsessionConfig(generated by GCPKSMClient) , and the name of the Secrets Manager configuration file which will be encrypted by GCP Cloud Key Management.
v1.1.0 behavior: A config path that is a symbolic link is now refused on both read and write. A config path with a hard-linked peer is replaced rather than written through on save. Point configPath or KSM_CONFIG_FILE at the real file, not a link. A zero-length config file is also now a hard error on init()/decryptConfig() instead of being treated as an empty config, so an interrupted or truncated write can no longer be silently re-encrypted over.
The config file path is the first non-blank value of these three: the config path argument you pass to GCPKeyValueStorage, the KSM_CONFIG_FILE environment variable, and client-config.json in the current working directory. A blank or whitespace-only value counts as unset.
The config file's directory must be writable, not only the file itself — writes create a temporary file alongside the config file and rename it into place. Config file writes land at file mode 0600 and a newly created config directory at 0700. On Linux and macOS, init() and decryptConfig() also refuse to read a config file that is owned by a user other than the account that runs your application (a root-owned file is accepted), or whose mode allows group or world write access, such as 0664 or 0666. A config file that version 1.0.0 created under a umask of 002 has mode 0664 and now fails, while 0644 passes. The error names the path. Set the file to 0600 and make sure the application account owns it. On Windows, Node.js does not apply POSIX file modes, so these modes have no effect and the config read does not check file ownership or mode. Restrict access to the config directory with Windows ACLs instead. A symbolic link at the config path is still refused on Windows, but the check runs just before the file is opened, so a link swapped in between the two steps is not caught. Anyone who can replace the config file can win that race, so limit who can write to the config directory. A save on Windows fails with an EPERM, EACCES, or EBUSY error if another process holds the config file open at that moment. The existing config file is left intact and the error reaches your code, so retry the save.
Call and await init() once before any other method. Every other public method, including decryptConfig(), rejects with an error that names init() until init() has finished, and an instance whose init() failed stays unusable. init() also rejects, and leaves the file untouched, when the config file holds JSON that is not an object of string values, such as null, an array, a number, or an object with a non-string value. Restore the file from a backup, or delete it to create a new configuration.
To do this, use GCPKeyValueStorage as your Secrets Manager storage in the SecretsManager constructor.
The storage will require gcp_key_config (generated by GCPKeyConfig ), gcp_session_config object (generated by GCPKMSClientConfig ) and the name of the Secrets Manager configuration file which will be encrypted by GCP Cloud Key Management.
To do this, use GCPKeyValueStorage as your Secrets Manager storage in the SecretsManager constructor.
The storage will require an keyConfig (generated by GCPKeyConfig ), gcpSessionConfig object (generated by GCPKMSClient ), and the name of the Secrets Manager configuration file which will be encrypted by GCP Cloud Key Management.
Using Application Default Credentials
If you have configured credentials via gcloud auth application-default login, the GOOGLE_APPLICATION_CREDENTIALS environment variable, or are running on a GCP compute instance with a service account attached, you can omit the credentials file entirely.
Alternatively, you can pass the service account email and private key directly without a file:
If you have configured credentials via gcloud auth application-default login, the GOOGLE_APPLICATION_CREDENTIALS environment variable, or are running on a GCP compute instance with a service account attached, you can omit the credentials file entirely.
ADC + RAW_ENCRYPT_DECRYPT limitation: ADC cannot be used with RAW_ENCRYPT_DECRYPT key types. The raw KMS API path requires an OAuth token that the default client does not expose. Use create_client_from_credentials_file() or create_client_using_credentials() for raw symmetric keys.
Alternatively, you can pass the service account email and private key directly without a file:
Additional Options
Change Key
We can change key that is used for encrypting the KSM configuration, examples below show the code needed to use it
Decrypt Config
You can decrypt the configuration file to migrate to a different cloud provider or to retrieve your raw credentials. Pass true to save the decrypted configuration back to the file, or false to return the plaintext without modifying the file.
Warning: decryptConfig(true) writes the client ID, app key, and device private key to disk in plaintext at the config file's path, replacing the encrypted file. Anything that can read that file, including backups, snapshots, and container image layers, can read those credentials until you re-encrypt it. The write does land at file mode 0600 (owner read/write only), which limits exposure to other local users on the same machine, but the data itself is plaintext on disk.
To return to an encrypted config, construct a new GCPKeyValueStorage against the same path and call .init() on it. loadConfig() detects the plaintext config file and re-encrypts it in place before init() returns. Do not call init() again on the instance that called decryptConfig(true) — that instance does not re-encrypt the file, and the file stays in plaintext.
v1.1.0 change: decrypt_config() called without arguments now defaults to autosave=False (returns plaintext only, does not write to disk). In v1.0.x the default was True, which would overwrite the encrypted config file with plaintext credentials. Always pass the argument explicitly.
You're ready to use the KSM integration 👍
Last updated

