Hi Andrea,
I think it's a good idea to target sse-kms for this project. The
proposed refactoring steps look great.
Since this work may be the foundation for future sse-s3 support, I'd
like to choose more general names for the config options - like
rgw_crypt_vault_* instead of rgw_crypt_s3_kms_vault_*.
The vault agent sounds really convenient here. There are some challenges
to using the token file for authentication:
- does it need to be secured and readable only by radosgw? is
restricting access to the 'ceph' user/group good enough?
- how often do we re-read it from disk in order to detect when the token
is refreshed? hopefully not every request?
On 7/2/19 12:49 PM, Andrea wrote:
Hi everyone,
I am currently working on a project where the Rados Gateway SSE-KMS
feature is required;
I cannot rely on the solution based on Barbican and Vault is the KMS of choice.
For these reason, here [1] a proposal to abstract the key management
service and an initial sketch for a refactoring strategy to support
HashiCorp Vault.
I am currently not planning on adding any new SSE strategy (such as
SSE-S3), although the refactoring might simplify its implementation.
Thanks.
[1] https://pad.ceph.com/p/rgw_sse-kms
--
Andrea Baglioni
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
