Access Control Lists | Administration Guide | SUSE Linux Enterprise High Availability Extension 12

SUSE Linux Enterprise High Availability Extension Documentation › Administration Guide › Configuration and Administration › Access Control Lists

ContentsContents

Administration Guide

Navigation←→

Applies to SUSE Linux Enterprise High Availability Extension 12

9 Access Control Lists

9.1 Requirements and Prerequisites
9.2 Enabling Use of ACLs In Your Cluster
9.3 The Basics of ACLs
9.4 Configuring ACLs with Hawk
9.5 Configuring ACLs with crmsh
9.6 For More Information

The cluster administration tools like crm shell (crmsh) or Hawk can be used by root or any user in the group haclient. By default, these users have full read/write access. To limit access or assign more fine-grained access rights, you can make use of Access control lists (ACLs).

Access control lists consist of an ordered set of access rules. Each rule allows read or write access or denies access to a part of the cluster configuration. Rules are typically combined to produce a specific role, then users may be assigned to a role that matches their tasks.

9.1 Requirements and Prerequisites #

Before you start using ACLs on your cluster, make sure the following conditions are fulfilled:

Ensure you have the same users on all nodes in your cluster, either by using NIS, Active Directory, or by manually adding the same users to all nodes.
All users for whom you want to modify access rights with ACLs must belong to the haclient group.
All users need to run crmsh by its absolute path /usr/sbin/crm.
If non-privileged users want to run crmsh, their PATH variable needs to be extended with /usr/sbin.

Important: Default Access Rights

ACLs are an optional feature. By default, use of ACLs is disabled.
If ACLs are not enabled, root and all users belonging to the haclient group have full read/write access to the cluster configuration.
Even if ACLs are enabled and configured, both root and the default CRM owner hacluster always have full access to the cluster configuration.

To use ACLs you need some knowledge about XPath. XPath is a language for selecting nodes in an XML document. Refer to http://en.wikipedia.org/wiki/XPath or look into the specification at http://www.w3.org/TR/xpath/.

9.2 Enabling Use of ACLs In Your Cluster #

Before you can start configuring ACLs, you need to enable use of ACLs. To do so, use the following command in the crmsh:

root # crm configure property enable-acl=true

Alternatively, use Hawk as described in Procedure 9.1, “Enabling Use of ACLs with Hawk”.

Procedure 9.1: Enabling Use of ACLs with Hawk #

Start a Web browser and log in to the cluster as described in Section 5.1.1, “Starting Hawk and Logging In”.
In the left navigation bar, select Cluster Properties.
In the CRM Configuration group, , select the enable-acl attribute from the empty drop-down box and click the plus icon to add it.
To set enable-acl=true, active the checkbox next to enable-acl and confirm your changes.

9.3 The Basics of ACLs #

an access right like read, write, or deny
a specification where to apply the rule. This specification can be a tag, an ID reference, a combination of both, or an XPath expression.

In most cases, it is convenient to bundle ACLs into roles and assign a specific role to users. It is also possible to configure ACLs directly for individual users.

There are two methods to create ACL rules:

Section 9.3.1, “Setting ACL Rules via XPath Expressions”. You need to know the structure of the underlying XML to create ACL rules.
Section 9.3.2, “Setting ACL Rules via Tag Abbreviations”. Create a shorthand syntax and ACL rules to apply to the matched objects.

9.3.1 Setting ACL Rules via XPath Expressions #

To manage ACL rules via XPath, you need to know the structure of the underlying XML. Retrieve the structure with the following command that shows your cluster configuration in XML (see Example 9.1, “Excerpt of a Cluster Configuration in XML”):

root # crm configure show xml

Example 9.1: Excerpt of a Cluster Configuration in XML #

<num_updates="59" 
      dc-uuid="175704363"
      crm_feature_set="3.0.9"
      validate-with="pacemaker-2.0"
      epoch="96"
      admin_epoch="0"
      cib-last-written="Fri Aug  8 13:47:28 2014"
      have-quorum="1">
  <configuration>
    <crm_config>
       <cluster_property_set id="cib-bootstrap-options">
        <nvpair name="stonith-enabled" value="true" id="cib-bootstrap-options-stonith-enabled"/>
        <nvpair name="no-quorum-policy" value="ignore" id="cib-bootstrap-options-no-quorum-policy"/>
         [...]
      </cluster_property_set>
    </crm_config>
    <nodes>
      <node id="175704363" uname="alice"/>
      <node id="175704619" uname="bob"/>
    </nodes>
    <resources> [...]  </resources>
    <constraints/>
    <rsc_defaults> [...] </rsc_defaults>
    <op_defaults> [...] </op_defaults>
  <configuration>
</cib>

With the XPath language you can locate nodes in this XML document. For example, to select the root node (cib) use the XPath expression /cib. To locate the global cluster configurations, use the XPath expression /cib/configuration/crm_config.

As an example, Table 9.1, “Operator Role—Access Types and XPath Expressions ” shows the parameters (access type and XPath expression) to create an “operator” role. Users with this role can only execute the tasks mentioned in the second column—they will not be able to reconfigure any resources (for example, change parameters or operations), nor change the configuration of colocation or ordering constraints.

