Access Control NCM component documentation

Description of the control fields in the CDB

The whole information about the root access and the interactive access to the computers is defined in the CDB. Through the parameters defined we drive the behavior of the ncm-access_control component that is installed on the computer. In this section we would like to describe each individual components as well as their meaning in the scheme:

"/software/components/access_control/active" - This parameter turns on and off the component in the CDB. The allowed values are true, false. By default this is true.
"/software/components/access_control/interactive_restrictions"- whether on not the interactive control of access should be used. The allowed values are on, off. By default this is turned on, for interactive clusters as such as lxplus this has to be turned off.
"/software/components/access_control/acl_root_method" - Allowed values are: keys, klogin and all. If keys option is only specified, the content of the /root/.ssh/authorized_keys will be updated by corresponding user public keys from the central keys repository. If klogin option is specified, /root/.klogin file is modified to reflect the list of users with access. If option all is specified, both of the mentioned access options will be used.
"/software/components/access_control/acl_int_method" - is used to specify method for controlling the interactive access. Allowed values are:login, session and all. The first option specifies that only content of the /etc/loginusers will be modified, the other one specified /etc/security/limits.conf file to be modified to reflect list of users. As in previous case, option all will modify both.

Description of the access control definition fields in the CDB

There are several ways how to specify access control list for each service or group of users in access control component. The suggested way is to create an access list per resource in question by assigning a group of people to the given resource. The other, discouraged way, is to define roles in real sense, assigning people to the role and specifying what resources given role can access. The first solution is preferred as it allows easier control of access since it would be bound to the resource directly (cluster, host) rather than generating global role list (takes also more time to compile such a list in CDB). The definition of a role or a resource is done in the following way:

"/software/components/access_control/roles/linux_support" = list("torvalds","morton","jpolok"); - defines a list of users that are identified as a role with name linux_support.
"/software/components/access_control/roles/lxbatch_root" = list("gwbush","jve"); - this defines a list of users that we associate with a resource named lxbatch_root.

In these two examples the only distinction made is by naming the given role/resource. The access is defined by assigning role/group to the root and interactive accesses in the following way:

"/software/components/access_control/privileges/acl_root/role/linux_support/0/targets" = list("+span::ALL"); - defines root access to the role linux_support everywhere.
"/software/components/access_control/privileges/acl_root/role/lxbatch_root/0/targets" = list("+cluster::lxbatch"); - defines root access for the lxbatch_root group.
"/software/components/access_control/privileges/acl_interactive/role/lxbatch_root/0/targets" = list("+node::lxb0001"); - defines interactive access for the lxbatch_root group.

The targets of each access control can be specified by +/-node::,+/-cluster:: and +span::ALL directives, that can listen on one line, but must be comma separated.

Putting that all together.

The best way to see how it works is to get a real case example (lxbatch):

#
# access control
#
include pro_system_acl;
"/software/components/access_control/roles/lxbatch_interactive" = list("atlonl","atlsprod","ccfpro","closier","cmsdc04","cmsprod","dcuser","effuser","harpob1");
"/software/components/access_control/roles/lxbatch_root" = list("laman","panzer","markusw");

"/software/components/access_control/privileges/acl_interactive/role/lxbatch_interactive/0/targets" = list("+cluster::lxbatch");
"/software/components/access_control/privileges/acl_root/role/lxbatch_root/0/targets" = list("+cluster::lxbatch");

"/software/components/access_control" = generate_acl_list(value("/software/components/access_control"));

Explanation:

In the pro_system_acl template there are default settings as well as access controls defaults for the entire computing center. Click on the link to get the file. In the next two lines we define two resource related groups - lxbatch_interactive and lxbatch_root. In the next two lines we define targets in the acl_root and acl_interactive lists. At the end one has to call the function to compile the access control lists for the machines. This is done by calling generate_acl_list() function. The example above shows how to do the specifications of the access list for the cluster. This can be further refined on the host's level by adding/removing additional rules. An example would be the following file (an extract from the lxplus001):

#
# add root access
#
"/software/components/access_control/roles/lxplus001_root" = list("defert","jpelegri");
"/software/components/access_control/privileges/acl_root/role/lxplus001_root/0/targets" = list("+node::lxplus001");

Generated list

By calling generate_acl_list() function final list of accesses will be generated, therefore it is important that you call this function at the end of your control statements in the templates. F.e. if you modify host's access list then do that before you include cluster's template. The generated list will look approximately in the following way (lxb0001) :

"access_control" =
"active" = true
"acl_interactive" =
bcouturi
bjac3
cscct
dmac3
gordon
tdbct
cons
console
dore
dwhughes
fuji
gcancio
hcacote
jdurand
jveldik
meinhard
mirsi
obarring
"acl_root" =
bcouturi
bjac3
cscct

"acl_console" =
bcouturi
bjac3
cscct
dmac3
gordon
tdbct
cons
console
dore
"acl_root_method" = all
"acl_int_method" = all
"interactive_restrictions" = on

Applying the access rules by using the ncm-access_control component
Access control rights are applied on the targeted host by calling ncm-access_control component. This is done by logging as root on the target host and specifying the following arguments:
> ncm-ncd --configure access_control
To make sure that the template change has been already reflected on the machine, you can see the settings of the component by issuing the following command:
> ncm-query --components access_control

mirsi
Last modified: Tue Aug 31 13:52:29 CEST 2004