Re: [openstack-dev] [Security][Barbican][all] Bring your own key fishbowl sessions

[Nathan Reller]

> Thoughts?

Is anyone interested in the pull model or actually implementing it? I
say if the answer to that is no then only discuss the push model.

Note that I am having a talk on BYOK on Tuesday at 11:15. My talk will
go over provider key management, the push model, and the pull model.
There are some aspects of design in it that will likely interest
people. You might want to take the poll after session because I'm not
sure how many people know what the differences are.

-Nate

__
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

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

[Nathan Reller]

I agree with Doug's comments. Castellan is a generic key manager
library that allows symmetric keys, private keys, public keys,
certificates, passphrases, and opaque secret data to be stored in a
key manager. There is a Barbican implementation that is complete, and
a KMIP (Key Management Interoperability Protocol (an OASIS standard))
implementation is under development.

The precursor to castellan was the KeyManager interface integrated
into Nova and Cinder. We are in the process of making the easy switch
from that to Castellan. Glance and Sahara have both already integrated
with Castellan. Swift is currently integrating with Castellan and will
swap between Barbican and KMIP.

-Nate



On Wed, Apr 13, 2016 at 3:04 PM, Douglas Mendizábal
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi Hongbin,
>
> I have to admit that it's a bit disappointing that the Magnum team
> chose to decouple from Barbican, although I do understand that our
> team needs to do a better job of documenting detailed how-tos for
> deploying Barbican.
>
> I'm not sure that I understand the Threat Model you're trying to
> protect against, and I have not spent a whole lot of time researching
> Magnum architecture so please forgive me if my assumptions are wrong.
>
> So that we're all on the same page, I'm going to summarize the TLS
> use-case as I understand it:
>
> The magnum-conductor is a single process that may be scalable at some
> point in the future. [1]
>
> When the magnum-conductor is asked to provision a new bay the
> following things happen:
> 1. A new self-signed root CA is created.  This results in a Root CA
> Certificate and its associated key
> 2. N number of nodes are created to be part of the new bay.  For each
> node, a new x509 certificate is provisioned and signed by the Root CA
> created in 1.  This results in a certificate and key pair for each node.
> 3. The conductor then needs to store all generated keys in a secure
> location.
> 4. The conductor would also like to store all generated Certificates
> in a secure location, although this is not strictly necessary since
> Certificates contain no secret information as pointed out by Adam
> Young elsewhere in this thread.
>
> Currently the conductor is using python-barbicanclient to store the
> Root CA and Key in Barbican and associates those secrets via a
> Certificate Container and then stores the container URI in the
> conductor database.
>
> Since most users of Magnum are unwilling or unable to deploy Barbican
> the Magnum team would like an alternative mechanism for storing all
> keys as well as the Certificates.
>
> Additionally, since magnum-conductor may be more than one process in
> the future, the alternative storage must be available to many
> magnum-conductors.
>
> Now, in the proposed Keystone alternative the magnum-conductor will
> have a (symmetric?) encryption key.  Let's call this key the DEK
> (short for data-encryption-key).  How the DEK is stored and replicated
> to other magnum-conductors is outside of the scope of the proposed
> alternative solution.
> The magnum-conductor will use the DEK to encrypt all Certificates and
> Keys and then store the resulting ciphertexts using the Keystone
> credentials endpoint.
>
> This begs the question: If you're pre-encrypting all this data with
> the DEK, why do you need to store it in an external system?  I see no
> security benefit of using Keystone credentials over just storing these
> ciphertexts in a table in the database that all magnum-conductors will
> already have access to.
>
> I think a better alternative would be to integrate with Castellan and
> develop a new Castellan implementation where the DEK is specified in a
> config file, and the ciphertexts are stored in a database.  Let's call
> this new implementation LocalDEKAndDBKeyManager.
>
> With this approach the deployer could specify the
> LocalDEKAndDBKeyManager class as the implementation of Castellan to be
> used for their deployment, and then the DEK and db connection string
> could be specified in the config as well.
>
> By introducing the Castellan abstraction you would lose the ability to
> group secrets into containers, so you'd have to store separate
> references for each cert and key instead of just one barbican
> reference for both.  Also, you would probably have to write the
> Castellan integration in a way that always uses a context that is
> generated from the config file which will result in all keys being
> owned by the Magnum service tenant instead of the user's tenant when
> using Barbican as a backend.
>
> The upshot is that a deployer could choose the existing Barbican
> implementation instead, and other projects may be able to make use of
> the LocalDEKAndDBKeyManager.
>
> - - Douglas Mendizábal
>
> [1] http://docs.openstack.org/developer/magnum/#architecture
>
> On 4/13/16 10:14 AM, Hongbin Lu wrote:
>> I think there are two questions here:
>>
>> 1.   Should Magnum 

