I know it happened a few messages up in the thread, but you may have forgotten where I said that we should resurrect the idea of having automatic instance-users as a feature of Nova (and even to add this to Shade/Oaktree, so people could add it to existing OpenStack clouds before they roll out the version that has it supported natively.
My only point there was that currently there is a workaround available, and it wouldn't be that alien to most users of clouds. Excerpts from Fox, Kevin M's message of 2017-03-13 14:31:10 +0000: > 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
