Avoid write the passwords in the config files
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.
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
#1 Updated by Tino Vázquez almost 9 years ago
- File auth-in-one.pdf added
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.