Re: [openstack-dev] [oslo][all] What would you like changed/fixed/new in oslo??

[Nathan Reller]

> Red Herring.  We don't need HMAC. We need to make better use of the tools in 
> Rabbit.

I'm curious what you mean by this. I'd like to know the lessons learned.

> As for HMAC several years/releases ago, what was the issue (just wondering)?
> Just to much load on controller nodes to do verification?
> Not enough adoption, something else...?

I would also be interested in knowing the answers to these questions.

-Nate

__
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

Re: [openstack-dev] [barbican] Nominating Fernando Diaz for Barbican Core

[Nathan Reller]

+1

He is a great addition to the Barbican community.

-Nate

On Mon, Feb 15, 2016 at 1:34 PM, Dave McCowan (dmccowan)
 wrote:
> +1
>
> On 2/15/16, 12:45 PM, "Douglas Mendizábal"
>  wrote:
>
>>-BEGIN PGP SIGNED MESSAGE-
>>Hash: SHA512
>>
>>Hi All,
>>
>>I would like to nominate Fernando Diaz for the Barbican Core team.
>>Fernando has been an enthusiastic contributor since joining the
>>Barbican team.  He is currently the most active non-core reviewer on
>>Barbican projects for the last 90 days. [1]  He¹s got an excellent eye
>>for review and I think he would make an excellent addition to the team.
>>
>>As a reminder to our current core reviewers, our Core Team policy is
>>documented in the wiki. [2]  So please reply to this thread with your
>>votes.
>>
>>Thanks,
>>- - Douglas Mendizábal
>>
>>[1] http://stackalytics.com/report/contribution/barbican-group/90
>>[2] https://wiki.openstack.org/wiki/Barbican/CoreTeam
>>-BEGIN PGP SIGNATURE-
>>
>>iQIcBAEBCgAGBQJWwg7GAAoJEB7Z2EQgmLX7mEUP/RFZCAZ9ZbDAB48lgek1dAPo
>>0KoK8IjkQhwKE7VYYhHwoZIlIdG0Eb9t8Y8ia9+k3SDzo0Q3upXckqEZbiZUZWQT
>>gv0BwpMkfUJ8zQeEQouomN8p/ZeRayZuAi3rz5rfte/JDr6IA1eFmPFRAQG+UO1H
>>hN6Al7nGm1Ixu/t969fqzslI6FwUu6CHGMDAcoXxL1mlCptC82mRzZZ26m0ObPFQ
>>GcnVka7CPseMqHCM6ls9I8AIubAWRehth9oLp7MP6D1vmJagNkwsWnHw5iB1rfBu
>>5TU9litnvei89kZ0uoIiOVruo9zh8R/hXn7CT3s3+9sQdwURrmoTHpEWlPlFQ8c7
>>ZRqRB7xt4L6jBt3lhoxCDftbmLIDMjBDPsfZjQKG44c+Tr0XuvaWTBVu/giJhvYW
>>RnKbQNhB/cByVooVc9itRC8QxZfI+3Ee1X+YEJrALDxjinAl7cHbi1T3DhmFyhRn
>>RbnF/9OVqy4+EqLsZFqEWdVZtyn29NWBOmiTyYtufufI41Yu+L6KU/hKj/a5HcSh
>>P63Bwp2cpyu+bJsCvMJWfXwW2odUte9RBKsmozFz2Q1ge2FMsr1nR7U0/+DVLoYI
>>GLHB3uvnKi2PgWAdbJCS21J6bGlhVX/MoIP/4gWmVuG5LflAfbyg3n5STgnRr7vQ
>>iBe0oW8NcTsETUVCYkwA
>>=09Wx
>>-END PGP SIGNATURE-
>>
>>__
>>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

__
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-dev] [cinder][nova]Move encryptors to os-brick

[Nathan Reller]

> the cinder admin and the nova admin are ALWAYS the same people

There is interest in hybrid clouds where the Nova and Cinder services
are managed by different providers. The customer would place higher
trust in Nova because you must trust the compute service, and the
customer would place less trust in Cinder. One way to achieve this
would be to have all encryption done by Nova. Cinder would simply see
encrypted data and provide a good cheap storage solution for data.

