Frequently Asked Questions about Client-Side Field Level Encryption

Learn about client-side field level encryption (CSFLE) with these frequently asked questions.

What is client-side field level encryption?

Client-side field level encryption (CSFLE) encrypts specific fields in your data at the producer before sending to Kafka, ensuring sensitive data is never stored in plaintext. Confluent Cloud administrators cannot access your encrypted data because you control the encryption keys in your key management service (KMS).

Key characteristics:

  • All sensitive data is encrypted on clients such as Kafka producers and consumers.

  • Organizations own and manage the encryption keys in their own 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?

Use client-side field level encryption to:

  • Prevent Confluent employees, including SRE and Engineering, from accessing sensitive data, even when they have access to the Confluent Cloud environment and clusters.

  • Prevent sensitive data exposure through third-party tools such as Amazon S3, Datadog, Splunk, or other tools that integrate with Confluent Cloud.

  • Meet 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.

Where are keys stored?

When you enable Share key access with Confluent Cloud, you can create an encryption key for AWS, Azure, or Google Cloud key management service.

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.