OpenStack VM user_id


#1

Hi everyone,

I’m looking at collecting user-data from OpenStack of VMs provisioned by ManageIQ. I have an OpenStack account associated with each ManageIQ user, and ideally I’d like this account reflected in the OpenStack VM user_id property.

OpenStack exposes this property as the user_id when doing a nova show , ie (from OpenStack);

$ nova show <vm-id>
-----------------------------------------------------------------------------------
| Property                       | Value                                                     
----------------------------------------------------------------------------------- 
.                                                                                              
.                                                                                                     
user_id                           | 60dde0bc12b34da39bd56037ee5718e 
-----------------------------------------------------------------------------------

Since I’ve provided the admin credentials to ManageIQ, this user_id always corresponds to the admin user.

Is there any way I can customize the credentials that ManageIQ uses to provision to OpenStack, or any other provider? If I can customize the credentials during openstack_PreProvisioning/CustomizeRequest, then the correct user_id would be reflected when I do a nova show

I’ve tried working around this problem by setting the user_id during MIQ post-provisioning with a fog call, ie;

require 'fog'

nova = Fog::Compute::OpenStack.new ({
  :openstack_auth_url => 'http://192.168.100.1:5000/v2.0/tokens',
  :openstack_username => 'admin',
  :openstack_api_key => 'api_key',
  :openstack_tenant => 'tenant' })

server = nova.servers.pop
nova.update_server(server.id, {"user_id" => "422640ff7cad47a9987f00cd60146cf2"})

However, this fails silently, simply leaving the user_id unchanged.

Any assistance is appreciated.

Shane


#2

@jockey10 Hello, OpenStack doesn’t support impersonation in this way. The only way to do this, is signing as a different user and using that Keystone token to provision the VM.

At some point, you should be able to add multiple OpenStack users to ManageIQ and pick a user for doing a VM deployment. But it’s not possible right now.

For Vm deployment, we are using a default credentials of a provider, which are loaded here https://github.com/ManageIQ/manageiq/blob/3ae33750da55fed6e36f148bc534851bffbd932d/app/models/manageiq/providers/openstack/cloud_manager/provision/cloning.rb#L42-42 , that is not possible to change right now. With small changes to code, you could be able to just pass different credentials from automate, that would overwrite the default. But that would mean, you would have to store the credentials somewhere, e.g. mapping OpenStack users to ManageIQ users, but the credentials would need to be inserted manually, since we can’t fetch them from the API.


#3

@jockey10 the changes needed for changing creds in automate in 3 short steps would be:

  1. Add user id and password to connection_options, from options, which is settable by set_option from automate. (also domain_id for keystone v3)
  1. Load creds from options, that will overwrite the ones from provider (these are the connection_options passed in step 1)

domain_id:

user id and password:

  1. Make sure you don’t have your custom password anywhere in logs

#4

Thanks for the awesome reply @Ladas, that’s exactly what I was looking for!

I understand how to override the connection_options, however I’m not really clear on step 2 - do I need to override the username/ password/ domain_id passed to the OpenstackHandle during initialization (which doesn’t look like it’s exposed in any automate methods?), or will the ManageIQ provisioning state machine override this for me?

Thanks again!

Shane


#5

@jockey10 you will need to do something like this:

openstack_username = opts.delete(:username) || username
raw_service = self.class.raw_connect_try_ssl(openstack_username …

so it will take the options set from e.g. automate, instead of the default credentials


Remember that this would be a quick hacky solution. :slight_smile: The actual user impersonation will be implemented different way. Most probably, we will be fetching users from OpenStack and prompting users for credentials if they will want to use that OpenStack user for some operation. Then from automate, we will be passing a User object, instead of credentials.