Creating roles/entitlements for machine access

This page describes how to create a role/entitlement to allow access to a machine, or a class of machines. This allows us to allocate the appropriate role/entitlement to a user, and use that in access control, rather than a user's name directly. Crucially this means that we can apply lifecycle rules, such as ensuring any access does not continue into a user's grace period.

For a description of the various types of entitlements and how they are affected by grace periods, see here.

Entitlement naming

To allow access to a machine, or class of machines, we recommend that entitlements are named according to the following scheme:

login/<name-or-class>/<type>

... where name-or-class is either a machine name, or a class of machines (e.g. a specific lab, or a login cluster); and type is the type of access (e.g. remote).

e.g. an entitlement to allow remote login access to an individual machine brendel should be named login/brendel/remote

Creating container roles

When considering roles/entitlements, it should be remembered that roles are merely containers for entitlements. It is the latter which confer privileges on the user. We could, therefore, create entitlements only, and apply them directly to users. This would avoid creating single-use roles, but we have decided not to do this for machine access, for two reasons:

  • Creating container roles keeps all entitlements in the same logical namespace (i.e. rfe maps and the ou=Roles section of the prometheus tree).
  • Computing staff regularly use commands which query roles.

We recommend that single-entitlement roles for machine access should have the same name as the containing entitlement, but with the slashes translated into dashes, so the above example of login/brendel/remote should be contained in a role named login-brendel-remote.

e.g. a role/entitlement for machine bolt could look like this:

[bolt]toby: rfe -g roles/login-bolt-remote
# Role/entitlement for remote access to machine 'bolt'

!login/bolt/remote
[bolt]toby: 

Note that the entitlement is preceded by a '!' to indicate that this should not apply during a user's grace period.

Using the entitlement for access control

It is largely outwith the scope of this document to detail how to use entitlements in access control, however, one example could be to use the lcfg-auth component to add the entitlement to a machine's /etc/security/access.conf file, as used by pam, e.g.

!auth.users mADD(@login/bolt/remote)

All lists of entitlements exist on DICE machines as netgroups, which is what the '@' prefix above indicates.


-- TobyBlake - 12 Dec 2017

Topic revision: r1 - 12 Dec 2017 - 11:39:55 - TobyBlake
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies