Add KMS rotation/destruction feature to the changelog and docs (#2600)

* Add initial changelog entry

* feat(docs): Add initial stab at docs for KMS rotation/destruction

* fixup! Add initial changelog entry

* Review comments
This commit is contained in:
Johan Brandhorst-Satzkorn authored and Jim committed 2022-12-01 13:32:35 -05:00
1 parent 5f8d292ea1
commit 6d25b35b4e
2 files changed
+24 -12

No files matched your search

+9
View File
@@ -32,6 +32,15 @@ Canonical reference for changes, improvements, and bugfixes for Boundary.
string after a specified substring; this is useful for pulling an user/account name from an email address. In the following example it uses the account email can be any other parameter:
* `{{ truncateFrom .Account.Email "@" }}`: this would turn `foo@example.com` into `foo`
* Per-scope key lifecycle management: You can now manage the lifecycles of both Key
Encryption Keys (KEKs) and Data Encryption Keys (DEKs) using the new key rotation
and key version destruction functionality. To learn more about this new feature,
refer to the
[documentation](https://developer.hashicorp.com/boundary/docs/concepts/security/data-encryption).
Upgrade notice: If the Database purpose DEK for a scope is destroyed, you must use
the API to cancel any sessions that predate the upgrade.
([PR](https://github.com/hashicorp/boundary/pull/2477))
* Custom Response Headers: Adds ability to set api and ui response headers based
on status code. Includes default secure CSP and other headers.
@@ -13,11 +13,6 @@ Systems](/docs/configuration/kms) that protect the base encryption keys used
for various functions. This page describes the various KMS key purposes that
Boundary supports and how they are used within the system.
~> **Note:** Boundary does not currently support rotation of its internal keys, but this
will be supported in a future version. External keys can be rotated so long as
the original keys remain available for decryption; full support for rotating
these will come in a future version as well.
## The `worker-auth-storage` KMS Key
The `worker-auth-storage` KMS key is used by a [PKI
@@ -25,27 +20,35 @@ Worker](/docs/configuration/worker/pki-worker) for storage of authentication
keys. It is optional for PKI workers; if not specified the authentication keys
will not be encrypted on disk. This is not used by KMS workers.
## The `root` KMS Key and Per-Scope KEK/DEKs <sup>OSS Only</sup>
## The `rootKey` KMS Key and Per-Scope KEK/DEKs <sup>OSS Only</sup>
Following best practices of using different encryption keys for different
purposes, Boundary has a number of encryption keys generated within each scope.
Each key further contains versions, which hold the key material used to encrypt
data. You can create new key versions by _rotating_ the keys. A key version
can be destroyed, which will re-encrypt any existing data before destroying the
key material permanently.
The `root` KMS key acts as a KEK (Key Encrypting Key) for the scope-specific
KEKs (also referred to as the scope's `root` key). The scope's `root` KEK
The `rootKey` KMS key acts as a KEK (Key Encrypting Key) for the scope-specific
KEKs (also referred to as the scope's `rootKey` key). The scope's `rootKey` KEK
and the various DEKs (Data Encryption Keys) are created when a scope is created.
The DEKs are encrypted with the scope's `root` KEK, and this is in turn
encrypted with the KMS key marked for the `root` purpose.
The DEKs are encrypted with the scope's `rootKey` KEK, and this is in turn
encrypted with the KMS key marked for the `rootKey` purpose.
The current scoped DEKs and their purposes are detailed below:
~> **Note:** Management of these keys is handled entirely internally; the information
provided in this section is purely for informational purposes.
- `audit`: This is used to encrypt secret values in the event log. For more
information about the event log, refer to
[the events config](/docs/configuration/events).
- `database`: This is the general-purpose DEK used to encrypt values within the
database. Values that are encrypted are those generally considered to be
secret, such as API keys, third-party tokens, certificate private keys, and so
on.
- `oidc`: This is used to encrypt OIDC information in cookies and authentication
requests.
- `oplog`: This is used for encrypting oplog (operation log) values for the
given scope.