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 <zbit...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ 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
