Project

General

Profile

Roles and permissions » History » Version 17

« Previous - Version 17/18 (diff) - Next » - Current version
Ohad Levy, 01/03/2012 03:20 PM


Roles and permissions

A user's access to the features of Foreman are constrained by the roles and permissions that they are granted. These permissions are also used to restrict the set of hosts, host groups and domains that a user is able to access and modify.

Note: a user with global admin enabled is not restricted by the authorization system. This is the default for installations that do not have :login:true in config/settings.yml.

A logged in user will be granted the Anonymous role plus one or more additional roles. The permissions associated with these roles are aggregated and determine the final permission set.

Roles may be administered only by a user with global admin privileges.

Roles

These may be created, deleted and edited on the Roles page. Each role will be associates with one or more base privileges.

There are two builtin system roles
  1. Anonymous: This is a set of permissions that every user at your installation will be granted, irrespective of any other roles that they have.
  2. Default user: When a new Role is created this set of permissions are used as the template for the Role. The name is somewhat misleading but basically an ordinary default user who was assigned this Role would have these permissions set.

Permissions

These determine the operations that are allowed to be performed upon the items to which they refer. For simple items, like an architecture, this operates as expected but for more complex items, such as, the hosts a user is able to operate on, there is an additional layer of security called filtering.

When editing a user account there is a section at the bottom that narrows the scope of the permissions granted to a subset of the hosts, domains and host groups. See filtering below.

Permission Description
Permissions for Architectures, Authentication providers, environments, External variables, Common parameters, Medias, Models, Operating systems, Partition tables, Puppet classes and User groups
view The user is allowed to see this type of object when listing them on the index page
create The user is allowed to create this type of object
edit The user is allowed to edit this type of object
destroy The user is allowed to destroy this type of object
Permissions for Domains
view The user is allowed to see a list of domains when viewing the index page
create The user is allowed to create a new domain and will also be able to create domain parameters
edit The user is allowed to edit a domain and will also be able to edit a domain's parameters. If they have domain filtering active in their profile then only these domains will be editable
destroy The user is allowed to destroy a domain and will also be able to destroy domain parameters. If they have domain filtering active in their profile then only these domains will be deletable
Permissions for Host groups
view The user is allowed to see a list of host groups when viewing the index page
create The user is allowed to create a new host group and will also be able to create host group parameters
edit The user is allowed to edit a host group and will also be able to edit a host group's parameters. If they have host group filtering active in their profile then only these host groups will be editable
destroy The user is allowed to destroy a host group and will also be able to destroy host group parameters. If they have host group filtering active in their profile then only these host groups will be deletable
Permissions for Hosts
view The user is allowed to see a list of hosts when viewing the index page. This list may be constrained by the user's host filters
create The user is allowed to create a new host. This operation may be constrained by the user's host filters
edit The user is allowed to edit a host. This operation may be constrained by the user's host filters
destroy The user is allowed to destroy a host. This operation may be constrained by the user's host filters
Permissions for Users
view The user is allowed to see a list of users when viewing the index page. A user will always be able to see their own account even if they do not have this permission
create The user is allowed to create a new user
edit The user is allowed to edit existing users. A user will always be able to edit their own basic account settings and password
destroy The user is allowed to delete users from the system

Filtering

If the filtering section at the bottom of the user's profile page has no content then the permissions that the user has been granted will apply to all hosts within the system.

However, if the filtering section is in use then the permissions will apply only to those items selected in the filters and the user will have no access to anything not selected by the filters.

This is primarily a mechanism for restricting access to hosts. However if one or more domains or host groups are selected then this also restricts where parameters can be created, edited and deleted.

Filtering operates by generating a list of hosts on which actions can be performed. The list may be built out of four components

  1. Ownership: The hosts that a user owns directly or hosts that are owned by a user group of which the user is a member.
  1. Domain membership: The hosts that exist within one or more indicated domains.
  1. Host group membership: The hosts that are defined as being of one or more host group types.
  1. Fact filtering: These restrict the hosts to those machines that have this fact associated with them. As a fact is only generated during a puppet run, this filter will only refer to machines that have been built and therefore cannot be used to restrict the creation of machines.

These four pools of hosts can be combined by adding them together or the filters can be used to restrict the selected hosts to a smaller and smaller subset of the total. Think of it as set operations.

Note: If the "Administrator" check box is checked for a user, filtering will not take effect.

Example

A user's filter section has the select checkbox unticked, indicating that the user's owned hosts are not included in the final set of hosts, (unless they are selected some other way.)

The domain selection is prefixed with plus all and the two domains a.com and b.com are ticked. This implies that the hosts selected are the user's hosts, (of which there are none,) plus all the hosts in a.com and b.com.

The host group section is prefixed by must be and the hostgroup web server is selected. This implies that the hosts selected are the user's hosts, (of which there are none,) plus all the hosts in a.com and b.com but they must be of type web server.

The fact filter section is prefixed by must match and there are two filters virtual = vmware and architecture = i386. This implies that the hosts selected are the user's hosts, (of which there are none,) plus all the hosts in a.com and b.com but they must be of type web server and must match an i386 vmware host.

In any of these sections above, if the prefix had been plus all then every host in the system that matched the selections would have been added to the final host list, (though possibly removed by a later filter.)