I totally agree that policy management is a major problem too. A much bigger one then instance users, and something I was hoping to get to after instance users, but never made it past the easier of the two. :/
The just inject creds solution keeps getting proposed, but only looks at the surface of the issue so has a lot of issues under the hood. Lets dig in again. Lets say I create a heat template and inject creds through Parameters, as that is the natural place for a user to fill out settings and launch their application. The cred is loaded unencrypted into the heat database. Then heat-engine pushes it into the nova database where it resides unencrypted, so it can be sent to cloud init, usually also in an unencrypted form. You delete the heat stack, and the credential still sticks around in the nova database long after the vm is deleted, as it keeps deleted data. The channels for passing stuff to a vm are much better at passing config to the vm, not secrets. Its also a one shot way to get an initial cred to a vm, but not a way to update it should the need arise. Also, how is the secret maintained in a way that rebooting the vm works while snapshotting the vm doesn't capture the secret, etc. The use case/issues are described exhaustively in the spec and describe why its not something thats something that can easily be tackled by "just do X" solutions. I proposed one implementation I think will work generally and cover all bases. But am open to other implementations that cover all the bases. Many half solutions have been proposed, but the whole point is security, so a half solution that has big security holes in it isn't really a solution. Thanks, Kevin ________________________________________ From: Clint Byrum [cl...@fewbar.com] Sent: Sunday, March 12, 2017 8:30 AM To: openstack-dev Subject: Re: [openstack-dev] [tc][appcat] The future of the App Catalog 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. > 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. 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. __________________________________________________________________________ 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 __________________________________________________________________________ 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
