Open Stack

On 03/13/2017 05:10 PM, Zane Bitter 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.

Who, specifically, are these gatekeepers of which you speak?

-jay