Request #426

Avoid write the passwords in the config files

Added by javier diaz almost 9 years ago. Updated over 6 years ago.

Status:ClosedStart date:12/06/2010
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-
Pull request:

Description

Hi,
In somehow, the passwords should be generated in runtime using some procedure.

I thinks that there are only two passwords in the OpenNebula installation:
- Oneadmin password ($HOME/.one/one_auth). This could be changed to authenticate this user using local ssh keys, because you already provide this feature for other users.
- The database password in the file $ONE_LOCATION/etc/oned.cfg. An idea could be use some procedure to generate a password from the oneadmin's ssh key. This password should be used to create the oneadmin user in the database. In this way, you would have a unique password and OpenNebula would generate this password in runtime when needed.

Thanks,
Javi

auth-in-one.pdf (58.1 KB) Tino Vázquez, 12/23/2010 03:41 PM

Associated revisions

Revision 9be1a1a7
Added by Vlastimil Holer about 2 years ago

Send both gratuitous ARP request and reply on VIP change. (#426)

  • Send both gratuitous ARP request and reply on VIP change.
  • Enable arping in sudoers
  • Run arping via sudo

Revision b0f98851
Added by Vlastimil Holer about 2 years ago

Send both gratuitous ARP request and reply on VIP change. (#426)

  • Send both gratuitous ARP request and reply on VIP change.
  • Enable arping in sudoers
  • Run arping via sudo

(cherry picked from commit 9be1a1a706c4c132b97d401b1f08bab8383e344f)

History

#1 Updated by Tino Vázquez almost 9 years ago

After analyzing the problem, we have identified the possible problems derived from authenticating users. This needs to be taken into account if we want to avoid using passwords in clear text.

In the image, the arrows marks auth requests from different components. The red arrow can be secured using some sort of SSL proxy for the XMLRPC connections, so this is not an issue.

The blue arrow talks about the relation needed for the user to use its password to get an auth token. For this we use passwords in clear text, which is what we are trying to avoid. We have two choices:

1) save the file that stores the password in other format. If the file is stolen however, this offers the same protection as storing them in clear text. If we want to encrpyt it, then the user will need to enter the password each time it issues a request
2) create time expiring proxies using a password. this is our preferred solution, and it can be accomplished right now with the ssh auth module.
3) other mechanisms rather than proxies (like having a login/logout session). The problem is that we will need to rely on user discipline.

The problem with choice 2) (our preferred one) are what is depicted with black arrows in the image. There are components that need to authenticate with the core using the oneadmin account, for a variety of reasons. The problem about having time-expiring proxies for the oneadmin account is that it doesn't neatly apply to production environments, since these proxies will need to be manually updated.

Therefore we suggest a mix between 1) and 2), where 1) will apply to oneadmin account and 2) to the other, regular users.

#2 Updated by Ruben S. Montero over 6 years ago

  • Status changed from New to Closed

implemented as ssh drivers

Also available in: Atom PDF