[security][barbican][manila] hiding back end and service user credentials
In manila -- and so far as I can tell, other projects -- service user and back end (storage devices, security service) credentials appear plaintext in configuration files and in database tables. These are not accessible to ordinary OpenStack users but some cloud deployers nonetheless have concerns about this exposure and have asked us to tighten things up. So I want to check for best practices from other projects. I doubt this is a manila-specific concern -- e.g. is barbican already being used today by some projects to protect information of this sort? Thanks, -- Tom Barron
Hey, So, this is not something that Barbican can directly help with, given that it needs keystone for authentication. So, if you want to protect the keystone user/password; you get into a chicken and egg problem then. That being said, there is work being done to address this issue. Moises Guimaraes has been working to enable oslo.config to read the configuration values via drivers; and one of those drivers is castellan (which allows you to use something like Vault to store secrets). I'm sure he'll be able to provide you more details if needed. The next step is to integrate this work to the deployment engines. Best regards On 3/1/19 6:13 PM, Tom Barron wrote:
In manila -- and so far as I can tell, other projects -- service user and back end (storage devices, security service) credentials appear plaintext in configuration files and in database tables. These are not accessible to ordinary OpenStack users but some cloud deployers nonetheless have concerns about this exposure and have asked us to tighten things up.
So I want to check for best practices from other projects. I doubt this is a manila-specific concern -- e.g. is barbican already being used today by some projects to protect information of this sort?
Thanks,
-- Tom Barron
On 01/03/19 18:25 +0200, Juan Antonio Osorio Robles wrote:
Hey,
So, this is not something that Barbican can directly help with, given that it needs keystone for authentication. So, if you want to protect the keystone user/password; you get into a chicken and egg problem then.
That being said, there is work being done to address this issue.
Moises Guimaraes has been working to enable oslo.config to read the configuration values via drivers; and one of those drivers is castellan (which allows you to use something like Vault to store secrets).
I'm sure he'll be able to provide you more details if needed.
The next step is to integrate this work to the deployment engines.
Thanks!
Best regards
On 3/1/19 6:13 PM, Tom Barron wrote:
In manila -- and so far as I can tell, other projects -- service user and back end (storage devices, security service) credentials appear plaintext in configuration files and in database tables. These are not accessible to ordinary OpenStack users but some cloud deployers nonetheless have concerns about this exposure and have asked us to tighten things up.
So I want to check for best practices from other projects. I doubt this is a manila-specific concern -- e.g. is barbican already being used today by some projects to protect information of this sort?
Thanks,
-- Tom Barron
On 3/1/19 10:13 AM, Tom Barron wrote:
In manila -- and so far as I can tell, other projects -- service user and back end (storage devices, security service) credentials appear plaintext in configuration files and in database tables. These are not accessible to ordinary OpenStack users but some cloud deployers nonetheless have concerns about this exposure and have asked us to tighten things up.
So I want to check for best practices from other projects. I doubt this is a manila-specific concern -- e.g. is barbican already being used today by some projects to protect information of this sort?
This has been a pretty common concern for years in OpenStack. The good news is that this cycle we added a feature to Castellan that allows config secrets to be stored securely. Unfortunately, it doesn't appear to have been added to the project docs[0] (ugh, not even a release note), but you can see the documentation in the docstring for the file[1]. I'll work on getting the published docs updated. There is also a less secure, but potentially simpler option in oslo.config itself[2]. It allows secrets to be stored remotely and retrieved over HTTP(S). Obviously anyone who is able to read the config file can probably curl the URL too, but at least you won't accidentally copy-paste secrets while debugging. That takes care of the config aspect. I can't comment on what gets stored in the database though. Hopefully someone else has advice on that. -Ben 0: https://bugs.launchpad.net/castellan/+bug/1818258 1: https://github.com/openstack/castellan/blob/master/castellan/_config_driver.... 2: https://docs.openstack.org/oslo.config/rocky/reference/drivers.html#remote-f...
Thanks,
-- Tom Barron
On 01/03/19 10:31 -0600, Ben Nemec wrote:
On 3/1/19 10:13 AM, Tom Barron wrote:
In manila -- and so far as I can tell, other projects -- service user and back end (storage devices, security service) credentials appear plaintext in configuration files and in database tables. These are not accessible to ordinary OpenStack users but some cloud deployers nonetheless have concerns about this exposure and have asked us to tighten things up.
So I want to check for best practices from other projects. I doubt this is a manila-specific concern -- e.g. is barbican already being used today by some projects to protect information of this sort?
This has been a pretty common concern for years in OpenStack. The good news is that this cycle we added a feature to Castellan that allows config secrets to be stored securely. Unfortunately, it doesn't appear to have been added to the project docs[0] (ugh, not even a release note), but you can see the documentation in the docstring for the file[1]. I'll work on getting the published docs updated.
Thanks, Ben. I'm now watching that doc bug and have the PR. This sounds like the way to go for the config part of the problem.
There is also a less secure, but potentially simpler option in oslo.config itself[2]. It allows secrets to be stored remotely and retrieved over HTTP(S). Obviously anyone who is able to read the config file can probably curl the URL too, but at least you won't accidentally copy-paste secrets while debugging.
That takes care of the config aspect. I can't comment on what gets stored in the database though. Hopefully someone else has advice on that.
Well I also need to gain an understanding of why we store this info, which presumably started as config, in the DB in the first place.
-Ben
0: https://bugs.launchpad.net/castellan/+bug/1818258 1: https://github.com/openstack/castellan/blob/master/castellan/_config_driver.... 2: https://docs.openstack.org/oslo.config/rocky/reference/drivers.html#remote-f...
Thanks,
-- Tom Barron
participants (3)
-
Ben Nemec
-
Juan Antonio Osorio Robles
-
Tom Barron