[openstack-dev] [barbican][castellan] Stepping down from core
Hi Barbicaneers, I will be moving on to other projects at work and will not have time to contribute to OpenStack anymore. I am stepping down as core reviewer as I will not be able to maintain my responsibilities. It's been a great 4.5 years working on OpenStack and a fulfilling 3 years as a Barbican core reviewer. The recent growing interest in Castellan and Barbican for key management to support new security features is encouraging. The rest of the Barbican team will do a great job managing Barbican, Castellan, and Castellan-UI. If you have any pressing concerns or questions, you can still reach me by email. Thanks so much, Kaitlin Farr __ 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] Janney 2.0 "Data Protection in OpenStack" Summary Presentation
Hi everyone, I will be presenting a recap of the "Data Protection in OpenStack" presentation from IEEE CLOUD on Monday, September 25th at 4 PM in Central Spark. The OpenStack team wrote the paper, and the funding came from the Janney 2.0 "Engage" awards. https://aplweb.jhuapl.edu/news/Pages/JanneyTalks_KaitlineFarr.aspx Thanks! Kaitlin __ 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] [nova][cinder][barbican] Why is Cinder creating symmetric keys in Barbican for use with encrypted volumes?
Lee, a few thoughts on your previous email. Many of the details I think you already know, but I'm clarifying for posterity's sake: > However the only supported disk encryption formats on the front-end at > present are plain (dm-crypt) and LUKS, neither of which use the supplied > key to directly encrypt or decrypt data. Plain derives a fixed length > master key from the provided key / passphrase and LUKS uses PBKDF2 to > derive a key from the key / passphrase that unlocks a separate master > key. This is true. When we retrieve the key from Barbican, we don't use the key bytes themselves to encrypt the volume. We format the key as a string and use it as a passphrase. You can see this for both the LUKS encryptor [2] and the cryptsetup encryptor [3]. We pass in a "--key-file=-" parameter (which indicates the "keyfile" should be read from stdin) and then pass in the formatted key. But according to the documentation, "keyfile" is a misnomer. I think it would be clearer if dm-crypt renamed it to something like "passwordfile" because it's still used by dm-crypt and luks as a passphrase [4]. > I also can't find any evidence of these keys being used directly on the > backend for any direct encryption of volumes within c-vol. Happy to be > corrected here if there are out-of-tree drivers etc that do this. There are two options for control_location for the volume encryption type: 'front-end' (nova) and 'back-end' (cinder) [5]. 'front-end' is the default, and I know where the code logic is that sets up the encryptors for the front-end, now in os-brick [1]. But I cannot find any logic that handles the case for 'back-end'. I would think the 'back-end' logic would be found in Cinder, but I do not see it. I am under the impression that it was just a placeholder for future functionality. > IMHO for now we are better off storing a secret passphrase in Barbican > for use with these encrypted volumes, would there be any objections to > this? Are there actual plans to use a symmetric key stored in Barbican > to directly encrypt and decrypt volumes? It sounds like you're thinking that using a key manager object with the type "passphrase" is closer to how the encryptors are using the bytes than using the "symmetric key" type, but if you switch over to using passphrases, where are you going to generate the random bytes? Would you prefer the user to input their own passphrase? The benefit of continuing to use symmetric keys as "passphrases" is that the key manager can randomly generate the bytes. Key generation is a standard feature of key managers, but password generation Is not. On a side note, I thought the latest QEMU encryption feature was supposed to have support for passing in key material directly to the encryptors? Perhaps this is not true and I am misremembering. Hopefully that helps, Kaitlin 1. https://github.com/openstack/os-brick/blob/6cf9b1cd689f70a2c50c0fa83a9a9f7c502712a1/os_brick/encryptors/__init__.py#L62 2. https://github.com/openstack/os-brick/blob/6cf9b1cd689f70a2c50c0fa83a9a9f7c502712a1/os_brick/encryptors/luks.py#L63-L87 3. https://github.com/openstack/os-brick/blob/6cf9b1cd689f70a2c50c0fa83a9a9f7c502712a1/os_brick/encryptors/cryptsetup.py#L104-L129 4. https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#Keyfiles 5. https://docs.openstack.org/admin-guide/dashboard-manage-volumes __ 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 Jeremy Liu for Barbican Core
> Barbicaneers, please indicate your agreement by responding with +1. +1 from me. Jeremy has been a valuable contributor for the past several development cycles. Kaitlin __ 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][castellan] How to share secrets in barbican
> As i known, the secrets are saved in a user's domain, and other > project/user can not retrieve the secrets. > But i have a situation that many users need retrieve a same secret. > > After looking into the castellan usage, I see the method that saving the >credentials in configuration, > then all operators use this pre-created user to create/retrieve secrets. > I want to know, is this way typical and easy-accepted? Does other projects >face this issue? By default, the secrets in Barbican are available at the project-level [1]. I am not sure specifically which project or feature you are referring to that all users need to access to one secret, but I would suggest that editing the Barbican RBAC policy or ACL is a more elegant solution than storing username/pw in the conf file. You can find more details about RBAC at [2] and a sample policy.json file at [3]. Kaitlin Farr 1. https://developer.openstack.org/api-guide/key-manager/acls.html#default-acl 2. https://docs.openstack.org/developer/barbican/admin-guide-cloud/access_control.html 3. https://github.com/openstack/barbican/blob/master/etc/barbican/policy.json __ 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] [oslo][barbican][castellan] Proposal to rename Castellan to oslo.keymanager
This thread has generated quite the discussion, so I will try to address a few points in this email, echoing a lot of what Dave said. Clint originally explained what we are trying to solve very well. The hope was that the rename would emphasize that Castellan is just a basic interface that supports operations common between key managers (the existing Barbican back end and other back ends that may exist in the future), much like oslo.db supports the common operations between PostgreSQL and MySQL. The thought was that renaming to have oslo part of the name would help reinforce that it's just an interface, rather than a standalone key manager. Right now, the only Castellan back end that would work in DevStack is Barbican. There has been talk in the past for creating other Castellan back ends (Vault or Tang), but no one has committed to writing the code for those yet. The intended proposal was to rename the project, maintain the current review team (which is only a handful of Barbican people), and bring on a few Oslo folks, if any were available and interested, to give advice about (and +2s for) OpenStack library best practices. However, perhaps pulling it under oslo's umbrella without a rename is blessing it enough. In response to Julien's proposal to make Castellan "the way you can do key management in Python" -- it would be great if Castellan were that abstract, but in practice it is pretty OpenStack-specific. Currently, the Barbican team is great at working on key management projects (including both Barbican and Castellan), but a lot of our focus now is how we can maintain and grow integration with the rest of the OpenStack projects, for which having the name and expertise of oslo would be a great help. Thanks, Kaitlin __ 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] [oslo][barbican][castellan] Proposal to rename Castellan to oslo.keymanager
Proposed library name: Rename Castellan to oslo.keymanager Proposed library mission/motivation: Castellan's goal is to provide a generic key manager interface that projects can use for their key manager needs, e.g., storing certificates or generating keys for encrypting data. The interface passes the commands and Keystone credentials on to the configured back end. Castellan is not a service and does not maintain state. The library can grow to have multiple back ends, as long as the back end can authenticate Keystone credentials. The only two back end options now in Castellan are Barbican and a limited mock key manager useful only for unit tests. If someone wrote a Keystone auth plugin for Vault, we could also have a Vault back end for Castellan. The benefit of using Castellan versus using Barbican directly is Castellan allows the option of swapping out for other key managers, mainly for testing. If projects want their own custom back end for Castellan, they can write a back end that implements the Castellan interface but lives in their own code base, i.e., ConfKeyManager in Nova and Cinder. Additionally, Castellan already has oslo.config options defined which are helpful for configuring the project to talk to Barbican. When the Barbican team first created the Castellan library, we had reached out to oslo to see if we could name it oslo.keymanager, but the idea was not accepted because the library didn't have enough traction. Now, Castellan is used in many projects, and we thought we would suggest renaming again. At the PTG, the Barbican team met with the AWG to discuss how we could get Barbican integrated with more projects, and the rename was also suggested at that meeting. Other projects are interested in creating encryption features, and a rename will help clarify the difference between Barbican and Castellan. Existing similar libraries (if any) and why they aren't being used: N/A Reviewer activity: Barbican team Who is going to use this (project involvement): Cinder, Nova, Sahara, and Glance already use Castellan, Swift has a patch that integrates Castellan. Proposed adoption model/plan: The Castellan library was already created and produces a functional and useful artifact (a pypi release) and is integrated into various OpenStack projects and now it is proposed that the library be moved into the Oslo group's namespace by creating a fork of Castellan, clean up a few things, create a new oslo.keymanager release on pypi, and change the projects to use oslo.keymanager. Thanks, Kaitlin Farr Software Engineer The Johns Hopkins University Applied Physics Laboratory __ 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] [nova][cinder] Deprecating ConfKeyManager (fixed-key key manager)
>> Aiming toward tests that mirror real-world deployment is certainly a >> good thing, but I don't think we should remove ConfKeyManager. >> >> We will want to maintain the ability to test these Cinder/Nova code >> paths in development environments or in some automated environments >> without requiring additional services to be configured. >> >> We can address this by having ConfKeyManager emit warning messages >> indicating that it isn't for production environments. > > Right, effectively the fixed key manager was a Testing Fixture for us. > That's really important because it reduces the number of moving parts > when testing this stuff as a full stack. > > -Sean Ok, I am looking into a way to keep a fixed-key back end, but it will not live in Castellan. Even if we keep the fixed-key back end, what about adding a gate that tests the encryption features using Barbican? Would the community be supportive if I added that gate? Kaitlin __ 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] [nova][cinder] Deprecating ConfKeyManager (fixed-key key manager)
> The fixed key manager is useful for easy testing (we're using it in the > gate in places where barbican isn't available). Is there anything > equivalent with Catellan? > > -Sean > > -- > Sean Dague > http://dague.net There is no fixed-key back end with Castellan. I agree that using a fixed key makes for very easy testing, but the tests use a configuration (ConfKeyManager) that should not be used in deployment. The tests could be made much more useful if they used a more realistic configuration (Barbican). Adding a gate that tests using DevStack with Barbican enabled would be a more valuable than the existing tests for two reasons: 1. ConfKeyManager could be removed. 2. It would test the feature configured more closely to how a deployment would actually look. As part of this change to deprecate ConfKeyManager and integrate Castellan, I would like to add this new gate. -Kaitlin __ 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] [nova][cinder] Deprecating ConfKeyManager (fixed-key key manager)
All, Please reply or send me an email if you are using the ConfKeyManager (fixed-key key manager) in deployment for volume encryption or ephemeral storage encryption. You can check this by looking at the [keymgr] section, api_class entry of nova.conf or cinder.conf. The ConfKeyManager was only intended for testing and I am working on deprecating it. I would like to gauge the number of people using that backend, because it may affect the deprecation strategy. This is the start of the effort to replace the duplicated key manager code with Castellan [1], a key manager interface library that allows the user to swap out different backends, such as Barbican. While Castellan is based on the key managers built into Nova and Cinder, it does not have the fixed-key backend. That backend is insecure. A single key is used for all volumes. If the key is compromised, all of the encrypted data is easily decrypted. See Joel Coffman's comments on the Nova spec [2]. Deprecating the fixed-key key manager would need to occur before Castellan is integrated. Again, please let me know if you use the ConfKeyManager and you actively use the volume encryption and encrypted cinder volume features in a deployment Other feedback is also welcome. I am also creating a separate thread with this info on the operators mailing list. Thanks, Kaitlin Farr 1. Castellan source code. https://github.com/openstack/castellan 2. Castellan integration Nova spec. https://review.openstack.org/#/c/247561/ 3. Castellan integration Cinder spec. https://review.openstack.org/#/c/247577/ __ 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] [cinder][nova]Move encryptors to os-brick
Hi Lisa, In regards to your comment about the duplication of key management code in Cinder and Nova, there was a long-term plan to replace that code with a shared library when the encryption feature was implemented. The key manager code has been moved to its own library, Castellan [1]. The plan to replace the key manager code with Castellan has been outlined in a Nova spec [2] and Cinder spec [3]. 1. https://github.com/openstack/castellan 2. https://review.openstack.org/#/c/247561/ 3. https://review.openstack.org/#/c/247577/ I hope that helps, Kaitlin Farr -Original Message- From: Li, Xiaoyan [mailto:xiaoyan.li at intel.com] Sent: Monday, November 23, 2015 8:57 PM To: OpenStack Development Mailing List (not for usage questions); Daniel P. Berrange Subject: Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick Hi, Except creating encrypted volume from images, uploading encrypted volumes to image, as Duncan said there is desire to migrate volumes between encrypted and unencrypted type. https://review.openstack.org/#/c/248593/ And key magagment codes are duplicated in Cinder and Nova: https://github.com/openstack/cinder/tree/master/cinder/keymgr https://github.com/openstack/nova/tree/master/nova/keymgr Best wishes Lisa __ 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] [Barbican] Nominating Dave Mccowan for Barbican core
+1, Dave has been a key contributor, and his code reviews are thoughtful. Kaitlin 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
Re: [openstack-dev] [barbican] Utilizing the KMIP plugin
Hi Chris,
I would be happy to help you with the trouble you've encountered using the
KMIP plugin. From what you've described, it sounds like you have everything
set up correctly. If you've specified kmip_plugin under
enabled_secret_store_plugins, then the reason it would give you
SecretStorePluginsNotConfigured is if it had encountered an error in the
KMIPSecretStore __init__ method. Just to be sure, the permissions of the file
that you specified under the "keyfile" config option are 400, correct? Are
there any other error messages earlier in the logs?
Feel free to pass along your barbican-api.conf (changing any proprietary
information, of course) if you'd like another set of eyes to look at it.
Thanks,
Kaitlin Farr
Software Engineer
JHU/APL
-
Message: 39
Date: Fri, 3 Apr 2015 15:03:10 -0500
From: Christopher N Solis
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [barbican] Utilizing the KMIP plugin
Message-ID:
Content-Type: text/plain; charset="us-ascii"
Hello!
I am having some trouble with the kmip_plugin and would like some help.
When I make a call to barbican to store a secret it returns the following
error:
2015-04-03 12:33:17,279 - barbican.api.controllers - ERROR - Secret
creation failure seen - please contact site administrator.
Traceback (most recent call last):
File "/home/swift/barbican/barbican/api/controllers/__init__.py", line
98, in handler
return fn(inst, *args, **kwargs)
File "/home/swift/barbican/barbican/api/controllers/__init__.py", line
84, in enforcer
return fn(inst, *args, **kwargs)
File "/home/swift/barbican/barbican/api/controllers/__init__.py", line
140, in content_types_enforcer
return fn(inst, *args, **kwargs)
File "/home/swift/barbican/barbican/api/controllers/secrets.py", line
294, in on_post
transport_key_id=data.get('transport_key_id'))
File "/home/swift/barbican/barbican/plugin/resources.py", line 101, in
store_secret
key_spec=key_spec, plugin_name=plugin_name)
File "/home/swift/barbican/barbican/plugin/interface/secret_store.py",
line 477, in _check_plugins_configured
raise SecretStorePluginsNotConfigured()
SecretStorePluginsNotConfigured: No secret store plugins have been
configured
In the barbican-api.conf file I have set enabled_secretstore_plugins to
kmip_plugin.
I have also updated the kmip_plugin part of the file to point to the host
and port where my kmip Key Manager is running
with all the required credentials and ssl certs.
I also made sure the ssl requirements are set to permissions 400.
Is there something I am missing that is causing this problem?
Thank You!!
- Christopher Solis
Regards,
CHRIS SOLIS
Software Developer - Cloud Infrastructure Services Security
Phone: 1-512-286-6458 | Mobile:IBM
1-210-844-5913
E-mail: cnso...@us.ibm.com 11501 Burnet Rd
Austin, TX 78758-3400
United States
__
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] Using KMIP with Barbican (Utkarsh Simha)
Hi Utkarsh, Specifying "kmip_plugin" in the barbican-api.conf is the correct way to configure the plugin. In my previous debugging experience, I've found that I get CryptoPluginNotFound if an error occurred during the plugin's __init__ method. For the KMIP plugin, this means the key file permissions were not set to 400 or the PyKMIP KMIPProxy object could not be created with the configuration options set. To debug this further, we'll need to log at the logs for more clues. Hope this helps! Kaitlin Farr Johns Hopkins University Applied Physics Laboratory -- Date: Mon, 23 Mar 2015 16:56:43 +0530 From: Utkarsh Simha To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [barbican] Using KMIP with Barbican Message-ID: Content-Type: text/plain; charset=UTF-8 Hello! I was wondering how it is possible to use an external Key Management Server with Barbican? I have configured the barbican-api.conf file for the KMIP Plugin and also set "enabled_crypto_plugins" to "kmip_plugin", but it says "CryptoPluginNotFound" Any help is appreciated! Thank you :) -- Regards -- * __ 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
