OpenStack Shared File Systems Service (Manila)

security service password is stored in plaintext

Bug #1817316 reported by Maurice Escher on 2019-02-22

This bug affects 3 people

Affects		Status	Importance	Assigned to	Milestone
	OpenStack Shared File Systems Service (Manila)	Triaged	Wishlist	Felipe Rodrigues

Bug Description

Hi,

I want to get your opinion on the password field of security services.
I know I can protect security_service:show and detail via policy so that only a group of users can see it.
Additionally it can be visible at share server backend details. I can protect that, too.

But manila admins and anyone with database access can see the password in plaintext.

Do you see it feasible to use a key manager (like barbican) to store the password in an encrypted fashion?

By the way: we already guide our human users to give the technical user, who authenticates with that password, as few permissions as possible, but sometimes you find domain admin or the human user's personal credentials in there, oops. Such people have to be protected from themselves.

Thanks,
Maurice

Revision history for this message

Tom Barron (tpb) wrote on 2019-03-07:

I've added this to the Train PTG planning etherpad.

One idea would be to use oslo config Castellan support [2] to hold an encryption key in a vault and then we could use that to AES encrypt/decrypt the service user password when it is stored in the DB.

[1] https://etherpad.openstack.org/p/manila-denver-train-ptg-planning

[2] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003409.html

Changed in manila:
importance:	Undecided → Wishlist

Jason Grosso (jgrosso) on 2019-03-22

Changed in manila:
status:	New → Triaged

Revision history for this message

Goutham Pacha Ravi (gouthamr) wrote on 2019-05-02:

Hi Maurice,

Do you ever need to see the security service password? Can we stop exposing it in the API and would anyone care?

This was discussed at the manila Project Technical Gathering and we're of the opinion that we can just remove this from the API, since the secret never originated in the API.

We're okay with stopping storing the security service password in the database. We can discuss here how this will work in terms of migration.

Thanks,
Goutham

Revision history for this message

Maurice Escher (maurice-escher) wrote on 2019-05-05:

Hi Goutham, we don't need to see the password. I'm okay with stopping exposing it for users as well as admins.

I'm unsure, wether it should be stored at all, i.e. pass it to the driver and the back end and forget.
In my mind it is okay to have to re-enter the password if I want to update any other security service parameter, too. But I can only speak for the usage in the netapp driver.

Cheers,
Maurice

Revision history for this message

Vida Haririan (vhariria) wrote on 2020-12-03:

Additional comments http://eavesdrop.openstack.org/meetings/manila/2020/manila.2020-12-03-15.00.log.html