Users
OpenNebula supports user accounts and groups. This guide shows how to manage users; groups are explained in their own guide. To manage user rights, visit the Managing ACL Rules guide.
A user in OpenNebula is defined by a username and a password. You don’t need to create a new Unix account in the Front-end for each OpenNebula user, they are completely different concepts. OpenNebula users are authenticated using a session string (with <user>:<password>
format), this is included in every operation and validated by OpenNebula service.
Each user has a unique ID and belongs at least to one group.
After the installation, you will have two administrative accounts, oneadmin
and serveradmin
, and two default groups, oneadmin
and users
. You can check it using the oneuser list
and onegroup list
commands.
There are different user accounts in OpenNebula, depending on the default permissions granted to them:
- Administrators, the
oneadmin
account is created the first time OpenNebula is started.oneadmin
has enough privileges to perform any operation on any object (similar toroot
user in UNIX-like systems). Any other user added tooneadmin
group is considered an administrator user and has the same privileges asoneadmin
. - Users accounts may access most of the functionality offered by OpenNebula to manage resources.
- Group Administrators are similar to users but can manage user accounts and resources in their group.
- Service Users are used by the OpenNebula services (e.g., Sunstone web interface, OneFlow) to proxy auth request. By default,
serveradmin
user is created the first time OpenNebula service is started. This user is only intended to be used by OpenNebula services.
Note
oneadmin
credentials are set the first time OpenNebula service is started. By default, it looks for a session string in /var/lib/one/.one/one_auth
and defines the credentials according to it.Managing Users
User accounts within the OpenNebula system are managed by oneadmin
with the oneuser
command. This section will show you how to manage users in OpenNebula.
Adding Users
A new user can be easily created by running the oneuser create
command or by using the corresponding Sunstone dialog:
$ oneuser create <user_name> <password>
ID: 3
Warning
When defining usernames and passwords consider the following invalid characters:
username = [" ", ":", "\t", "\n", "\v", "\f", "\r"]
password = [" ", "\t", "\n", "\v", "\f", "\r"]
Some auth drivers do not require passwords (ldap); in this case a user can be created without it:
```default
$ oneuser create --driver ldap <user_name>
ID: 4
When a user is being created with different auth driver which does not require a password
The user types listed above are mainly defined by the group to which the user belongs. So, after creating the user, you may wish to modify the user’s groups. In order to do so, oneuser chgrp
can be used:
# Make <user_name> an administrator user.
$ oneuser chgrp <user_name> oneadmin
Disable User
To temporarily disable a user you can use the command oneuser disable
. To enable a user, use oneuser enable
. Disabled users can’t execute any action and can’t log in to Sunstone.
Deleting Users
In order to delete a user which is no longer needed, the oneuser delete
command can be used.
User Authentication
Sunstone Web interface
In order to authenticate yourself as a user by using Sunstone, you just need to provide your username and password in the login page.
CLI & APIs
In order to authenticate with OpenNebula when using the CLI or any API binding, you need a valid password or authentication token to generate the session string.
The default driver, core
, is a simple user-password match mechanism. To configure a user account we need to put our session string in a well known place so that it can be used when needed. By default we need to put it into $HOME/.one/one_auth
. The session string is just a single line with the format <username>:<password>
. For example, for user oneadmin
and password opennebula
the file would be:
$ cat $HOME/.one/one_auth
oneadmin:opennebula
Once configured you will be able to access the OpenNebula API and use the CLI tools:
$ oneuser show
USER 0 INFORMATION
ID : 0
NAME : oneadmin
GROUP : oneadmin
PASSWORD : c24783ba96a35464632a624d9f829136edc0175e
Note
OpenNebula does not store the plain password but a hashed version in the database, as shown by the oneuser example above.Check this guide to discover how you can customize shell variables.
Tokens
$HOME/.one/one_auth
is protected only with the standard filesystem permissions. To improve the system security you can use authentication tokens. In this way there is no need to store plain passwords because OpenNebula can generate or use an authentication token with a given expiration time. By default, the tokens are also stored in $HOME/.one/one_auth
.
Furthermore, if the user belongs to multiple groups, a token can be associated to one of those groups, and when the user operates with that token they will be effectively in that group, i.e., the user will only see the resources that belong to that group, and when the user creates a resource it will be placed in that group.
Create a Token
Any user can create a token:
$ oneuser token-create
File /var/lib/one/.one/one_auth exists, use --force to overwrite.
Authentication Token is:
testuser:b61010c8ef7a1e815ec2836ea7691e92c4d3f316
The command will try to write $HOME/.one/one_auth
if it does not exist.
The expiration time of the token is by default 10h (36000 seconds). When requesting a token the option --time <seconds>
can be used in order to define exactly when the token will expire. A value of -1
disables the expiration time.
The token can be associated with one of the groups the user belongs to. If a user logs in with that token, the user will be effectively only in that group and will only be allowed to see the resources that belong to that group, as opposed to the default token, which allows access to all the resources available to the groups that the user belongs to. In order to specify a group, the option --group <id|group>
can be used. When a group specific token is used, any newly created resource will be placed in that group.
List the Tokens
Tokens can be listed by doing:
$ oneuser show
[...]
TOKENS
ID EGID EGROUP EXPIRATION
3ea673b 100 groupB 2016-09-03 03:58:51
c33ff10 100 groupB expired
f836893 *1 users forever
The asterisk in the EGID
column means that the user’s primary group is 1 and that the token is not group specific.
Set (Enable) a Token
A token can be enabled by doing:
$ oneuser token-set --token b6
export ONE_AUTH=/var/lib/one/.one/5ad20d96-964a-4e09-b550-9c29855e6457.token; export ONE_EGID=-1
$ export ONE_AUTH=/var/lib/one/.one/5ad20d96-964a-4e09-b550-9c29855e6457.token; export ONE_EGID=-1
Delete a Token
Similarly, a token can be removed by doing:
$ oneuser token-delete b6
Token removed.
User Templates
The USER TEMPLATE
section can hold any arbitrary data. You can use the oneuser update
command to open an editor and add, for instance, the following DEPARTMENT
and EMAIL
attributes:
$ oneuser show 2
USER 2 INFORMATION
ID : 2
NAME : regularuser
GROUP : 1
PASSWORD : 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8
AUTH_DRIVER : core
ENABLED : Yes
USER TEMPLATE
DEPARTMENT=IT
EMAIL=user@company.com
These attributes can be used later in the Virtual Machine Contextualization. For example, using contextualization the user’s public ssh key can be automatically installed in the VM:
ssh_key = "$USER[SSH_KEY]"
The User template can be used to customize the access rights for the VM_USE_OPERATIONS
, VM_MANAGE_OPERATIONS
, and VM_ADMIN_OPERATIONS
. For a description of these attributes see VM Operations Permissions
Manage Your Own User
Users can see their account information and change their password.
For instance, as regularuser
you could do the following:
$ oneuser list
[UserPoolInfo] User [2] not authorized to perform action on user.
$ oneuser show
USER 2 INFORMATION
ID : 2
NAME : regularuser
GROUP : 1
PASSWORD : 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8
AUTH_DRIVER : core
ENABLED : Yes
USER TEMPLATE
DEPARTMENT=IT
EMAIL=user@company.com
$ oneuser passwd 1 abcdpass
As you can see, any user can find out his or her ID using the oneuser show
command without any arguments.
Regular users can retrieve their information in the Settings section of Sunstone:
Finally some configuration attributes can be set to tune the behavior of Sunstone or OpenNebula for the user. For a description of these attributes please check the group configuration guide.
Managing Users in Sunstone
All the described functionality is available graphically using Sunstone:
Change Credentials for oneadmin or serveradmin
In order to change the oneadmin
credentials you have to do the following in the Front-end node:
# oneuser passwd 0 <PASSWORD>
# echo 'oneadmin:<PASSWORD>' > /var/lib/one/.one/one_auth
Warning
After changing the password, please restart the OpenNebula service.In order to change serveradmin
credentials you have to do the following in the Front-end follow these steps.
# oneuser passwd 1 --sha256 <PASSWORD> # echo 'serveradmin:PASSWORD' > /var/lib/one/.one/oneflow_auth # echo 'serveradmin:PASSWORD' > /var/lib/one/.one/onegate_auth # echo 'serveradmin:PASSWORD' > /var/lib/one/.one/sunstone_auth
Restart Sunstone after changing the password.
We value your feedback
Was this information helpful?
Glad to hear it
Sorry to hear that