Open Stack

On 13/03/17 17:20, Davanum Srinivas wrote:
> Zane,
>
> Sorry for the top post, Can you please submit a TC resolution? I can
> help with it as well. Let's test the waters.

OK, here is a start:

https://review.openstack.org/#/c/447031/

- ZB

> Thanks,
> Dims
>
> On Mon, Mar 13, 2017 at 5:10 PM, Zane Bitter <zbitter at redhat.com> wrote:
>> On 12/03/17 11:30, Clint Byrum wrote:
>>>
>>> Excerpts from Fox, Kevin M's message of 2017-03-11 21:31:40 +0000:
>>>>
>>>> No, they are treated as second class citizens. Take Trova again as an
>>>> example. The underlying OpenStack infrastructure does not provide a good
>>>> security solution for Trove's use case. As its more then just IaaS. So they
>>>> have spent years trying to work around it on one way or another, each with
>>>> horrible trade offs.
>>>>
>>>> For example they could fix an issue by:
>>>> 1. Run the service vm in the users tenant where it belongs. Though,
>>>> currently the user has permissions to reboot the vm, login through the
>>>> console and swipe any secrets that are on the vm and make it much harder for
>>>> the cloud admin to administer.
>>>> 2. Run the vm in a "trove" tenant. This fixes the security issue but
>>>> breaks the quota model of OpenStack. Users with special host aggregate
>>>> access/flavors can't work with this model.
>>>>
>>>> For our site, we can't use Trove at all at the moment, even though we
>>>> want to. Because option 2 doesn't work for us, and option 1 currently has a
>>>> glaring security flaw in it.
>>>>
>>>> One of the ways I saw Trove try to fix it was to get a feature into Nova
>>>> called "Service VM's". VMs owned by the user but not fully controllable by
>>>> them but from some other OpenStack service on their behalf. This, IMO is the
>>>> right way to solve it. There are a lot of advanced services that need this
>>>> functionality. But it seems to have been rejected, as "users don't need
>>>> that"... Which is true, only if you only consider the IaaS use case.
>>>>
>>>
>>> You're right. This type of rejection is not O-K IMO, because this is
>>> consumers of Nova with a real use case, asking for real features that
>>> simply cannot be implemented anywhere except inside Nova. Perhaps the
>>> climate has changed, and this effort can be resurrected.
>>
>>
>> I don't believe the climate has changed; there's no reason for it have. Nova
>> is still constrained by the size of the core reviewers team, and they've
>> been unwilling or unable to take steps (like splitting Nova up into smaller
>> chunks) that would increase capacity, so they have to reject as many feature
>> requests as possible. Given that the wider community has never had a debate
>> about what we're trying to build or for whom, it's perfectly easy to drift
>> along thinking that the current priorities are adequate without ever being
>> challenged.
>>
>> Until we have a TC resolution - with the community consensus to back it up -
>> that says "the reason for having APIs to your infrastructure is so that
>> *applications* can use them and projects must make not being an obstacle to
>> this their highest purpose", or "we're building an open source AWS, not a
>> free VMWare", or https://www.youtube.com/watch?v=Vhh_GeBPOhs ... until it's
>> not possible to say with complete earnestness "OpenStack has VMs, so you can
>> run any application on it" then the climate will never change, and we'll
>> just keep hearing "I don't need this, so neither should you".
>>
>>>> The problems of these other OpenStack services are being rejected as
>>>> second class problems, not primary ones.
>>>>
>>>> I'm sure other sites are avoiding other OpenStack advanced services for
>>>> similar reasons. its not just that Operators don't want to deploy it, or
>>>> that Users are not asking for it.
>>>>
>>>> Let me try and explain Zane's post in a sligtly different way... maybe
>>>> that would help...
>>>>
>>>> So, say you had an operating system. It had the ability to run arbitrary
>>>> programs if the user started an executable via the keyboard/mouse. But had
>>>> no ability for an executable to start another executable. How useful would
>>>> that OS be? There would be no shell scripts. No non monolithic applications.
>>>> It would be sort of functional, but would be hamstrung.
>>>>
>>>> OpenStack is like that today. Like the DOS operating system. Programs are
>>>> expected to be pretty self contained and not really talk back to the
>>>> Operating System its running on, nor a way to discover other programs
>>>> running on the same system. Nor really for a script running on the Operating
>>>> System to start other programs, chaining them together in a way thats more
>>>> useful then the sum of their parts. The current view is fine if you need is
>>>> just a container to run a traditional OS in. Its not if you are trying to
>>>> build an application that spans things.
>>>>
>>>> There have been several attempts at fixing this, in Heat, in Murano, in
>>>> the App Catalog, but plumbing they rely on isn't really supportive of it, as
>>>> they believe the use case really is just launching a VM with an OS in it is
>>>> really the important thing to do, and the job's done.
>>>>
>>>> For the Applications Catalog to be successful, it needs the underlying
>>>> cloud to have enough functionality among a common set of cloud provided
>>>> services to allow applications developers to write cloud software that is
>>>> redistributable and consumable by the end user. Its failed because the
>>>> infrastructure just isn't there. The other advanced services are suffering
>>>> from it too.
>>>>
>>>
>>> I'm not sure I agree. One can very simply inject needed credentials
>>> into a running VM and have it interact with the cloud APIs.
>>
>>
>> Demo please!
>>
>> Most Keystone backends are read-only, you can't even create a new user
>> account yourself. It's an admin-only API anyway. The only non-expiring
>> credential you even *have*, ignoring the difficulties of getting it to the
>> server, is your LDAP password. Would *you* put *your* LDAP password on an
>> internet-facing server? I would not.
>>
>>> However,
>>> there is a deficiency that affects all VM users that might make this
>>> a more desirable option.
>>>
>>> There's a lack of a detailed policy management piece. What I'd really
>>> like to inject is an API key that can only do the 2 things my app needs
>>> (like, scale up load balancer, or allocate and attach a volume to itself).
>>> Roles are just too opaque for that to really work well these days.
>>
>>
>> Yes. this is a problem with the default policy - if you have *any* role in a
>> project then you get write access to everything in that project. I don't
>> know how I can even call this role-based, since everybody has access to
>> everything regardless of their roles.
>>
>> Keystone folks are working on a new global default policy. The new policy
>> will require specific reader/writer roles on a project to access any of that
>> project's data (I attended the design session and insisted on it). That will
>> free up services to create their own limited-scope roles without the
>> consequence of opening up full access to every other OpenStack API. e.g.
>> it's easy to imagine a magnum-tenant role that has permissions to move
>> Neutron ports around but nothing else.
>>
>> We ultimately need finer-grained authorisation than that - we'll want users
>> to be able to specify permissions for particular resources, and since most
>> users are not OpenStack projects we'll need them to be able to do it for
>> roles (or specific user accounts) that are not predefined in policy.json.
>> With the other stuff in place that's at least do-able in individual projects
>> though, and if a few projects can agree on a common approach then it could
>> easily turn into e.g. an Oslo library, even if it never turns into a
>> centralised authorisation service.
>>
>> That's all entirely dependent on the gatekeepers unblocking us though.
>>
>> cheers,
>> Zane.
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>