Casey, thanks for the feedback. About the token file authentication: 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) 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(a)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(a)ceph.io > > To unsubscribe send an email to dev-leave(a)ceph.io > _______________________________________________ > Dev mailing list -- dev(a)ceph.io > To unsubscribe send an email to dev-leave(a)ceph.io