GCP KSM
Keeper Secrets Manager integrates with GCP KMS in order to provide protection 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 GCP KMS
- Protect against unauthorized access to your Secrets Manager connections
- Requires only minor changes to code for immediate protection. Works with all Keeper Secrets Manager Python SDK functionality
Prerequisites
- Supports the Python Secrets Manager SDK
- Requires
google-cloud-kmspackage - These are permissions required for service account:
- Cloud KMS CryptoKey Decrypter
- Cloud KMS CryptoKey Encrypter
- Cloud KMS CryptoKey Public Key Viewer
- Cloud KMS Viewer (provides
cloudkms.cryptoKeys.get, required for key introspection on init)
Setup
- Install KSM Storage Module
The Secrets Manager GCP KSM module can be installed using pip
pip3 install keeper-secrets-manager-storage-gcp-kms
Note: v1.1.0+ requires Python 3.9.2+ (effective floor;
cryptography>=46.0.5excludes 3.9.0 and 3.9.1). Users on Python 3.6–3.8 should pin tokeeper-secrets-manager-storage-gcp-kms<1.1.0.
- Configure GCP Connection
By default the google-cloud-kms library will utilize the default connection session setup with the GCP CLI with the gcloud auth command. If you would like to specify the connection details, the two configuration files located at ~/.config/gcloud/configurations/config_default and ~/.config/gcloud/legacy_credentials//adc.json can be manually edited.
See the GCP documentation for more information on setting up an GCP session: https://cloud.google.com/sdk/gcloud/reference/auth
Alternatively, configuration variables can be provided explicitly as a service account file using the GcpSessionConfig data class and providing a path to the service account json file.
You will need a GCP service account to use the GCP KMS integration.
For more information on GCP service accounts see the GCP documentation: https://cloud.google.com/iam/docs/service-accounts
- Add GCP KMS Storage to Your Code
Now that the GCP connection has been configured, you need to tell the Secrets Manager SDK to utilize the KMS as storage.
To do this, use GcpKmsKeyvalueStorage as your Secrets Manager storage in the SecretsManager constructor.
The storage will require a GCP Key ID, as well as the name of the Secrets Manager configuration file which will be encrypted by GCP KMS.
from keeper_secrets_manager_storage_gcp_kms import GCPKeyConfig, GCPKeyValueStorage, GCPKMSClientConfig
from keeper_secrets_manager_core import SecretsManager
# example key : projects/<project>/locations/<location>/keyRings/<key>/cryptoKeys/<key_name>/cryptoKeyVersions/<key_version>
gcp_key_config_1 = GCPKeyConfig("<key_resource_uri_1>")
gcp_key_config_2 = GCPKeyConfig("<key_resource_uri_1>")
gcp_session_config = GCPKMSClientConfig().create_client_from_credentials_file('<gcp_credentials_config_file_location.json>')
config_path = "<ksm_config.json>"
one_time_token = "<token>"
storage = GCPKeyValueStorage(config_path, gcp_key_config_1, gcp_session_config)
storage.change_key(gcp_key_config_2) # if we want to change the key
secrets_manager = SecretsManager(token=one_time_token,config=storage)
all_records = secrets_manager.get_secrets()
print(storage.decrypt_config(False))
first_record = all_records[0]
print(first_record)
You're ready to use the KSM integration 👍 Using the GCP KMS Integration
Once setup, the Secrets Manager GCP KMS integration supports all Secrets Manager Python SDK functionality. Your code will need to be able to access the GCP KMS APIs in order to manage the decryption of the configuration file when run.
Change Log
1.1.0
Requirements:
- Minimum Python version raised to 3.9.2 (effective floor;
cryptography>=46.0.5excludes 3.9.0 and 3.9.1 — users on exactly those patch versions will hit a pip resolver error); users on Python 3.6–3.8 should pin to<1.1.0 - Minimum
keeper-secrets-manager-coredependency raised to 17.2.1
Security:
- Fixed CVE-2026-0994: upgraded
protobufto ≥6.33.5 (JSON recursion DoS) - Fixed CVE-2026-26007: upgraded
cryptographyto ≥46.0.5 (subgroup attack) - Fixed AES-GCM nonce from 128-bit (PyCryptodome default) to 96-bit per NIST SP 800-38D; existing encrypted blobs remain readable
- Replaced MD5 with SHA-256 for config change detection
Bug fixes:
GCPKeyValueStoragenow raises on init whencloudkms.cryptoKeys.getis denied, instead of proceeding with the config file left unencrypted on disk- KMS errors (permission denials, network failures, decryption failures) now propagate as exceptions instead of being silently swallowed or reported as misleading JSON parse errors
decrypt_config()no longer writes plaintext credentials to disk when called without arguments (autosavedefault changed fromTruetoFalse)read_storage()now returns a copy; mutations to the returned dict no longer silently corrupt internal statedelete()of the last config key now persists correctly to diskdelete_all()now removes the config file from disk; previously it attempted to re-encrypt an empty config, leaving credentials readable if KMS was unavailableset()now propagatesPermissionErrorwhen the config file is read-only, preventing silent in-memory/on-disk state divergencechange_key()rolls back cleanly on failure; a failed rotation no longer leaves the storage in an inconsistent stateGCPKeyValueStorageis now thread-safe for concurrentset(),delete(),change_key(), anddecrypt_config()calls (KSM-946)key_versiononGCPKeyConfigapplies only to encrypt and asymmetric operations; symmetricclient.decryptuses the unversioned CryptoKey name as required by the GCP API (the server selects the version from the ciphertext envelope)load_config()now always leavesself.configas a dict (neverNone) after parsing a plaintext{}bootstrap config; previously every subsequentread/set/deletecrashed withTypeError: 'NoneType' object is not iterable(KSM-948)
1.0.1
- Fixed installation and import instructions in README
1.0.0
- Initial release
Release files for keeper-secrets-manager-storage-gcp-kms 1.1.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| keeper_secrets_manager_storage_gcp_kms-1.1.0.tar.gz | 22.5 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| keeper_secrets_manager_storage_gcp_kms-1.1.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 40.5 kB
Release files / keeper_secrets_manager_storage_gcp_kms-1.1.0.tar.gz
| Download URL | keeper_secrets_manager_storage_gcp_kms-1.1.0.tar.gz |
|---|---|
| Size | 22.5 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
c82fb7dddfcfe541f36778276012af7fc7a9abf1ebbe92addfcbfddf9d9cb487
|
|
BLAKE2b-256 checksum How to use checksums |
dd39bc96f9e98aa155a198e084227fdbca9c88ae2dba9ddd910da1cffa52c922
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.13
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on May 27, 2026.
Transparency logRelease files / keeper_secrets_manager_storage_gcp_kms-1.1.0-py3-none-any.whl
| Download URL | keeper_secrets_manager_storage_gcp_kms-1.1.0-py3-none-any.whl |
|---|---|
| Size | 18.0 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
dc7bd6dc6618e42a43276373c21c90468ceae60b88e05b78cc57f45032ae8b4a
|
|
BLAKE2b-256 checksum How to use checksums |
bdcfd8510e066a80857f44dab621e74e1d969b9019553fee9fea67ac60242a73
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.13
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on May 27, 2026.
Transparency log