Open Stack

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.
>