Open Stack

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