Consider a company with sensitive data. They can run the compute nodes
themselves and offload Cinder service to some third-party service.
This way they are the only ones who can manage the machines that see
the plaintext.

-Nate

__
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

Re: [openstack-dev] [Barbican] Providing service user read access to all tenant's certificates

[Nathan Reller]

> But that approach looks a little untidy, because tenant admin has to do
some infrastructure work.

I would think infrastructure work would be part of the admin role. They are
doing other things such as creating LBaaS, which seems like an
infrastructure job to me. I would think configuring LBaaS and key
management are similar. It seems like you think they are not similar. Can
you explain more?

-Nate
__
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

Re: [openstack-dev] [Barbican] Nominating Dave Mccowan for Barbican core

[Nathan Reller]

+1

Dave is a great member of the team, and I think he has earned it.

-Nate

On Tue, Sep 8, 2015 at 12:13 PM, Douglas Mendizábal <
douglas.mendiza...@rackspace.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> +1
>
> Dave has been a great asset to the team, and I think he would make an
> excellent core reviewer.
>
> - - Douglas Mendizábal
>
> On 9/8/15 11:05 AM, Juan Antonio Osorio wrote:
> > I'd like to nominate Dave Mccowan for the Barbican core review
> > team.
> >
> > He has been an active contributor both in doing relevant code
> > pieces and making useful and thorough reviews; And so I think he
> > would make a great addition to the team.
> >
> > Please bring the +1's :D
> >
> > Cheers!
> >
> > -- Juan Antonio Osorio R. e-mail: jaosor...@gmail.com
> > 
> >
> >
> >
> > __
> 
> >
> >
> >
> 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
> >
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - https://gpgtools.org
>
> iQIcBAEBCgAGBQJV7wkfAAoJEB7Z2EQgmLX7X+IP/AtYTxcx0u+O6MMLDU1VcGZg
> 5ksCdn1bosfuqJ/X/QWplHBSG8BzllwciHm7YJxIY94MaAlThk3Zw6UDKKkBMqIt
> Qag09Z868LPl9/pll0whR5fVa052zSMq/QYWTnpgwpAgQduKNe4KaR1ZKhtBBbAJ
> BvjyKEa2dJLA6LIMXxcxpoCAKSeORM5lce19kHHhWyqq9v5A89U6GHMgwRAa2fGN
> 7RyYmlOrmxh6TyJQX9Xl+w9y5WPAbxaUqC0MYEkLMpa7VnGf2pEangkN0LUAJO2x
> NxwHa73b2LA8K1+4hwTvZO28sRnyMHwjSpqvpGt60FXkgi4dLyyy8gR6gsO49EDB
> QOSwpwyFHzA//iuMl72pAD6uMzK0SCECtEu2000l0p3WEXS1i0z7p9VTfw4FySqb
> V0S/IeSFfkt09TK2DoOSzXAvBZjsLz9gjRbRIv2dx0QTTmN5JpihOeoUojn24aDV
> 86AshlhoImJGOX16MwRL+T6LCindkczGe4Faz7WzmBomEJ7SOY6pzDbyEBLYcqzu
> crvrLt2D1HmaygFGS37lVCqxlIegwsnZHGIe+Jtr8pDIDSW37ig4LZIDVra2/lj9
> E7/fWYCDqbSIUWYG2jMr0/3eQQwZCj4kNvtWaTlNFmTPJZAEYpSN3rBhkfWBgsLv
> mqBOM4IeR4EqaqaC2og7
> =jL8d
> -END PGP SIGNATURE-
>
> __
> 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

Re: [openstack-dev] [Barbican] Multiple KMIP servers on a single barbican

[Nathan Reller]

You would need to update the KMIPSecretStore or create a new
SecretStore to handle this. The logic should be behind the SecretStore
abstraction because Barbican only allows one active secret store.

I would think that the configuration file would have a listing of
available KMIP server URLs.

The URL as to where each key is stored would not be in the DTO but
rather in the metadata associated with a secret. The return calls for
the generate and store methods would return this metadata. Then all of
the other calls would need to parse the metadata to determine where
the secret is stored, so it would contact the correct KMIP server.

That's how I am envisioning it, but perhaps you have a better design
in which case I would vote for that one :)

-Nate

__
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

Re: [openstack-dev] Barbican : Retrieval of the secret in text/plain format generated from Barbican order resource

[Nathan Reller]

Asha,

When you say you want your key in ASCII does that also mean putting
the bytes in hex or base64 format? Isn't ASCII only 7 bits?

-Nate

