Users and models
This section is about understanding models with multiple users.
Adding models
When an administrator adds a model, by default, the cloud credentials used throughout the model will be those that the admin used to create the controller and the SSH keys copied across the model will be those of the controller model. The administrator can override these defaults with the appropriate command options.
The model creator becomes, by default, the model owner. However, the creation process does allow for owner designation.
Examples:
Add model 'mymodel' (in the current controller):
juju add-model mymodel
Add model 'mymodel' and designate user 'tron' as the owner:
juju add-model --owner=tron mymodel
See Adding a model for details on adding models.
Models and user access
An administrator can use the grant
command to grant a user 'read', 'write',
or 'admin' access to any model.
read
: A user can view the state of a model with themodels
,machines
andstatus
commands.write
: In addition to 'read' abilities, a user can modify/configure models.admin
: In addition to 'write' abilities, a user can backup models and connect to machines via thejuju ssh
command.
To give 'bob' read-only access to the model 'mymodel', for example, the administrator would enter the following:
juju grant bob read mymodel
To give 'jim' write access to the same model, the administrator would use the following:
juju grant jim write mymodel
See Users for details on available commands.
Note: Each user has control over naming the models they own. This means it is possible for two users, jane
and claire
, to each have a model with the same name, foo
. This could cause difficulty when claire
needs to access jane
's model. Because of this, it is possible to refer to models using {owner}/{model}
in place of just the model name. For example, claire
can get the status of the model using juju status -m jane/foo
.
Controller access
A controller is a special kind of model that acts as the management node for each cloud environment. Properly managed access to any controller is critical to the security and stability of your cloud and all its models.
In addition to the two levels of user access for models, three further levels of access are used to manage access to Juju's controllers:
login
: the standard access level for any user, enabling them to connect to a cloud and access any permitted models.add-model
: in addition to login access, a user is also be permitted to add and remove new models.superuser
: grants a user the same permissions as an administrator and complete control over the deployed environment.
The grant
syntax for controller access is the same as model
access, only without the need to specify a model. With no controller specified,
the current controller will be assumed the target:
juju grant jim add-model
A controller can be specified using the --controller
argument followed by the
name of the controller:
juju grant jim add-model --controller admin-lxd
The users
command can be used to list all users registered to a controller, along
with their access levels. The output will look similar to the following:
Controller: admin-lxd Name Display name Access Date created Last connection admin* admin superuser 2016-11-14 just now bob login 1 hour ago 58 minutes ago jim add-model 2016-11-14 58 minutes ago
Controller access for external users
It is possible to give a user access to a controller without creating a local account for them. Linking the controller to the external identity manager, such as the Ubuntu SSO, in this way provides the benefit of convenience, as the authentication system used may also be used for other systems. This reduces the number of login credentials that users must remember across multiple systems.
To do this, these criteria must first be met:
- The user must already have an account on an external identity manager
- The controller must have been created (bootstrapped) using the identity
configuration option, like here where we use the URL for the Ubuntu SSO
and Juju:
--config identity-url=https://api.jujucharms.com/identity
- The user must first log in to http://jujucharms.com at least once before attempting to log in to Juju as an external user
- The user must install Juju on the machine from which they will access the controller
On the controller, you grant Frances access to add models using:
juju grant frances@external addmodel
Note: The '@external' is required as it indicates where the credential comes from, as opposed to '@local'.
You can allow anyone with an Ubuntu SSO account to create models on this controller like this:
juju grant everyone@external addmodel
Sharing controller information must be done directly between the controller
owner and the external user, such as via email, and manually adding the
controller information to the local user's $HOME/.local/share/juju/controllers.yaml
in Ubuntu and other Linux distributions and the similar location in other OSes.
The external user will log in from their machine with juju login -u <username>
.
They will be directed to the URL for the external identity provider so that
they may log in there and then will be granted access to the controller.
For the external user to create models from the controller, they must have credentials for that provider, for example, GCE or AWS. Any models created by this user will use these credentials.
juju add-model test --credential gce
To learn more about credentials, see credentials.
Public controllers
The juju login
command can also be used to access a public controller, using
either the name or the host name of the controller as a parameter:
juju login jaas
The above command will add the 'jaas' public controller to the list of
controllers you can use, caching its details in the locally stored
controllers.yaml
file.
Public controllers will normally use an external identity provider. JAAS, as used above, uses Ubuntu SSO, which means you should register with https://jujucharms.com/login.
Revoke access rights
The 'revoke' command is used to remove a user's access to either a model or a controller. To revoke 'add-model' controller access for user 'jim', you would use the following:
juju revoke jim add-model
After a revoke
command has been issued, a user's access will reduce to the
next lower access level. With the above example, user 'jim' would have have
'add-model' access reduced to 'login' access on the controller. This also means
that if a user has write access to a model, the following command would revoke
both read and write access:
juju revoke bob read mymodel
Note: The admin user has credentials stored in the controller and will be able to perform functions on any model. However, a regular user who has been given 'add-model' permissions may need to specify which credential to use when logging in to a model for the first time. To specify a credential, run 'juju add-credential'.