DGS-19840 Ensure use of DEK object is thread-safe

[rayokota]

What

Checklist

• Contains customer facing changes? Including API/behavior changes
• Did you add sufficient unit test and/or integration test coverage for this PR?
  • If not, please explain why it is not required

References

JIRA:

Test & Review

Open questions / Follow-ups

[confluent-cla-assistant]

🎉 All Contributor License Agreements have been signed. Ready to merge.
_{Please push an empty commit if you would like to re-run the checks to verify CLA status for all contributors.}

PR Overview

This PR aims to ensure thread-safety when using the DEK object by adding locking around the decoding and caching of key material bytes.

• Introduced a threading lock (_lock) in the Dek class.
• Wrapped base64 decode operations in get_encrypted_key_material_bytes and get_key_material_bytes within a lock.
• Added lock protection in set_key_material.

Reviewed Changes

File	Description
src/confluent_kafka/schema_registry/rules/encryption/dek_registry/dek_registry_client.py	Added thread-safety via a new lock, protecting cached key material decoding and updates

Copilot reviewed 1 out of 1 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (1)

src/confluent_kafka/schema_registry/rules/encryption/dek_registry/dek_registry_client.py:254

• In the set_key_material method, when key_material_bytes is None, only self.key_material is cleared, but the corresponding cached self.key_material_bytes is not reset. This may lead to inconsistent state if a non-None key_material_bytes had been previously decoded.

def set_key_material(self, key_material_bytes: bytes):

[sonarqube-confluent]

Analysis Details

0 Issues

• 0 Bugs
• 0 Vulnerabilities
• 0 Code Smells

Coverage and Duplications

• 81.80% Coverage (61.80% Estimated after merge)
• No duplication information (0.90% Estimated after merge)

Project ID: confluent-kafka-python

View in SonarQube