Open Stack

Hi all,

I’m strongly in favor of having immutable TLS-typed containers, and very
much opposed to storing every revision of changes done to a container.  I
think that storing versioned containers would add too much complexity to
Barbican, where immutable containers would work well.


I’m still not sold on the idea of registering services with Barbican, even
though (or maybe especially because) Barbican would not be using this data
for anything.  I understand the problem that we’re trying to solve by
associating different resources across projects, but I don’t feel like
Barbican is the right place to do this.

It seems we’re leaning towards option #2, but I would argue that
orchestration of services is outside the scope of Barbican’s role as a
secret-store.  I think this is a problem that may need to be solved at a
higher level.  Maybe an openstack-wide registry of dependend entities
across services?

-Doug

On 6/9/14, 2:54 PM, "Tiwari, Arvind" <arvind.tiwari at hp.com> wrote:

>As per current implementation, containers are immutable.
>Do we have any use case to make it mutable? Can we live with new
>container instead of updating an existing container?
>
>Arvind 
>
>-----Original Message-----
>From: Samuel Bercovici [mailto:SamuelB at Radware.com]
>Sent: Monday, June 09, 2014 1:31 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS
>Integration Ideas
>
>As far as I understand the Current Barbican implementation is immutable.
>Can anyone from Barbican comment on this?
>
>-----Original Message-----
>From: Jain, Vivek [mailto:VIVEKJAIN at ebay.com]
>Sent: Monday, June 09, 2014 8:34 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS
>Integration Ideas
>
>+1 for the idea of making certificate immutable.
>However, if Barbican allows updating certs/containers then versioning is
>a must.
>
>Thanks,
>Vivek
>
>
>On 6/8/14, 11:48 PM, "Samuel Bercovici" <SamuelB at Radware.com> wrote:
>
>>Hi,
>>
>>I think that option 2 should be preferred at this stage.
>>I also think that certificate should be immutable, if you want a new
>>one, create a new one and update the listener to use it.
>>This removes any chance of mistakes, need for versioning etc.
>>
>>-Sam.
>>
>>-----Original Message-----
>>From: Jorge Miramontes [mailto:jorge.miramontes at RACKSPACE.COM]
>>Sent: Friday, June 06, 2014 10:16 PM
>>To: OpenStack Development Mailing List (not for usage questions)
>>Subject: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS
>>Integration Ideas
>>
>>Hey everyone,
>>
>>Per our IRC discussion yesterday I'd like to continue the discussion on
>>how Barbican and Neutron LBaaS will interact. There are currently two
>>ideas in play and both will work. If you have another idea please free
>>to add it so that we may evaluate all the options relative to each other.
>>Here are the two current ideas:
>>
>>1. Create an eventing system for Barbican that Neutron LBaaS (and other
>>services) consumes to identify when to update/delete updated secrets
>>from Barbican. For those that aren't up to date with the Neutron LBaaS
>>API Revision, the project/tenant/user provides a secret (container?) id
>>when enabling SSL/TLS functionality.
>>
>>* Example: If a user makes a change to a secret/container in Barbican
>>then Neutron LBaaS will see an event and take the appropriate action.
>>
>>PROS:
>> - Barbican is going to create an eventing system regardless so it will
>>be supported.
>> - Decisions are made on behalf of the user which lessens the amount of
>>calls the user has to make.
>>
>>CONS:
>> - An eventing framework can become complex especially since we need to
>>ensure delivery of an event.
>> - Implementing an eventing system will take more time than option #2ŠI
>>think.
>>
>>2. Push orchestration decisions to API users. This idea comes with two
>>assumptions. The first assumption is that most providers' customers use
>>the cloud via a GUI, which in turn can handle any orchestration
>>decisions that need to be made. The second assumption is that power API
>>users are savvy and can handle their decisions as well. Using this
>>method requires services, such as LBaaS, to "register" in the form of
>>metadata to a barbican container.
>>
>>* Example: If a user makes a change to a secret the GUI can see which
>>services are registered and opt to warn the user of consequences. Power
>>users can look at the registered services and make decisions how they
>>see fit.
>>
>>PROS:
>> - Very simple to implement. The only code needed to make this a
>>reality is at the control plane (API) level.
>> - This option is more loosely coupled that option #1.
>>
>>CONS:
>> - Potential for services to not register/unregister. What happens in
>>this case?
>> - Pushes complexity of decision making on to GUI engineers and power
>>API users.
>>
>>
>>I would like to get a consensus on which option to move forward with
>>ASAP since the hackathon is coming up and delivering Barbican to
>>Neutron LBaaS integration is essential to exposing SSL/TLS
>>functionality, which almost everyone has stated is a #1/#2 priority.
>>
>>I'll start the decision making process by advocating for option #2. My
>>reason for choosing option #2 has to deal mostly with the simplicity of
>>implementing such a mechanism. Simplicity also means we can implement
>>the necessary code and get it approved much faster which seems to be a
>>concern for everyone. What option does everyone else want to move
>>forward with?
>>
>>
>>
>>Cheers,
>>--Jorge
>>
>>
>>_______________________________________________
>>OpenStack-dev mailing list
>>OpenStack-dev at lists.openstack.org
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>_______________________________________________
>>OpenStack-dev mailing list
>>OpenStack-dev at lists.openstack.org
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5660 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140609/fd9fc3e1/attachment.bin>