On Mon, Jun 8, 2015 at 1:17 AM, Asha Seshagiri asha.seshag...@gmail.com wrote:
 Thanks John for your response.
 I am aware that application/octet-stream works for the retrieval of secret .
 We are utilizing the key generated from Barbican in our AES encryption
 algorithm . Hence we  wanted the response in text/plain format from Barbican
 since AES encryption algorithm would need the key of ASCII format which
 should be either 16,24 or 32 bytes.

 The AES encyption algorithms would not accept the binary format and even if
 binary  is converted into ascii , encoding is failing for few of the keys
 because some characters exceeeds the range of ASCII and for some keys  after
 encoding length exceeds 32 bytes  which is the maximum length for doing AES
 encryption.

 Would like to know the reason behind Barbican not supporting the retrieval
 of the secret in text/plain format generated from the order resource in
 plain/text format.

 Thanks and Regards,
 Asha Seshagiri

 On Sun, Jun 7, 2015 at 11:43 PM, John Wood john.w...@rackspace.com wrote:

 Hello Asha,

 The AES type key should require an application/octet-stream Accept header
 to retrieve the secret as it is a binary type. Please replace ‘text/plain’
 with ‘application/octet-stream’ in your curl calls below.

 Thanks,
 John


 From: Asha Seshagiri asha.seshag...@gmail.com
 Date: Friday, June 5, 2015 at 2:42 PM
 To: openstack-dev openstack-dev@lists.openstack.org
 Cc: Douglas Mendizabal douglas.mendiza...@rackspace.com, John Wood
 john.w...@rackspace.com, Reller, Nathan S. nathan.rel...@jhuapl.edu,
 Adam Harwell adam.harw...@rackspace.com, Paul Kehrer
 paul.keh...@rackspace.com
 Subject: Re: Barbican : Retrieval of the secret in text/plain format
 generated from Barbican order resource

 Hi All ,

 I am currently working on use cases for database and file Encryption.It is
 really important for us to know since my Encryption use case would be using
 the key generated by Barbican through order resource as the key.
 The encyption algorithms would not accept the binary format and even if
 converted into ascii , encoding is failing for few of the keys because some
 characters exceeeds the range of ASCII and for some key  after encoding
 length exceeds 32 bytes  which is the maximum length for doing AES
 encryption.
 It would be great if  someone could respond to the query ,since it would
 block my further investigations on Encryption usecases using Babrican

 Thanks and Regards,
 Asha Seshagiri


 On Wed, Jun 3, 2015 at 3:51 PM, Asha Seshagiri asha.seshag...@gmail.com
 wrote:

 Hi All,

 Unable to retrieve the secret in text/plain format  generated from
 Barbican order resource

 Please find the curl command and responses for

 Order creation with payload content type as text/plain :

 [root@barbican-automation ~]# curl -X POST -H
 'content-type:application/json' -H
 X-Auth-Token:9b211b06669249bb89665df068828ee8 \
  -d '{type : key, meta: {name: secretname2,algorithm: aes,
  bit_length:256,  mode: cbc, payload_content_type: text/plain}}'
  -k https://169.53.235.102:9311/v1/orders

 {order_ref:
 https://169.53.235.102:9311/v1/orders/727113f9-fcda-4366-9f85-93b15edd4680}

 Retrieval of the order by ORDER ID in order to get to know the secret
 generated by Barbican

 [root@barbican-automation ~]# curl -H 'Accept: application/json' -H
 X-Auth-Token:9b211b06669249bb89665df068828ee8 \
  -k
  https://169.53.235.102:9311/v1/orders/727113f9-fcda-4366-9f85-93b15edd4680
 {status: ACTIVE, sub_status: Unknown, updated:
 2015-06-03T19:08:13, created: 2015-06-03T19:08:12, order_ref:
 https://169.53.235.102:9311/v1/orders/727113f9-fcda-4366-9f85-93b15edd4680;,
 secret_ref:
 https://169.53.235.102:9311/v1/secrets/5c25525d-a162-4b0b-9954-90c4ce426c4e;,
 creator_id: cedd848a8a9e410196793c601c03b99a, meta: {name:
 secretname2, algorithm: aes, payload_content_type: text/plain,
 mode: cbc, bit_length: 256, expiration: null}, sub_status_message:
 Unknown, type: key}[root@barbican-automation ~]#


 Retrieval of the secret failing with the content type text/plain

 [root@barbican-automation ~]# curl -H 'Accept:text/plain' -H
 X-Auth-Token:9b211b06669249bb89665df068828ee8 -k
 https://169.53.235.102:9311/v1/secrets/5c25525d-a162-4b0b-9954-90c4ce426c4e/payload
 {code: 500, description: Secret payload retrieval failure seen -
 please contact site administrator., title: Internal Server Error}

 I would like to know wheather this is a bug from Barbican side  since
 Barbican allows creation of the order resource with text/plain as the
 payload_content type but the retrieval of the secret payload with the
 content type text/plain is not allowed.

 Any help would highly be appreciated.
 --
 Thanks and Regards,
 Asha Seshagiri




 --
 Thanks and Regards,
 Asha Seshagiri




 --
 Thanks and Regards,
 Asha Seshagiri

 

Re: [openstack-dev] [Barbican] Multiple KMIP servers on a single barbican

[Nathan Reller]

 You would just store the url in the DTO.

You will need to have the KMIP secret store return the KMIP server
that handled the request in the metadata that is returned to Barbican
Core.

 each kmip server url would need to be in the barbican-api.conf file?

I would assume that would be true.

 I'm trying to stray away from making multiple active plugins

That is good because only one active secret store is allowed to be
active in Barbican. You can add this functionality to the KMIP secret
store plugin. You would need to change it to have a list of valid KMIP
servers. Then when a request is received to store or generate a key
then you would need some algorithm to know which KMIP appliance to
choose. Then do everything as normal. At the end then return the KMIP
URL in the metatdata. Then all other operations would retrieve the
server URL before communicating with the KMIP appliance. I hope that
makes sense. If not then I will be around on IRC.

-Nate

On Fri, Jun 5, 2015 at 1:41 PM, Christopher N Solis cnso...@us.ibm.com wrote:
 Hey all.

 I wanted to get people's opinion on allowing barbican to talk to multiple
 KMIP servers.
 I got good advice from Nathan and John and it seems like it would be pretty
 easy keeping track of
 which secret resides in which KMIP applicance. You would just store the url
 in the DTO.
 However, in order for barbican to be aware of all KMIP servers wouldn't that
 mean that each
 kmip server url would need to be in the barbican-api.conf file? Or somewhere
 for barbican
 to know that multiple kmip servers are available? I noticed that there is a
 blueprint to introduce
 the concept of a single active and multiple inactive secret store plugins so
 I'm trying to stray away from
 making multiple active plugins.

 Regards,

   Chris Solis


 __
 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

Re: [openstack-dev] [barbican] Nominating Kaitlin Farr for barbican-core

[Nathan Reller]

+1

On Thu, May 21, 2015 at 12:29 PM, John Wood john.w...@rackspace.com wrote:
 +1
 
 From: Douglas Mendizábal douglas.mendiza...@rackspace.com
 Sent: Tuesday, May 19, 2015 7:09 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] [barbican] Nominating Kaitlin Farr for barbican-core

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 Hi All,

 I would like to nominate Kaitlin Farr for barbican-core.

 Kaitlin has been contributing to the project for a long time, both by
 contributing code to Barbican, python-barbicanclient and Castellan,
 and also by providing valuable reviews. [1]

 As a reminder to the rest of the core team, we use the process
 outlined in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add
 members to the barbican-core team.

 Thanks,
 Douglas Mendizábal

 [1] http://stackalytics.com/report/contribution/barbican-group/90
 -BEGIN PGP SIGNATURE-
 Comment: GPGTools - https://gpgtools.org

 iQIcBAEBCgAGBQJVW9CgAAoJEB7Z2EQgmLX7u6kP/22G3NqsnJmKRsnw065btt8z
 /Sb7OqFa2RKuIKk88a9yehwRuunh2YCdfLmXta1+XXpucghG9dbflfFVGU4/VujX
 VG/B3yUXTBYT2kn72mtwpKk4S6mYXBPn+fpKGR7iJrifYSg55XO7a2c2m/xIC8pO
 R9+d5/8ZztxS1UbmhNuqLwBDpo9FIG+5CoWOfYPTAQ1TxB/SIs2ltk4jzLaU05yb
 5LTG3uq5K3CT+LvM3Rl6SCZ7bIiTmaTuPsXMnqqLiqhya90U63VJGGXUE1yjW11G
 Kgm7yxUV8DkcESHXEe0aW8hpLMuGKda/f83XetGN27+YpM3/G1z8N656zLX9sF3t
 oVU7dWnARn9NsByFP9ASg8BCk8iWr/mCeB/fajwXT95C+OXAicNWn5jXKowXQhQH
 v4XaFrjafROLdJocgH0mfcoEbTXZXlsKyHYtnZdwAO+T06RNd21c/lnNiG1rMYeh
 2Yl48nzxxx33YprizHDRMEhABIb11HO040+j+EHNCvbsGSJGZIZmzzbxNe2QGXkx
 q++JvMBW60pPd6pi7nEVjbjSEZhb6f6xHs13/y+nZ9NCSNkUPx1UoxKz18JRtrLi
 /XDZLv6D92Trlaxae9mpVlWTM1elYPWSm3QVMxMrSP9wtAYbUIoq0PN+WwKk/1J7
 WaeQpFjA1SdFHj5uPNZk
 =1OIW
 -END PGP SIGNATURE-

 __
 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

