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.
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.
If you have upgraded from SUSE Linux Enterprise High Availability Extension 11 SPx and kept your former CIB version, refer to the Access Control List chapter in the Administration Guide for SUSE Linux Enterprise High Availability Extension 11 SP3 or earlier. It is available from https://documentation.suse.com/sle-ha-11.
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
.
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/.
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 12.1, “Enabling Use of ACLs with Hawk2”.
Log in to Hawk2:
https://HAWKSERVER:7630/
In the left navigation bar, select
to display the global cluster options and their current values.
Below No
.
Set its value to Yes
and apply your changes.
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.
Usually, it is convenient to bundle ACLs into roles and assign a specific role to system users (ACL targets). There are two methods to create ACL rules:
Section 12.3.1, “Setting ACL Rules via XPath Expressions”. You need to know the structure of the underlying XML to create ACL rules.
Section 12.3.2, “Setting ACL Rules via Abbreviations”. Create a shorthand syntax and ACL rules to apply to the matched objects.
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 12.1):
root #
crm
configure show 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"/> [...] </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 12.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.
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. |
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.
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 12.4, “Adding a Monitor Role and Assigning a User with crmsh”.
Log in to Hawk2:
https://HAWKSERVER:7630/
In the left navigation bar, select
.Click
.
Enter a unique monitor
.
As access Read
.
As /cib
.
Click
.
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
.
If necessary, add more rules by clicking the plus icon and specifying the respective parameters.
Sort the individual rules by using the arrow up or down buttons.
To assign the role we created in Procedure 12.2 to a system user (target), proceed as follows:
Log in to Hawk2:
https://HAWKSERVER:7630/
In the left navigation bar, select
.
To create a system user (ACL Target), click tux
.
Make sure this user belongs to the haclient
group.
To assign a role to the target, select one or multiple
.
In our example, select the monitor
role you created
in Procedure 12.2.
Confirm your choice.
To configure access rights for resources or constraints, you can also use the abbreviated syntax as explained in Section 12.3.2, “Setting ACL Rules via Abbreviations”.
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.
Log in as root
.
Start the interactive mode of crmsh:
root #
crm
configurecrm(live)configure#
Define your ACL role(s):
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.
Add additional roles as needed.
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
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 12.3.2, “Setting ACL Rules via Abbreviations”.