Open Stack

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.

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



-- 
Davanum Srinivas :: https://twitter.com/dims