I created a few machines in Openstack using the Rancher API. For this I had to provide my Openstack user and password.
Using: /v1/projects/1a5/hosts/1h1/physicalhost I can see my Openstack password in plain text. I suppose it’s not the end of the world as long as the openstack password is not also my corp account password. But still this will be a bit difficult to manage. I was experimenting with creating a “read only” user to see if this information was hidden from that user, but it’s not.
I don’t know the solution here, but I don’t know how I can give people access to the UI if they can use it to gain access to the underlying openstack cluster.
aaww… that’s seriously broken. Passwords should never be presented in the clear. I do see the need to get the password out somehow, for when it is to be used, but that ought to be hardened down tight. Guess it’s on the todo-list. (but until then it would probably be good with a warning/notice in the UI or somesuch about leaking passwords…)
This is one of the reasons OpenStack isn’t an option in the UI today even though I built the form for it a while ago… In all the other providers the credential is typically a randomly generated API key that is less valuable or already shared among the team.
The credentials need to be stored to give to docker-machine to create and delete the machine. We added an interface for hashing or encrypting arbitrary database fields but it hasn’t been applied here yet. Along with that it would be marked not readable from the API.
The other thing that needs them is cloning a host, as that is all client side. It will either just be changed to require you to reenter the credentials every time, or pre-fill with a per-user setting value.
Actually, I didn’t use the API directly, I used the UI, but the openstackConfig data I put into the UI contains my password.
Secondly, was logged in to the UI as another User with “read only” access to the environment. For some reason, I thought his role would not have access to the API data. I clicked the link on the API & Keys page and then I was able to find and click the projects/1a5/hosts/1h1/physicalhost link.
@vincent, it’s clear that you are on top of this, so that’s great news. A little more sophisticated RBAC may help here as well. I can imagine we may want a user role that can’t see the raw data that can be seen from clicking the link on the API & Keys page. But I know RBAC secnarios can spin out of control so I’ll wait and see what you come up with. You have all done such a great job with Rancher, I’m confident you have provide a good solution here as well.
Have you considered hiding the Endpoint link on the API & Keys for all but Admin users? It may
be an easy short term “hack” that will allow openstack users to give UI access to their users be creating “User” accounts. . Just a thought…
The “read-only” user can also download the machine config. I could not open a shell directly from the UI, but the machine config would give this “read-only” user direct SSH access to the host.
Clicking on the endpoint is using the API, we’ve just made it so convenient to experiment with you didn’t realize it . (That interface is a separate project called the “API UI”).
The UI and API UI are 100% client-side and driven by making API calls, so hiding the link or similar is just pretending the problem doesn’t exist.
Individual fields and resource types can be exposed or not in the API based on the role. The “read-only” role is exactly a “member” that can’t PUT/POST/DELETE things.
Disabling the machine config seems like a good idea though. And the cleartext apikey/secrets fields for machine configs will eventually be made write-only for all roles so even "admin"s can’t read the field.
. (That interface is a separate project called the “API UI”).