[Proposal] Extend SSE-KMS in Rados Gateway to support HashiCorp Vault
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
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
Casey, thanks for the feedback. About the token file authentication:
- does it need to be secured and readable only by radosgw? is restricting access to the 'ceph' user/group good enough? For now its planned main use-case is for development, with ownership / read permissions restricted to the radosgw user/group only. (I've updated the doc)
- how often do we re-read it from disk in order to detect when the token is refreshed? hopefully not every request? The assumption here is that token file is for development only. In case someone decides to use it for production, refresh / authentication should be done externally and at that point he/she should be better of using the agent. In general, I would like to avoid to write custom KMS authentication methods and or refresh logic into the radosgw code.
-- Andrea Baglioni On Tue, 2 Jul 2019 at 22:08, Casey Bodley <cbodley@redhat.com> wrote:
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
Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
participants (2)
-
Andrea
-
Casey Bodley