Frequently Asked Questions about Client-Side Field Level Encryption

What is client-side field level encryption?

Client-side field level encryption (CSFLE) is a mechanism that encrypts specific fields to ensure that sensitive data is never stored in plaintext. The encryption and decryption of these fields is performed client-side, meaning that the sensitive data is never sent to Confluent Cloud in plaintext. This mechanism is designed to protect sensitive data from unauthorized access, even by Confluent Cloud administrators.

  • All sensitive data should be encrypted on clients such as Kafka producers and consumers.
  • Organizations own and manage the encryption keys in their own key management system (KMS).
  • Confluent does not have access to the encryption keys or data in plaintext.
  • CSFLE is based on existing governance capabilities like Schema Registry and tags.

Why should I use client-side field level encryption?

Here are some reasons to use client-side field level encryption:

  • Confluent employees, including SRE and Engineering, cannot access sensitive data, even when they have access to the Confluent Cloud environment and clusters.
  • Sensitive data cannot be exposed through third-party tools such as Amazon S3, Datadog, Splunk, or other tools that integrate with Confluent Cloud.
  • CSLFE meets important compliance requirements for data privacy and security.

Which fields should be encrypted?

  • Only encrypt fields that contain sensitive data. For example, encrypt fields that contain personally identifiable information (PII) such as social security numbers, credit card numbers, or other sensitive data.
  • Do not encrypt fields that are used for filtering or sorting. For example, fields used for filtering or sorting should not be encrypted because encrypted data cannot be filtered or sorted.
  • Encryption and decryption processes in field-level encryption execute on your clients. Sensitive data is encrypted before it is stored or transmitted, and then decrypted when it needs to be accessed by authorized users, producers, or consumers.
  • You can also use self-managed keys for server-side encryption for your Kafka clusters in Confluent Cloud. For more information, see Using Self-Managed Keys for Server-Side Encryption.

What encryption algorithm is used?

By default, the data encryption key uses the Advanced Encryption Standard (AES) algorithm in Galois/Counter Mode (GCM) with 256-bit keys (also referred to as AES-256-GCM).

Is Hashicorp Vault supported?

Hashicorp Vault Transit Secrets Engine is supported only when the KEK is not shared with Confluent. For more information, see Encryption as a Service: Transit Secrets Engine.

Can I use multiple key vaults for high availability?

Yes. CSFLE supports accessing encryption keys from multiple key vault instances for high availability and disaster recovery. It allows you to:

  • Configure redundant key vault access to ensure encryption operations continue if one key vault becomes unavailable.
  • Store identical copies of encryption keys across multiple regions or cloud providers.
  • Implement custom proxy services for advanced key vault management and failover logic.
  • Support data classification requirements where different types of data use different key vaults.

All key vault instances must contain identical copies of the encryption key material. CSFLE does not provide automatic failover between key vaults. You must implement retry/fallback in clients or a custom KMS driver/proxy. For more information, see the use of encrypt.alternate.kms.key.ids under kmsProps in KEK Parameters.