For the complete documentation index, see llms.txt. This page is also available as Markdown.

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-kms

  • GCP KMS key needs ENCRYPT and DECRYPT permissions.

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/kms is 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-kms package and these permissions

    • Cloud 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)

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.

See the Google documentation for more information on generating keys:

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.

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.

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.

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.

Check out the KSM SDKs documentation for more examples and functionality

Last updated