Open Stack

So, this is where things start getting a little ugly and undefined... This is what I've been able to gather so far, so please someone correct me if I'm wrong.

Barbican is the OpenStack secret manager. It provides a standard OpenStack api for users to be able store/retrieve secrets... Its plugable and in theory, you could add a vault plugin to it. Barbican is then your abstraction layer.

Separate from that, is Castellan. Which is a plugable abstraction library at the client side. So a Vault plugin could be create for it instead.

My personal preference is to have a standard rest api over having a standard python client api in a cloud. Its more the OpenStack way. I'll leave it up to other sources to get into why a rest api's better.

That being said, there's still the elephant in the room I think of:

How do you securely get a secret to the vm, to allow you to get secrets from the secret store? I've been working on that use case for over a year now with little traction. :/ 

Either Castellan, Barbican, or talking directly to Vault will have that issue. How do you validate your vm with that service.

The current endeavor to address the situation is located here: 
https://review.openstack.org/#/c/222293/

We really need to get all the OpenStack projects together and address this issue as a whole. Everyone's now trying or has already worked around it in some not so nice ways. Amazon has had a solution for years now. Why can't we address it?

Thanks,
Kevin



________________________________________
From: Ian Cordasco [sigmavirus24 at gmail.com]
Sent: Wednesday, March 23, 2016 2:45 PM
To: Monty Taylor; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Streamline adoption of Magnum

-----Original Message-----
From: Monty Taylor <mordred at inaugust.com>
Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Date: March 22, 2016 at 18:49:41
To: openstack-dev at lists.openstack.org <openstack-dev at lists.openstack.org>
Subject:  Re: [openstack-dev] [magnum] Streamline adoption of Magnum

> On 03/22/2016 06:27 PM, Kevin Carter wrote:
> > /me wearing my deployer hat now: Many of my customers and product folks
> > want Magnum but they also want magnum to be as secure and stable as
> > possible. If Barbican is the best long term solution for the project it
> > would make sense to me that Magnum remain on course with Barbican as the
> > defacto way of deploying in production. IMHO building alternative means
> > for certificate management is a distraction and will only confuse folks
> > looking to deploy Magnum into production.
>
> I'm going to agree. This reminds me of people who didn't want to run
> keystone back in the day. Those people were a distraction, and placating
> them hampered OpenStack's progress by probably several years.

Right. Barbican is a good service that is actually necessary for a cloud (see also other similar services announced by the likes of Hashicorp). Magnum relying on it to securely store information makes perfect sense.

> >> Some ops teams are willing to
> >> adopt a new service, but not two. They only want to add Magnum and not
> >> Barbican.
> >
> > It would seem to me that once the Barbican dependency is well
> > documented, which it should be at this point, Barbican is be easy to
> > accept especially with the understanding of why it is needed. Many of
> > the deployment projects are creating the automation needed to make the
> > adoption of services simpler and I'd imagine deployment automation is
> > the largest hurdle to wide spread adoption for both Barbican and Magnum.
> > If the OPS team you mention does not want both services it would seem
> > they can use "local file" option; this is similar to Cinder+LVM and
> > Glance+file_store both of which have scale operational issues in production.
>
> Agree.

If it wasn't obvious, I also agree. That said, people will still try to use these to avoid the illusion of additional costs. They tend to ignore the cost of the repercussions of these decisions down the road.

> >> We think that once those operators become familiar with
> >> Magnum, adding Barbican will follow. In the mean time, we’d like to
> >> offer a Barbican alternative that allows Magnum to scale beyond one
> >> conductor, and allows for encrypted storage of TLC credentials needed
> >> for unattended bay operations.
> >
> > If all of this is to simplify or provide for the developer/"someone
> > kicking the tires" use case I'd imagine the "local file" storage would
> > be sufficient. If the acceptance of Barbican is too much to handle or
> > introduce into an active deployment (I'm not sure why that would be
> > especially if they're adding Magnum), the synchronization of locally
> > stored certificates across multiple hosts is manageable and can be
> > handled by a very long list of other pre-existing operational means.

Right, they may be using any of the other recently announced services created and provided by other groups.

> >> A blueprint [2] was recently proposed to
> >> address this. We discussed this in our team meeting today [3], where we
> >> used an etherpad [4] to collaborate on options that could be used as
> >> alternatives besides the ones offered today. This thread is not intended
> >> to answer how to make Barbican easier to adopt, but rather how to make
> >> Magnum easier to adopt while keeping Barbican as the default
> >> best-practice choice for certificate storage.
> >
> > I'd like there _NOT_ to be an "easy button" way for operators to hang
> > themselves in production by following a set of "quick start
> > instructions" under the guise of "easy to adopt". If Barbican is the
> > best-practice lets keep it that way. If for some reason Barbican is hard
> > to adopt lets identify those difficulties and get them fixed. Going down
> > the path of NIH or alternative less secure solutions because someone
> > (not identified here or speaking for themselves) has said they don't
> > want Barbican or deploying it is hard seems like a recipe for
> > fragmentation and disaster.
>
> Agree.

Perhaps, if the problem is less that two new services is problematic and the real problem is one (or some combination) of:

- Magnum and Barbican's dependency is poorly (if at all) documented
- Magnum and Barbican don't have documentation to deploy the services
- Magnum should support a variety of services like Barbican (e.g., adding support for Vault)

There are things that can be done. One thing is writing documentation. Another would be a driver for Vault or any other service the community might want. (Which is not to imply that there is a desire to rely on those, just that those are services that might be easier for our hypothetical operators to deploy.)

--
Ian Cordasco


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev