Hi all, I have some queries about what the future of the ec2tokens API is for keystone, context as we're looking to move Heat from a horrible mixture of v2/v3 keystone to just v3, currently I'm not sure we can:
- The v3/credentials API allows ec2tokens to be stored (if you create the access/secret key yourself), but it requires admin, which creating an ec2-keypair via the v2 API does not? - There is no v3 interface for validating signed requests like you can via POST v2.0/ec2tokens AFAICT? - Validating requests signed with ec2 credentials stored via v3/credentials does not work, if you try to use v2.0/ec2tokens, should it? So my question is basically, what's the future of ec2tokens, is there some alternative in the pipeline for satisfying the same use-case? The main issues we have in Heat: - We want to continue supporting AWS style signed requests for our cloudformation-compatible API, which is currently done via ec2tokens. - ec2 keypairs are currently the only method of getting a non-expiring credential which we can deploy in-instance, that is no longer possible via the v3 API for the reasons above. What is the recommended way for us to deploy a (non expiring) credential in an instance (ideally derived from a trust or otherwise role-limited), then use that credential to authenticate against our API? My first thought is that the easiest solution would be to allow trust scoped tokens to optionally be configured to not expire (until we delete the trust when we delete the Heat stack)? Can anyone offer any suggestions on a v3 compatible way to do this? I did start looking at oauth as a possible solution, but it seems the client support is not yet there, and there's no auth middleware we can use for authenticating requests containing oauth credentials, any ideas on the status of this would be most helpful! Thanks! Steve _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