__
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

Re: [openstack-dev] [Barbican] Nominating Chelsea Winfree for Barbican core

[Nathan Reller]

+1

On Thu, May 21, 2015 at 4:53 PM, Juan Antonio Osorio
jaosor...@gmail.com wrote:
 +1

 On Thu, May 21, 2015 at 11:05 PM, John Wood john.w...@rackspace.com wrote:

 +1

 
 From: Chad Lung chad.l...@gmail.com
 Sent: Sunday, May 17, 2015 6:34 PM
 To: openstack-dev@lists.openstack.org
 Subject: [openstack-dev] [Barbican] Nominating Chelsea Winfree for
 Barbican core

 Hi all,

 I'd like to nominate Chelsea Winfree for the Barbican core review team.

 Chelsea has been active in Barbican as a regular contributor of code and
 helping always needed documentation.
 http://stackalytics.com/?user_id=chelsea-winfreerelease=all

 As a reminder to barbican-core members we use the voting process outlined
 in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add members to our
 team.

 Thanks,

 Chad Lung
 EMC Cloud Services



 __
 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




 --
 Juan Antonio Osorio R.
 e-mail: jaosor...@gmail.com


 __
 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

Re: [openstack-dev] [barbican] Secret store API validation

[Nathan Reller]

 It seems we need to add some validation to the process

