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@ceph.io To unsubscribe send an email to dev-leave@ceph.io