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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