Yes, we are planning to add some validation checks in Kilo. I would
submit a bug report for this.

The big part of the issue is that we need to be clearer about the
expected input types to the API as well as the SecretStores. This was
a big topic of discussion at the summit. I hope to have a spec out
soon, I hope, that will address this issue.

-Nate

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican][OSSG] Mid Cycle Attendance / Crossover.

[Nathan Reller]

 How many people would want to attend both the OSSG mid-cycle and the Barbican 
 one?

+1

-Nate

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican] Nominating Juan Antonio Osorio Robles for barbican-core

[Nathan Reller]

+1 for me

-Nate

-

Hi All,

I would like to nominate Juan Antonio Osorio Robles to the barbican-core
team.

Juan has been consistently giving us very well thought out and constructive
reviews for Barbican, python-barbicanclient and barbican-specs.  It’s
obvious from his reviews that he cares deeply for the quality of the
Barbican project, and I think he will be a great addition to the core team.

As a reminder to barbican-core members, we use the voting process outlined
in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add members to our
team.

References:

http://stackalytics.com/report/contribution/barbican-group/90

Thanks,
Douglas

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican] Nominating Steve Heyman for barbican-core

[Nathan Reller]

+1 for me

-Nate

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack] [Barbican] [Cinder] Cinder and Barbican

[Nathan Reller]

 is Cinder capable today to use Barbican for encryption?

Yes, Cinder has a KeyManager abstraction, and one of the implementations is
Barbican. Checkout cinder.keymgr.barbican.py. We have successfully used
Barbican within Cinder.

I think the python-barbicanclient has recently changed. This change has
temporarily broken the code, but we plan to submit a patch to fix that soon.

-Nate

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican] KMIP support

[Nathan Reller]

 I was wondering about the progress of KMIP support in Barbican?

As John pointed out, JHU/APL is working on adding KMIP support to Barbican.
We submitted the first CR to add a Secret Store interface into Barbican.
The next step is to add a KMIP implementation of the Secret Store.

 Is this waiting on an open python KMIP support?

We are working in parallel to add KMIP support to Barbican and to release
an open source version of a Python KMIP library. We would like to have both
out by Juno.

 Also, is the “OpenStack KMIP Client” ever going to be a thing?
 (https://wiki.openstack.org/wiki/KMIPclient)

That work was not proposed by us, so I can't comment on the status of that.
Right now our path forward is to support Barbican by adding a KMIP Secret
Store.

-Nate

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev