Open Stack

On Thu, Aug 30, 2012 at 01:29:54PM -0700, Joshua Harlow wrote:
> Another thought,
> 
> Why not combine the signing and the admin role, but instead create a
> 'limited privileges' role that will act on behalf of the user later (but
> still maintains a connection to that user/tenant instead of a generic
> 'admin' role). The user will know that this user can only do a small
> subset of things on behalf of them (restorative actions only) and it will
> also be signed so that it can not do those restorative actions when that
> signing/token expires. I'd rather not store any user/pass in the DB
> (outside of where it originally came from). This sounds how you give
> permissions to your iphone to interact say with facebook, but that
> permissions set is limited and only valid for X time. For those that don't
> want to give this information or opt-out they would not get to take
> advantage of said restorative actions/HA...

I think that is an excellent point, even if we wanted to use an 'admin'
type user per tenant we should instead have an 'ha' user per tenant and
they can have a role that allows them to do only what they need.  That
is still a lot however as it generally requires being able to delete and
recreate the stack (instances, volumes etc).

I do agree about storing credentials in the database.. which is why we
want to find some other solution.

Good feedback, thanks. :)

    Ian

> On 8/30/12 12:40 PM, "Ian Main" <imain at redhat.com> wrote:
> 
> >
> >Howdy folks,
> >
> >So I've been doing some research lately into how to best support high
> >availability (HA) in heat-api.  The crux of the issue is that we need to
> >be able to perform operations on instances, volumes etc. some time after
> >we initially create them in order to perform restorative actions.  This
> >creates an issue with the authentication needed to perform these
> >operations.  I am posting to the list in the hope that we can get some
> >better ideas or hash out a good solution to this problem.
> >
> >Our current solution is to store the user credentials (either
> >ec2 access/secret key or keystone user/pass etc) in the database
> >(symmetrically encrypted) and use them to reauthenticate at a later date.
> >This could get hairy if the user was removed or changed tenants etc.
> >
> >The good:
> >- It's easy for admins.
> >- It works today.
> >- With encryption it's not too terribly insecure.
> >- Quota and billing is as it should be.
> >
> >Cons:
> >- Encryption passwd is in the config file.
> >- If a user state changes the stack (instances) could lose HA abilities
> >  unexpectedly.
> >
> >There are other options we could persue as well such as having an
> >'admin' user with a role in each tenant allowing us to perform
> >operations in that tenant as admin so we do not lose billing & quota
> >info.  This however requires the admin to add a role for each new tenant
> >and could be error prone.
> >
> >Pros:
> >- HA operations are performed by an 'admin' in the tenant and should
> >  always be available.
> >- Billing and quota info is still available although the billing may
> >  get odd as the user id could change on VM restart.
> >- It could work today.
> >
> >Cons:
> >- Requires more setup by the admin.  The scary part being everything
> >  would seem to work fine until HA was needed.  Although we could
> >  verify HA authentication when creating the stack.
> >- If custom billing app used user_id it could confuse someone.
> >
> >Another proposal was to possibly extend keystone with the ability to
> >'sign' HA operations so they can be performed at a later time with a
> >signature or token.
> >
> >Pros:
> >- Quite possibly very secure.
> >- Probably could be built so it doesn't matter if the user is gone?
> >- Would preserve billing/quotas.
> >
> >Cons:
> >- Not in existence. :)
> >- Possibly rather complex.
> >
> >I see also that there is a proposal for domains to be added to keystone:
> >
> >https://blueprints.launchpad.net/keystone/+spec/keystone-domains
> >
> >However I couldn't tell what the status of that was or if that would
> >clearly provide a solution to our HA needs.
> >
> >So that is the background of the present situation.  I am hoping that
> >this thread can lead to some new ideas or possibly some clear direction
> >going forward.
> >
> >Thanks!
> >
> >    Ian
> >
> >
> >_______________________________________________
> >OpenStack-dev mailing list
> >OpenStack-dev at lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>