VMware: avoid vCenter plaintext passwords in nova.conf
The primary concern is that vCenter usernames and passwords are stored in plain text inside the nova.conf file.
The proposed solution is to give a user the capability to put the vCenter user and password in the keystone credential store instead of nova.conf. The keystone credential store database access is secured through use of the nova user and password.
The vmware driver would first check the 'vmware' section of the nova.conf for the host_ip, host_username, and host_password. Only in the case where host_username and/or host_password are not found in nova.conf, does the driver contact keystone to search for an appropriate credential.
Part of this conversation: https:/
Blueprint information
- Status:
- Started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- Shawn Hartsock
- Direction:
- Needs approval
- Assignee:
- Eric Brown
- Definition:
- Pending Approval
- Series goal:
- Proposed for ocata
- Implementation:
-
Needs Code Review
- Milestone target:
- None
- Started by
- Shawn Hartsock
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
IBM has something internally that we've been using since Grizzly that I think might be the same as your quick and dirty solution for Icehouse until something better can be fleshed out long-term with keystone, barbican, and/or password keyrings in oslo-incubator. I'll work on pushing an oslo.config WIP patch for that to get you an idea if it's something that has legs. I've been looking to move this code upstream for awhile now, just never had the right vehicle. -- mriedem
The scope of this blueprint appears to be encrypted passwords in nova.conf, but the review that's posted goes in a different direction. And according to the linked etherpad the nova.conf solution is relying upon changes to oslo.config in which case this should be set as a dependent blueprint of something in oslo. --alaski
Plan is to modify the Nova vmware driver to look up its necessary user/pwd in the keystone credential store. It would only do so if the host_username or host_password options were not specified in the nova.conf. The host_ip would always need to be specified. Its an optional solution that enables a customer to avoid the vcenter password in the nova.conf.
It does not attempt to address all other passwords that could be in any of the services' conf files (the oslo based solution). I've been told barbican can potentially help to address that.
Documented this design in the blueprint's etherpad under A.5. And I've already created a patch (https:/
Since this is going in a different direction than the title and description above would indicate, could you update the blueprint to match the new direction. I think the current direction is fine, but I would like the scope of the blueprint to be accurately represented to help reviewers out. --alaski
deferred from icehouse-3 to "next": http://
Gerrit topic: https:/
Addressed by: https:/
VMware: Store vCenter passwords in keystone credential store
Removed from next, as next is now reserved for near misses from the last milestone --johnthetubaguyIBM has something internally that we've been using since Grizzly that I think might be the same as your quick and dirty solution for Icehouse until something better can be fleshed out long-term with keystone, barbican, and/or password keyrings in oslo-incubator. I'll work on pushing an oslo.config WIP patch for that to get you an idea if it's something that has legs. I've been looking to move this code upstream for awhile now, just never had the right vehicle. -- mriedem
The scope of this blueprint appears to be encrypted passwords in nova.conf, but the review that's posted goes in a different direction. And according to the linked etherpad the nova.conf solution is relying upon changes to oslo.config in which case this should be set as a dependent blueprint of something in oslo. --alaski
Plan is to modify the Nova vmware driver to look up its necessary user/pwd in the keystone credential store. It would only do so if the host_username or host_password options were not specified in the nova.conf. The host_ip would always need to be specified. Its an optional solution that enables a customer to avoid the vcenter password in the nova.conf.
It does not attempt to address all other passwords that could be in any of the services' conf files (the oslo based solution). I've been told barbican can potentially help to address that.
Documented this design in the blueprint's etherpad under A.5. And I've already created a patch (https:/
Since this is going in a different direction than the title and description above would indicate, could you update the blueprint to match the new direction. I think the current direction is fine, but I would like the scope of the blueprint to be accurately represented to help reviewers out. --alaski
deferred from icehouse-3 to "next": http://
Gerrit topic: https:/
Addressed by: https:/
VMware: Store vCenter passwords in keystone credential store
Removed from next, as next is now reserved for near misses from the last milestone --johnthetubaguy
Marking this blueprint as definition: Drafting. If you are still working on this, please re-submit via nova-specs. If not, please mark as obsolete, and add a quick comment to describe why. --johnthetubaguy (20th April 2014)
Gerrit topic: https:/
Addressed by: https:/
VMware: Store vCenter passwords in keystone credential store
No spec submition linked here, please submit a spec and consider this for juno-2, un-targeting blueprint from juno-1 --johnthetubaguy (28th May 2014)
Addressed by: https:/
VMware: store vCenter user/password in Keystone
Work Items
Dependency tree
* Blueprints in grey have been implemented.
