Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE Linux Enterprise High Availability Extension 15 SP2

13 Access Control Lists Edit source

The cluster administration tools like crm shell (crmsh) or Hawk2 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 use 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.

Note
Note: CIB Syntax Validation Version and ACL Differences

This ACL documentation only applies if your CIB is validated with the CIB syntax version pacemaker-2.0 or higher. For details on how to check this and upgrade the CIB version, see Note: Upgrading the CIB Syntax Version.

13.1 Requirements and Prerequisites Edit source

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
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.

13.2 Conceptual Overview Edit source

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. An ACL role is a set of rules which describe access rights to CIB. A rule consists of the following:

  • an access right like read, write, or deny

  • a specification where to apply the rule. This specification can be a type, an ID reference, or an XPath expression. XPath is a language for selecting nodes in an XML document. Refer to http://en.wikipedia.org/wiki/XPath.

Usually, it is convenient to bundle ACLs into roles and assign a specific role to system users (ACL targets). There are these methods to create ACL roles:

13.3 Enabling Use of ACLs in Your Cluster Edit source

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 Hawk2 as described in Procedure 13.1, “Enabling Use of ACLs with Hawk2”.

Procedure 13.1: Enabling Use of ACLs with Hawk2
  1. Log in to Hawk2:

    https://HAWKSERVER:7630/
  2. In the left navigation bar, select Cluster Configuration to display the global cluster options and their current values.

  3. Below Cluster Configuration click the empty drop-down box and select enable-acl to add the parameter. It is added with its default value No.

  4. Set its value to Yes and apply your changes.

13.4 Creating a Read-Only Monitor Role Edit source

The following subsections describe how to configure read-only access by defining a monitor role either in Hawk2 or crm shell.

13.4.1 Creating a Read-Only Monitor Role with Hawk2 Edit source

The following procedures show how to configure 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 13.4, “Adding a Monitor Role and Assigning a User with crmsh”.

Procedure 13.2: Adding a Monitor Role with Hawk2
  1. Log in to Hawk2:

    https://HAWKSERVER:7630/
  2. In the left navigation bar, select Roles.

  3. Click Create.

  4. Enter a unique Role ID, for example, monitor.

  5. As access Right, select Read.

  6. As Xpath, enter the XPath expression /cib.

  7. Click Create.

    This creates a new role with the name monitor, sets the read rights and applies this to all elements in the CIB by using the XPath expression/cib.

  8. If necessary, add more rules by clicking the plus icon and specifying the respective parameters.

  9. Sort the individual rules by using the arrow up or down buttons.

Procedure 13.3: Assigning a Role to a Target with Hawk2

To assign the role we created in Procedure 13.2 to a system user (target), proceed as follows:

  1. Log in to Hawk2:

    https://HAWKSERVER:7630/
  2. In the left navigation bar, select Targets.

  3. To create a system user (ACL Target), click Create and enter a unique Target ID, for example, tux. Make sure this user belongs to the haclient group.

  4. To assign a role to the target, select one or multiple Roles.

    In our example, select the monitor role you created in Procedure 13.2.

  5. Confirm your choice.

To configure access rights for resources or constraints, you can also use the abbreviated syntax as explained in Section 13.8, “Setting ACL Rules via Abbreviations”.

13.4.2 Creating a Read-Only Monitor Role with crmsh Edit source

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 13.4: Adding a Monitor Role and Assigning a User with crmsh
  1. Log in as root.

  2. Start the interactive mode of crmsh:

    root # crm configure
    crm(live)configure# 
  3. 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 the 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.

  4. Assign your roles to one or multiple ACL targets, which are the corresponding system users. Make sure they belong to the haclient group.

    crm(live)configure# acl_target tux monitor
  5. Check your changes:

    crm(live)configure# show
  6. 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 13.8, “Setting ACL Rules via Abbreviations”.

13.5 Removing a User Edit source

The following subsections describe how to remove an existing user from ACL either in Hawk2 or crmsh.

13.5.1 Removing a User with Hawk2 Edit source

To remove a user from ACL, proceed as follows:

  1. Log in to Hawk2:

    https://HAWKSERVER:7630/
  2. In the left navigation bar, select Targets.

  3. To remove a system user (ACL target), click the garbage bin icon under the Operations column.

  4. Confirm the dialog box.

13.5.2 Removing a User with crmsh Edit source

To remove a user from ACL, replace the placeholder USER with the name of the user:

root # crm configure delete USERNAME

As an alternative, you can use the edit subcommand:

root # crm configure edit USERNAME

13.6 Removing an Existing Role Edit source

The following subsections describe how to remove an existing role in either Hawk2 or crmsh.

Note
Note: Deleting Roles with Referenced Users

Keep in mind, no user should belong to this role. If there is still a reference to a user in the role, the role cannot be deleted. Delete the references to the users first before you delete the role.

13.6.1 Removing an Existing Role with Hawk2 Edit source

To remove a role, proceed as follows:

  1. Log in to Hawk2:

    https://HAWKSERVER:7630/
  2. In the left navigation bar, select Roles.

  3. To remove a role, click the garbage bin icon under the Operations column.

  4. Confirm the dialog box. If an error message appears, make sure your role is empty and does not reference users.

13.6.2 Removing an Existing Role with crmsh Edit source

To remove an existing role, replace the placeholder ROLE with the name of the role:

root # crm configure delete ROLE

13.7 Setting ACL Rules via XPath Expressions Edit source

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 13.1):

root # crm configure show xml
Example 13.1: Excerpt of a Cluster Configuration in XML
<cib>
  <!-- ... -->
  <configuration>
    <crm_config>
       <cluster_property_set id="cib-bootstrap-options">
        <nvpair name="stonith-enabled" value="true" id="cib-bootstrap-options-stonith-enabled"/>
       [...]
      </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 13.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 cannot reconfigure any resources (for example, change parameters or operations), nor change the configuration of colocation or ordering constraints.

Table 13.1: Operator Role—Access Types and XPath Expressions

Type

XPath/Explanation

Write

//crm_config//nvpair[@name='maintenance-mode']

Turn cluster 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='maintenance']

Select if a resource should be put to maintenance mode or not.

Write

//constraints/rsc_location

Migrate/move resources from one node to another.

Read

/cib

View the status of the cluster.

13.8 Setting ACL Rules via Abbreviations Edit source

For users who do not want to deal with the XML structure there is an easier method.

For example, consider the following XPath:

//*[@id="rsc1"]

which locates all the XML nodes with the ID rsc1.

The abbreviated syntax is written like this:

ref:"rsc1"

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

//constraints/rsc_location

The abbreviated syntax is written like this:

type:"rsc_location"

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

Print this page