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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
