FDB native Encryption data at-rest

Development
1

(Disclaimer: This post is intentionally kept terse and doesn’t discuss the detailed design. My intention is to keep the community aware of upcoming feature additions to the FDB. Please ask questions as needed)

At Snowflake we are currently working on the FDB native Encryption data at-rest feature. With this post I want to share the feature details with the broader community incase it is useful for others and they want to start preparatory work to utilize the feature (or want to participate in early testing as soon as the feature is code-complete in the main branch)

Status Quo

FoundationDB being a multi-model, easily scalable and fault-tolerant, with an ability to provide great performance even with commodity hardware, plays a critical role enabling enterprises to deploy, manage and run mission critical applications. Data-at-rest encryption support is considered a table-stake feature for any modern enterprise service offering.

FDB currently does not support data-at-rest encryption semantics; a customer needs to implement application level encryption schemes to protect their data/metadata stored in FDB. Given the criticality of the feature, it seems highly desirable to implement FDB native data-at-rest encryption support adhering to the latest security standards.

Goals

  • Implement end-user transparent, FDB native data-at-rest encryption support.
  • Isolation guarantees: the encryption domain matches the “tenant” partition semantics supported by a FDB cluster. For details on “tenant” concepts refer to documentation
  • KMS integration: Ease of integration with external Key Management Service/Solutions.

Refer to Encryption data at rest wiki for more details.

1 Like
2

Hi all,

As promised earlier, FDB 71.3 (Snowflake release) enables Encryption at-Rest feature support for FDB. Please follow the https://github.com/apple/foundationdb/blob/main/design/encryption-data-at-rest.md for details and/or reach out to me for any issues/concerns etc.
Thanks

3

@aehusain - Do we have documentation on how to pass KMS configurations when enabling encryption-at-rest ?

–discover-kms-conn-url-file: local filesystem file-path defining the URL to connect with KMS on startup. FDB support periodic refreshes of KMS URLs if supported.

–kms-conn-validation-token-details: local file system file(s) detailing the validation tokens needed by KMS to authorize FDB ↔ GS communication.

–kms-conn-get-encryption-keys-endpoint: KMS REST endpoint to fetch encryption keys by baseCipherIds

–kms-conn-get-latest-encryption-keys-endpoint: KMS REST endpoint to fetch latest encryption keys for a given encryption domain id

or any examples on how to use the REST based KMS integration ? Thanks

4

@aknagpal

All above mentioned parameters can be passed using foundationdb.conf file Or also known as cluster file in some conversations.

A sample file:

knob_rest_kms_connector_get_encryption_keys_endpoint        = <rest endpoint>
knob_rest_kms_connector_get_latest_encryption_keys_endpoint = <rest endpoint>
knob_rest_kms_connector_discover_kms_url_file               = <cluster host local filesystem path>
kms-conn-validation-token-details                           = <pattern specified below>

ServerKnob.cpp documents format of the validation-token files:

	// Details to fetch validation token from a localhost file
	// acceptable format: "<token_name1>$<absolute_file_path1>,<token_name2>$<absolute_file_path2>,.."
	// NOTE: 'token-name" can NOT contain '$' character
	init( REST_KMS_CONNECTOR_VALIDATION_TOKEN_DETAILS,             "");

Hope it helps. Feel free to reach out for more question/concerns/suggestions etc.

5

Thanks @aehusain. Are there any restrictions/specs on knob_rest_kms_connector_get_encryption_keys_endpoint (i.e. request/response schema) .

Example: GET - http://localhost/getEncryptionKey

Also, is it possible to enable the encryption-at-rest support for already existing database ?

6

@aknagpal Follow https://github.com/apple/foundationdb/blob/main/fdbserver/RESTKmsConnector.actor.cpp#L692 to learn more about request and response payload formats.

As an AI on myself, will update the design documentation https://github.com/apple/foundationdb/blob/main/design/encryption-data-at-rest.md with relevant details.

7

No, EaR support is driven by database configuration which can be set ONLY at the time of database creation and can’t be modified after creation.
Thanks

8

Do we have plans to add this feature in general release?

9

Please follow conversation in this thread for general release details: Is there any plan to support data at rest encryption in FDB? - #8 by biswas-adobe

10

@aehusain - Have a question on the key revocation workflow ? If the client wants to delete the key/revoke the key for tenant, are there any settings/configs that can be applied for this workflow ?

i.e. FDB tenant is still there but the key has been revoked by KMS. Any guidelines on, Whats the best way to handle this scenario?

11

@aknagpal

If the client wants to delete the key/revoke the key for tenant, are there any settings/configs that can be applied for this workflow

FDB enables KMS to govern lifecycle of cipher fetches from external KMS

// Acceptable response payload json format:
	//
	// response_json_payload {
	//   "version" = <version>
	//   "cipher_key_details" : [
	//     {
	//        "base_cipher_id"    : <cipherKeyId>,
	//        "encrypt_domain_id" : <domainId>,
	//        "base_cipher"       : <baseCipher>,
	//        "refresh_after_sec"   : <refreshTimeInterval>, (Optional)
	//        "expire_after_sec"    : <expireTimeInterval>  (Optional)
	//     },
	//     {
	//         ....
	//	   }
	//   ],
	//   "kms_urls" : [
	//         "url1", "url2", ...
	//   ],
	//	 "error" : {					// Optional, populated by the KMS, if present, rest of payload is ignored.
	//		"errMsg" : <message>,
	//		"errCode": <code>
	// 	  }
	// }

There isn’t any explicit workflow to revoke key for any given tenant, however, given FDB periodically refreshes encryption keys for known tenants, revocation can be done in refresh cycle if needed. However, for decryption purposes already fetches ciphers by FDB would still be valid, an alternate solution would be wipe out in-memory cache by bouncing EKP process (not ideal as it has negative impact on all tenants served by the cluster)

12

@aknagpal just curious, do you mind what is the scope of the project undertaking you are working on and also which company the project is associated, if any?

Thanks

13

Thanks @aehusain. Can you elaborate on the part where already fetched ciphers will be available. Are these available in-memory cache for the 10 mins or these are always available ?

14

Sure, I work at Adobe, we are exploring Customer Managed keys support for foundation db datastore.