Open Stack

On 12/09/2013 05:34 PM, Steven Hardy wrote:
> 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?

X509.

The issue, as I understand it, is that there is no user object to back 
that credential.  You don't have a user to execute the trust.

Note that you should not be deriving a credential from a trust, you 
should be linking a trust to a credential.

The KDS code base has a similar problem.  We need a longer term 
credential service for internal components of Open Stack.  KDS is going 
to do it with symmetric keys, which might serve your needs. This is 
usually done via Kerberos in enterprise deployments.



>
> 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!
OAuth is short term delegation, not what you need.


>
> Thanks!
>
> Steve
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev