-
Notifications
You must be signed in to change notification settings - Fork 183
DOC-12393 native encryption at rest #3809
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: release/8.0
Are you sure you want to change the base?
Conversation
… page and some work to add/change roles for Morpheus.
…managing page. Start on REST API.
* Fixes/edits to other in-progress topics.
* Finished rough draft of manage topic. * Updated bucket refernce pages for new settings and new fields in output. * Updated screenshots that should show encrytion at rest field.
[CAUTION] | ||
==== | ||
Do not use encryption keys managed by AWS KMS to directly encrypt data. | ||
While retrieving individual encryption keys from AWS can take less than a second, cluster startup could result in many synchronous key retrievals. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While retrieving individual encryption keys from AWS can take less than a second
We don't retrieve keys from AWS KMS. We use AWS KMS for encryption and decryption on their side.
Something like "While each encryption and decryption with AWS key can take up to a second..." would be more correct.
While retrieving individual encryption keys from AWS can take less than a second, cluster startup could result in many synchronous key retrievals. | ||
These key retrievals can cause delays during cluster start. | ||
|
||
Only use the encryption keys you store in the AWS KMS as Key Encryption Keys (KEKs). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only use the encryption keys you store in the AWS KMS as Key Encryption Keys (KEKs)
This phrase doesn't sound fully correct to me because any encryption key described on this page is always used as a KEK.
For example, when you are configuring AWS Key to encrypt configuration data, it really means that "AWS Key" encrypts "Configuration DEKs", while "Configuration DEKs" encrypt "Configuration data". So as you see the AWS key plays a KEK role in this case as well.
What I think we should say here is something like:
We recommend using AWS Key to encrypt Couchbase Server Managed Keys instead of assigning them to encrypt data directly.
In other words instead of: AWS Key -> DEKs -> Data
we recommend using: AWS Key -> CB Managed Key -> DEKs -> Data
|
||
Only use the encryption keys you store in the AWS KMS as Key Encryption Keys (KEKs). | ||
Use these keys to encrypt Couchbase Server managed encryption keys. | ||
This method limits the number of retrievals from AWS while maintaining the security advantage of having keys managed by a remote KMS. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The same as above: We don't retrieve keys from AWS KMS. Encryption and decryption happens on AWS KMS side. Basically we ask AWS to encrypt or decrypt stuff for us with provided key ARN.
This method limits the number of encryption operations made by AWS while maintaining the security advantage of having keys managed by a remote KMS.
Disruptions in AWS or the network could result in errors because the cluster cannot retrieve encryption keys to encrypt or decrypt data. | ||
|
||
+ | ||
[#aws-kms-caution] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably should have the same caution for KMIP as well.
If you decide to use one caution for both of them there is one caveat though:
In comments below I am saying that we are not retrieving keys from AWS.
Well, for KMIP we can retrieve keys from the KMIP server (it is optional) so we need to be careful with phrasing if you decide to write a single caution. Maybe we can use more generic word like "operation".
|
||
Couchbase Server Secret Management:: | ||
You can have Couchbase Server act as the key management system. | ||
This method does not require any additional configuration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This method does not require any additional configuration.
However, using this method means that Couchbase Server stores your encryption keys locally, leaving them more vulnerable if there is a security breach.
This is not fully correct. It can be configured to be secure.
Maybe something like:
Couchbase Server manages the encryption key material (it generates, rotates, removes it with respect to the encryption key configuration).
This type of keys can be encrypted either with another encryption key (e.g. KMIP key), or with node master password (this method requires master password to be properly configured on each Couchbase node, note that by default master password is not configured).
| xref:rest-api:security/encryption-at-rest/manage-encryption-keys.adoc#list-keys[List Single Encryption-at-Rest Key] | ||
|
||
| `POST` | ||
| `/settings/encryptionKey` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is also POST /settings/encryptionKey/test
which tests the key (tries to use it for encryption and decryption)
Parameters are identical POST /settings/encryptionKey
.
| xref:rest-api:security/encryption-at-rest/manage-encryption-keys.adoc#create-key[Create an Encryption-at-Rest Key] | ||
|
||
| `PUT` | ||
| `/settings/encryptionKey/{KEY_ID}` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is also PUT /settings/encryptionKey/{KEY_ID}/test
which tests the key (tries to use it for encryption and decryption)
Parameters are identical to PUT /settings/encryptionKey/{KEY_ID}
.
[[del-privs]] | ||
=== Required Privileges | ||
|
||
You must have at least on one of the following roles: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as in the "(this comment describes roles that have write access for encryption keys)" comment.
[[get-privs]] | ||
=== Required Privileges | ||
|
||
You must have at least on one of the following roles: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correction:
Correct roles for GET /settings/security/encryptionAtRest
are
"Full Admin"
"Read-Only Admin"
"Security Admin"
This value can be: | ||
** `disabled`: not being encrypted | ||
** `encryptionKey`: encrypted using an encryption-at-rest key. | ||
** `nodeSecretManager`: Couchbase Server uses the master database password to encrypt the data. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"master database password" -> "node master password"
This PR adds documentation for the native encryption at rest feature (MB-16143).
Here's the doc plan for this feature.
Pages added/changed for this feature (links lead to perview site):
See here for the passwords for the preview site.