Table 9.1: Operator Role—Access Types and XPath Expressions #

Type	XPath/Explanation
Write	//crm_config//nvpair[@name='maintenance-mode'] Turn maintenance mode on or off.
Write	//op_defaults//nvpair[@name='record-pending'] Choose whether pending operations are recorded.
Write	//nodes/node//nvpair[@name='standby'] Set node in online or standby mode.
Write	//resources//nvpair[@name='target-role'] Start, stop, promote or demote any resource.
Write	//resources//nvpair[@name='is-managed'] Select if a resource should be managed or not.
Write	//constraints/rsc_location Migrate/move resources from one node to another.
Read	/cib View the status of the cluster.

9.3.2 Setting ACL Rules via Tag Abbreviations #

For users who do not want to deal with the XML structure there is an easier method. It is a combination of a tag specifier and/or a reference.

For example, consider the following XPath:

/cib/resources/primitive[@id='rsc1']

primitive is a resource with the reference rsc1. The abbreviated syntax is:

tag: "primitive"  ref:"rsc1"

This also works for constraints. Here is the verbose XPath:

/cib/constraint/rsc_location

The abbreviated syntax is written like this:

tag: "rsc_location"

The abbreviated syntax can be used in crmsh and Hawk. The CIB daemon knows how to apply the ACL rules to the matching objects.

9.4 Configuring ACLs with Hawk #

The following procedure shows how to configure a read-only access to the cluster configuration by defining a monitor role and assigning it to a user. Alternatively, you can use crmsh to do so, as described in Procedure 9.3, “Adding a Monitor Role and Assigning a User with crmsh”.

Procedure 9.2: Adding a Monitor Role and Assigning a User with Hawk #

Start a Web browser and log in to the cluster as described in Section 5.1.1, “Starting Hawk and Logging In”.
In the left navigation bar, select Access Control Lists. The view shows the Roles and Users that are already defined.
To define your ACL role(s):
1. Select the Roles category and click the plus icon.
2. Enter a unique Role ID, for example, monitor.
3. For our example of defining a monitor role, select read from the Right drop-down box.
4. In the Xpath text box, enter the Xpath expression /cib and click Create Role.
  This creates a new role with name monitor, sets the read rights and applies it to all elements in the CIB by using the XPath expression/cib.
5. If necessary, you can add more access rights and XPath arguments by clicking the plus icon and specifying the respective parameters. Confirm your changes.
Assign the role to a user:
1. Select the Users category and click the plus icon.
  The Create User view shows the available roles. It also contains an additional line for configuring individual ACLs rules for that user. The view lest you either assign one or multiple roles to the user or define one or more individual rules for the user. Selecting a role with make the line for individual rules disappear and vice versa. Assigning a role plus individual rules is not possible.
2. Enter a unique User ID, for example, tux. Make sure this user belongs to the haclient group.
3. To assign a role to the user, select the respective entries from Roles. In our example, select the monitor role you just created.
  To deselect one or multiple roles, click the respective entries once more. If no role is selected, the line for defining individual rules will appear again.
  Figure 9.1: Hawk—Assigning a Role or Rule to a User #
4. If you want to define individual rules instead, select a Right and enter the respective Xpath parameters for your rule. Click the plus icon to define additional rules.
5. Confirm your choice and assign the roles or rules to the user by clicking Create User.

To configure access rights for resources or constraints, you can also use the abbreviated syntax as explained in Section 9.3.2, “Setting ACL Rules via Tag Abbreviations”. For example, if you have a primitive resource with the ID rsc1, enter the following values for Tag and Ref: primitive and rsc1. When entering only rsc1 as Ref, it has the advantage that it can match a primitive resource and a local resource manager resource (LRM), which enables you to configure rsc1 and also cleanup its status at the same time.

9.5 Configuring ACLs with crmsh #

The following procedure shows how to configure a read-only access to the cluster configuration by defining a monitor role and assigning it to a user.

Procedure 9.3: Adding a Monitor Role and Assigning a User with crmsh #

Start the interactive mode of crmsh:

root # crm configure
crm(live)configure#

Define your ACL role(s):
1. Use the role command to define a new role:
```
crm(live)configure# role monitor read xpath:"/cib"
```
  The previous command creates a new role with name monitor, sets the read rights and applies it to all elements in the CIB by using the XPath expression /cib. If necessary, you can add more access rights and XPath arguments.
2. Add additional roles as needed.
Assign your roles to one or multiple users. Make sure the users belong to the haclient group.
```
crm(live)configure# acl_target tux monitor
```
Check your changes:
```
crm(live)configure# show
```
Commit your changes:
```
crm(live)configure# commit
```

To configure access rights for resources or constraints, you can also use the abbreviated syntax as explained in Section 9.3.2, “Setting ACL Rules via Tag Abbreviations”. If you have a primitive resource with the ID rsc1, use the following notation to set the access rights: write tag:"primitive" ref:"rsc1". You can also refer to the ID with write ref:"rsc1". This has the advantage that it can match a primitive resource and a local resource manager resource (LRM), which enables you to configure rsc1 and also cleanup its status at the same time.

9.6 For More Information #

See http://www.clusterlabs.org/doc/acls.html.

Print this page