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@xxxxxxxxxx> 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@xxxxxxx > > To unsubscribe send an email to dev-leave@xxxxxxx > _______________________________________________ > 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
