2018-10-23 19:14:32 +00:00
|
|
|
---
|
2020-01-18 00:18:09 +00:00
|
|
|
layout: docs
|
|
|
|
page_title: Google Cloud KMS - Secrets Engines
|
2018-10-23 19:14:32 +00:00
|
|
|
description: |-
|
|
|
|
The Google Cloud KMS secrets engine for Vault interfaces with Google Cloud
|
|
|
|
KMS for encryption/decryption of data and KMS key management through Vault.
|
|
|
|
---
|
|
|
|
|
2023-07-18 21:07:55 +00:00
|
|
|
# Google Cloud KMS secrets engine
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
The Google Cloud KMS Vault secrets engine provides encryption and key management
|
|
|
|
via [Google Cloud KMS][kms]. It supports management of keys, including creation,
|
|
|
|
rotation, and revocation, as well as encrypting and decrypting data with managed
|
|
|
|
keys. This enables management of KMS keys through Vault's policies and IAM
|
|
|
|
system.
|
|
|
|
|
|
|
|
## Setup
|
|
|
|
|
|
|
|
Most secrets engines must be configured in advance before they can perform their
|
|
|
|
functions. These steps are usually completed by an operator or configuration
|
|
|
|
management tool.
|
|
|
|
|
|
|
|
1. Enable the Google Cloud KMS secrets engine:
|
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
```text
|
|
|
|
$ vault secrets enable gcpkms
|
|
|
|
Success! Enabled the gcpkms secrets engine at: gcpkms/
|
|
|
|
```
|
2018-10-23 19:14:32 +00:00
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
By default, the secrets engine will mount at the name of the engine. To
|
|
|
|
enable the secrets engine at a different path, use the `-path` argument.
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
1. Configure the secrets engine with account credentials and/or scopes:
|
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
```text
|
|
|
|
$ vault write gcpkms/config \
|
|
|
|
credentials=@my-credentials.json
|
|
|
|
Success! Data written to: gcpkms/config
|
|
|
|
```
|
2018-10-23 19:14:32 +00:00
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
If you are running Vault from inside [Google Compute Engine][gce] or [Google
|
|
|
|
Kubernetes Engine][gke], the instance or pod service account can be used in
|
2020-06-15 18:57:51 +00:00
|
|
|
place of specifying the credentials JSON file. For more information on
|
2020-01-18 00:18:09 +00:00
|
|
|
authentication, see the [authentication section](#authentication) below.
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
1. Create a Google Cloud KMS key:
|
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
```text
|
|
|
|
$ vault write gcpkms/keys/my-key \
|
|
|
|
key_ring=projects/my-project/locations/my-location/keyRings/my-keyring \
|
|
|
|
rotation_period=72h
|
|
|
|
```
|
2018-10-23 19:14:32 +00:00
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
The `key_ring` parameter is specified in the following format:
|
2018-10-23 19:14:32 +00:00
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
```text
|
|
|
|
projects/<project>/locations/<location>/keyRings/<keyring>
|
|
|
|
```
|
2018-10-23 19:14:32 +00:00
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
where:
|
|
|
|
|
|
|
|
- `<project>` - the name of the GCP project (e.g. "my-project")
|
|
|
|
- `<location>` - the location of the KMS key ring (e.g. "us-east1", "global")
|
|
|
|
- `<keyring>` - the name of the KMS key ring (e.g. "my-keyring")
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
## Usage
|
|
|
|
|
|
|
|
After the secrets engine is configured and a user/machine has a Vault token with
|
|
|
|
the proper permission, it can be used to encrypt, decrypt, and manage keys. The
|
|
|
|
following sections describe the different ways in which keys can be managed.
|
|
|
|
|
|
|
|
### Symmetric Encryption/Decryption
|
|
|
|
|
|
|
|
This section describes using a Cloud KMS key for symmetric
|
2018-10-25 21:10:11 +00:00
|
|
|
encryption/decryption. This is one of the most common types of encryption.
|
|
|
|
Google Cloud manages the key ring which is used to encrypt and decrypt data.
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
<table>
|
|
|
|
<thead>
|
|
|
|
<tr>
|
|
|
|
<th>Purpose</th>
|
|
|
|
<th>Supported Algorithms</th>
|
|
|
|
</tr>
|
|
|
|
<tr>
|
2020-01-18 00:18:09 +00:00
|
|
|
<td valign="top">
|
|
|
|
<code>encrypt_decrypt</code>
|
|
|
|
</td>
|
2018-10-23 19:14:32 +00:00
|
|
|
<td valign="top">
|
|
|
|
<code>symmetric_encryption</code>
|
|
|
|
</td>
|
|
|
|
</tr>
|
|
|
|
</thead>
|
|
|
|
</table>
|
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
1. Create or use an existing key eligible for symmetric encryption/decryption:
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
```text
|
|
|
|
$ vault write gcpkms/keys/my-key \
|
|
|
|
key_ring=projects/.../my-keyring \
|
|
|
|
purpose=encrypt_decrypt \
|
|
|
|
algorithm=symmetric_encryption
|
|
|
|
```
|
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
1. Encrypt plaintext data using the `/encrypt` endpoint with a named key:
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
```text
|
|
|
|
$ vault write gcpkms/encrypt/my-key plaintext="hello world"
|
|
|
|
Key Value
|
|
|
|
--- -----
|
|
|
|
ciphertext CiQAuMv0lTiKjrF43Lgr4...
|
|
|
|
key_version 1
|
|
|
|
```
|
|
|
|
|
|
|
|
Unlike Vault's transit backend, plaintext data does not need to be base64
|
|
|
|
encoded. The endpoint will automatically convert data.
|
|
|
|
|
|
|
|
Note that Vault is not _storing_ this data. The caller is responsible for
|
|
|
|
storing the resulting ciphertext.
|
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
1. Decrypt ciphertext using the `/decrypt` endpoint with a named key:
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
```text
|
|
|
|
$ vault write gcpkms/decrypt/my-key ciphertext=CiQAuMv0lTiKjrF43Lgr4...
|
|
|
|
Key Value
|
|
|
|
--- -----
|
|
|
|
plaintext hello world
|
|
|
|
```
|
|
|
|
|
|
|
|
For easier scripting, it is also possible to extract the plaintext directly:
|
|
|
|
|
|
|
|
```text
|
|
|
|
$ vault write -field=plaintext gcpkms/decrypt/my-key ciphertext=CiQAuMv0lTiKjrF43Lgr4...
|
|
|
|
hello world
|
|
|
|
```
|
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
1. Rotate the underlying encryption key. This will generate a new crypto key
|
|
|
|
version on Google Cloud KMS and set that version as the active key.
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
```text
|
|
|
|
$ vault write -f gcpkms/keys/rotate/my-key
|
|
|
|
WARNING! The following warnings were returned from Vault:
|
|
|
|
|
|
|
|
* The crypto key version was rotated successfully, but it can take up to 2
|
|
|
|
hours for the new crypto key version to become the primary. In practice, it
|
|
|
|
is usually much shorter. Be sure to issue a read operation and verify the
|
|
|
|
key version if you require new data to be encrypted with this key.
|
|
|
|
|
|
|
|
Key Value
|
|
|
|
--- -----
|
|
|
|
key_version 2
|
|
|
|
```
|
|
|
|
|
|
|
|
As the message says, rotation is not immediate. Depending on a number of
|
|
|
|
factors, the propagation of the new key can take quite some time. If you
|
|
|
|
have a need to immediately encrypt data with this new key, query the API to
|
2018-10-25 21:10:11 +00:00
|
|
|
wait for the key to become the primary. Alternatively, you can specify the
|
|
|
|
`key_version` parameter to lock to the exact key for use with encryption.
|
2018-10-23 19:14:32 +00:00
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
1. Re-encrypt already-encrypted ciphertext to be encrypted with a new version of
|
|
|
|
the crypto key. Vault will decrypt the value using the appropriate key in the
|
|
|
|
keyring and then encrypt the resulting plaintext with the newest key in the
|
|
|
|
keyring.
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
```text
|
|
|
|
$ vault write gcpkms/reencrypt/my-key ciphertext=CiQAuMv0lTiKjrF43Lgr4...
|
|
|
|
Key Value
|
|
|
|
--- -----
|
|
|
|
ciphertext CiQAuMv0lZTTozQA/ElqM...
|
|
|
|
key_version 2
|
|
|
|
```
|
|
|
|
|
|
|
|
This process **does not** reveal the plaintext data. As such, a Vault policy
|
2018-10-25 21:10:11 +00:00
|
|
|
could grant an untrusted process the ability to re-encrypt ciphertext data,
|
|
|
|
since the process would not be able to get access to the plaintext data.
|
2018-10-23 19:14:32 +00:00
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
1. Trim old key versions by deleting Cloud KMS crypto key versions that are
|
|
|
|
older than the `min_version` allowed on the key.
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
```text
|
|
|
|
$ vault write gcpkms/keys/config/my-key min_version=10
|
|
|
|
```
|
|
|
|
|
|
|
|
Then delete all keys older than version 10. This will make it impossible to
|
|
|
|
encrypt, decrypt, or sign values with the older key by conventional means.
|
|
|
|
|
|
|
|
```text
|
|
|
|
$ vault write -f gcpkms/keys/trim/my-key
|
|
|
|
```
|
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
1. Delete the key to delete all key versions and Vault's record of the key.
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
```text
|
|
|
|
$ vault delete gcpkms/keys/my-key
|
|
|
|
```
|
|
|
|
|
|
|
|
This will make it impossible to encrypt, decrypt, or sign values by
|
|
|
|
conventional means.
|
|
|
|
|
2023-07-18 21:07:55 +00:00
|
|
|
### Asymmetric decryption
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
This section describes using a Cloud KMS key for asymmetric decryption. In this
|
|
|
|
model Google Cloud manages the key ring and exposes the public key via an API
|
2018-10-25 21:10:11 +00:00
|
|
|
endpoint. The public key is used to encrypt data offline and produce ciphertext.
|
|
|
|
When the plaintext is desired, the user submits the ciphertext to Cloud KMS
|
|
|
|
which decrypts the value using the corresponding private key.
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
<table>
|
|
|
|
<thead>
|
|
|
|
<tr>
|
|
|
|
<th>Purpose</th>
|
|
|
|
<th>Supported Algorithms</th>
|
|
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<td valign="top">
|
2020-01-18 00:18:09 +00:00
|
|
|
<code>asymmetric_decrypt</code>
|
|
|
|
</td>
|
|
|
|
<td valign="top">
|
|
|
|
<code>rsa_decrypt_oaep_2048_sha256</code>
|
|
|
|
<br />
|
|
|
|
<code>rsa_decrypt_oaep_3072_sha256</code>
|
|
|
|
<br />
|
2018-10-23 19:14:32 +00:00
|
|
|
<code>rsa_decrypt_oaep_4096_sha256</code>
|
|
|
|
</td>
|
|
|
|
</tr>
|
|
|
|
</thead>
|
|
|
|
</table>
|
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
1. Create or use an existing key eligible for symmetric encryption/decryption:
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
```text
|
|
|
|
$ vault write gcpkms/keys/my-key \
|
|
|
|
key_ring=projects/.../my-keyring \
|
|
|
|
purpose=asymmetric_decrypt \
|
|
|
|
algorithm=rsa_decrypt_oaep_4096_sha256
|
|
|
|
```
|
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
1. Retrieve the public key from Cloud KMS:
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
```text
|
2020-07-30 17:50:23 +00:00
|
|
|
$ gcloud kms keys versions get-public-key <crypto-key-version> \
|
2018-10-25 21:10:11 +00:00
|
|
|
--location <location> \
|
|
|
|
--keyring <key-ring> \
|
|
|
|
--key <key> \
|
2018-10-23 19:14:32 +00:00
|
|
|
--output-file ~/mykey.pub
|
|
|
|
```
|
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
1. Encrypt plaintext data with the public key. Note this varies widely between
|
|
|
|
programming languages. The following example uses OpenSSL, but you can use your
|
|
|
|
language's built-ins as well.
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
```text
|
|
|
|
$ openssl pkeyutl -in ~/my-secret-file \
|
|
|
|
-encrypt -pubin \
|
|
|
|
-inkey ~/mykey.pub \
|
|
|
|
-pkeyopt rsa_padding_mode:oaep \
|
|
|
|
-pkeyopt rsa_oaep_md:sha256 \
|
|
|
|
-pkeyopt rsa_mgf1_md:sha256
|
|
|
|
```
|
|
|
|
|
|
|
|
Note that this encryption happens offline (meaning outside of Vault), and
|
|
|
|
the encryption is happening with a _public_ key. Only Cloud KMS has the
|
|
|
|
corresponding _private_ key.
|
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
1. Decrypt ciphertext using the `/decrypt` endpoint with a named key:
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
```text
|
2020-07-30 17:50:23 +00:00
|
|
|
$ vault write gcpkms/decrypt/my-key key_version=1 ciphertext=CiQAuMv0lTiKjrF43Lgr4...
|
2018-10-23 19:14:32 +00:00
|
|
|
Key Value
|
|
|
|
--- -----
|
|
|
|
plaintext hello world
|
|
|
|
```
|
|
|
|
|
2023-07-18 21:07:55 +00:00
|
|
|
### Asymmetric signing
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
This section describes using a Cloud KMS key for asymmetric signing. In this
|
|
|
|
model Google Cloud manages the key ring and exposes the public key via an API
|
|
|
|
endpoint. A message or digest is signed with the corresponding private key, and
|
2018-10-25 21:10:11 +00:00
|
|
|
can be verified by anyone with the corresponding public key.
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
<table>
|
|
|
|
<thead>
|
|
|
|
<tr>
|
|
|
|
<th>Purpose</th>
|
|
|
|
<th>Supported Algorithms</th>
|
|
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<td valign="top">
|
2020-01-18 00:18:09 +00:00
|
|
|
<code>asymmetric_sign</code>
|
|
|
|
</td>
|
|
|
|
<td valign="top">
|
|
|
|
<code>rsa_sign_pss_2048_sha256</code>
|
|
|
|
<br />
|
|
|
|
<code>rsa_sign_pss_3072_sha256</code>
|
|
|
|
<br />
|
|
|
|
<code>rsa_sign_pss_4096_sha256</code>
|
|
|
|
<br />
|
|
|
|
<code>rsa_sign_pkcs1_2048_sha256</code>
|
|
|
|
<br />
|
|
|
|
<code>rsa_sign_pkcs1_3072_sha256</code>
|
|
|
|
<br />
|
|
|
|
<code>rsa_sign_pkcs1_4096_sha256</code>
|
|
|
|
<br />
|
|
|
|
<code>ec_sign_p256_sha256</code>
|
|
|
|
<br />
|
2018-10-23 19:14:32 +00:00
|
|
|
<code>ec_sign_p384_sha384</code>
|
|
|
|
</td>
|
|
|
|
</tr>
|
|
|
|
</thead>
|
|
|
|
</table>
|
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
1. Create or use an existing key eligible for symmetric encryption/decryption:
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
```text
|
|
|
|
$ vault write gcpkms/keys/my-key \
|
|
|
|
key_ring=projects/.../my-keyring \
|
|
|
|
purpose=asymmetric_sign \
|
|
|
|
algorithm=ec_sign_p384_sha384
|
|
|
|
```
|
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
1. Calculate the base64-encoded binary digest. Use the hashing algorithm that
|
|
|
|
corresponds to they key type:
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
```text
|
2020-07-30 17:50:23 +00:00
|
|
|
$ export DIGEST=$(openssl dgst -sha384 -binary /my/file | base64)
|
2018-10-23 19:14:32 +00:00
|
|
|
```
|
|
|
|
|
|
|
|
Ask Cloud KMS to sign the digest:
|
|
|
|
|
|
|
|
```text
|
|
|
|
$ vault write gcpkms/sign/my-key key_version=1 digest=$DIGEST
|
|
|
|
Key Value
|
|
|
|
--- -----
|
|
|
|
signature MGYCMQDbOS2462SKMsGdh2GQ...
|
|
|
|
```
|
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
1. Verify the signature of the digest:
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
```text
|
|
|
|
$ vault write gcpkms/verify/my-key key_version=1 digest=$DIGEST signature=$SIGNATURE
|
|
|
|
Key Value
|
|
|
|
--- -----
|
|
|
|
valid true
|
|
|
|
```
|
|
|
|
|
2018-10-25 21:10:11 +00:00
|
|
|
Note: it is also possible to verify this signature without Vault. Download
|
|
|
|
the public key from Cloud KMS, and use a tool like OpenSSL or your
|
|
|
|
programming language primitives to verify the signature.
|
|
|
|
|
2018-10-23 19:14:32 +00:00
|
|
|
## Authentication
|
|
|
|
|
|
|
|
The Google Cloud KMS Vault secrets backend uses the official Google Cloud Golang
|
|
|
|
SDK. This means it supports the common ways of [providing credentials to Google
|
|
|
|
Cloud][cloud-creds]. In addition to specifying `credentials` directly via Vault
|
|
|
|
configuration, you can also get configuration from the following values **on the
|
|
|
|
Vault server**:
|
|
|
|
|
|
|
|
1. The environment variables `GOOGLE_APPLICATION_CREDENTIALS`. This is specified
|
2020-01-18 00:18:09 +00:00
|
|
|
as the **path** to a Google Cloud credentials file, typically for a service
|
|
|
|
account. If this environment variable is present, the resulting credentials are
|
|
|
|
used. If the credentials are invalid, an error is returned.
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
1. Default instance credentials. When no environment variable is present, the
|
2020-01-18 00:18:09 +00:00
|
|
|
default service account credentials are used. This is useful when running Vault
|
|
|
|
on [Google Compute Engine][gce] or [Google Kubernetes Engine][gke]
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
For more information on service accounts, please see the [Google Cloud Service
|
|
|
|
Accounts documentation][service-accounts].
|
|
|
|
|
2019-01-10 18:05:21 +00:00
|
|
|
To use this secrets engine, the service account must have the following
|
2018-10-23 19:14:32 +00:00
|
|
|
minimum scope(s):
|
|
|
|
|
|
|
|
```text
|
|
|
|
https://www.googleapis.com/auth/kms
|
|
|
|
```
|
|
|
|
|
2023-07-18 21:07:55 +00:00
|
|
|
### Required permissions
|
2018-10-23 19:14:32 +00:00
|
|
|
|
2019-01-10 18:05:21 +00:00
|
|
|
The credentials given to Vault must have the following role:
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
```text
|
|
|
|
roles/cloudkms.admin
|
|
|
|
```
|
|
|
|
|
|
|
|
If Vault will not be creating keys, you can reduce the permissions. For example,
|
|
|
|
to create keys out of band and have Vault manage the encryption/decryption, you
|
|
|
|
only need the following permissions:
|
|
|
|
|
|
|
|
```text
|
|
|
|
roles/cloudkms.cryptoKeyEncrypterDecrypter
|
|
|
|
```
|
|
|
|
|
2018-10-25 21:10:11 +00:00
|
|
|
To sign and verify, you only need the following permissions:
|
|
|
|
|
|
|
|
```text
|
|
|
|
roles/cloudkms.signerVerifier
|
|
|
|
```
|
|
|
|
|
2019-01-10 18:05:21 +00:00
|
|
|
For more information, please see the [Google Cloud KMS IAM documentation][kms-iam].
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
## FAQ
|
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
**How is this different than Vault's transit secrets engine?**<br />
|
2018-10-23 19:14:32 +00:00
|
|
|
Vault's [transit][vault-transit] secrets engine uses in-memory keys to
|
|
|
|
encrypt/decrypt keys. In general it will be faster and more performant. However,
|
|
|
|
users who need physical, off-site, or out-of-band key management can use the
|
|
|
|
[Google Cloud KMS][kms] secrets engine to get those benefits while leveraging
|
|
|
|
Vault's policy and identity system.
|
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
**Can Vault use an existing KMS key?**<br />
|
2018-10-23 19:14:32 +00:00
|
|
|
You can use the `/register` endpoint to configure Vault to talk to an existing
|
|
|
|
Google Cloud KMS key. As long as the IAM permissions are correct, Vault will be
|
|
|
|
able to encrypt/decrypt data and rotate the key. See the [api][api] for more
|
|
|
|
information.
|
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
**Can this be used with a hardware key like an HSM?**<br />
|
2018-10-23 19:14:32 +00:00
|
|
|
Yes! You can set `protection_level` to "hsm" when creating a key, or use an
|
|
|
|
existing Cloud KMS key that is backed by an HSM.
|
|
|
|
|
2020-01-18 00:18:09 +00:00
|
|
|
**How much does this cost?**<br />
|
2018-10-23 19:14:32 +00:00
|
|
|
The plugin is free and open source. KMS costs vary by key type and the number of
|
|
|
|
operations. Please see the [Cloud KMS pricing page][kms-pricing] for more
|
|
|
|
details.
|
|
|
|
|
2023-07-18 21:07:55 +00:00
|
|
|
## Help & support
|
2018-10-23 19:14:32 +00:00
|
|
|
|
|
|
|
The Google Cloud KMS Vault secrets engine is written as an external Vault
|
|
|
|
plugin. The code lives outside the main Vault repository. It is automatically
|
|
|
|
bundled with Vault releases, but the code is managed separately.
|
|
|
|
|
|
|
|
Please report issues, add feature requests, and submit contributions to the
|
|
|
|
[vault-plugin-secrets-gcpkms repo on GitHub][repo].
|
|
|
|
|
|
|
|
## API
|
|
|
|
|
|
|
|
The Google Cloud KMS secrets engine has a full HTTP API. Please see the
|
|
|
|
[Google Cloud KMS secrets engine API docs][api] for more details.
|
|
|
|
|
2023-01-26 00:12:15 +00:00
|
|
|
[api]: /vault/api-docs/secret/gcpkms
|
2018-10-23 19:14:32 +00:00
|
|
|
[cloud-creds]: https://cloud.google.com/docs/authentication/production#providing_credentials_to_your_application
|
|
|
|
[gce]: https://cloud.google.com/compute/
|
|
|
|
[gke]: https://cloud.google.com/kubernetes-engine/
|
|
|
|
[kms]: https://cloud.google.com/kms
|
|
|
|
[kms-iam]: https://cloud.google.com/kms/docs/reference/permissions-and-roles
|
|
|
|
[kms-pricing]: https://cloud.google.com/kms/pricing
|
|
|
|
[repo]: https://github.com/hashicorp/vault-plugin-secrets-gcpkms
|
|
|
|
[service-accounts]: https://cloud.google.com/compute/docs/access/service-accounts
|
2023-01-26 00:12:15 +00:00
|
|
|
[vault-transit]: /vault/docs/secrets/transit
|