So for cloud apps, you must have a config management system to do secure secret transport? A cloud app developer must target which config management tool? How do you know what the end user sites are running? Do you have to support all of them? Config management tooling is very religious, so if you don't pick the right one, folks will shun your app. Thats way too burdensome on app developers and users to require.
Instead, look at how aws does creds, and k8s. Any vm can just request a fresh token. In k8s, a fresh token is injected into the container automatically. This makes it extremely easy to deal with. This is what app developers are expecting now and openstack is turning folks away when we keep pushing a lot of work their way. Openstacks general solution for any hard problem seems to be, make the operator, app dev, or user deal with it, not openstack. Thats ok if those folks have no where else to go. They do now, and are starting to do so as there are more options. Openstack needs to abandon that phylosophy. It can no longer afford it. Thanks, Kevin ________________________________ From: Clint Byrum Sent: Sunday, March 12, 2017 10:30:49 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-12 16:54:20 +0000: > 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. > _OR_, you inject a nonce that is used to authenticate the instance to config management. If you're ever going to talk to anything outside of the cloud APIs, you'll need this anyway. Once you're involved with config management you are already sending credentials of various types to your instances. __________________________________________________________________________ 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
