13.5. ACL Examples

⁠13.5. ACL Examples

<acls>

   <acl_role id="read_all">
       <acl_permission id="read_all-cib" kind="read" xpath="/cib" />
   </acl_role>

   <acl_role id="operator">

       <acl_permission id="operator-maintenance-mode" kind="write"
           xpath="//crm_config//nvpair[@name='maintenance-mode']" />

       <acl_permission id="operator-maintenance-attr" kind="write"
           xpath="//nvpair[@name='maintenance']" />

       <acl_permission id="operator-target-role" kind="write"
           xpath="//resources//meta_attributes/nvpair[@name='target-role']" />

       <acl_permission id="operator-is-managed" kind="write"
           xpath="//resources//nvpair[@name='is-managed']" />

       <acl_permission id="operator-rsc_location" kind="write"
           object-type="rsc_location" />

   </acl_role>

   <acl_role id="administrator">
       <acl_permission id="administrator-cib" kind="write" xpath="/cib" />
   </acl_role>

   <acl_role id="minimal">

       <acl_permission id="minimal-standby" kind="read"
           description="allow reading standby node attribute (permanent or transient)"
           xpath="//instance_attributes/nvpair[@name='standby']"/>

       <acl_permission id="minimal-maintenance" kind="read"
           description="allow reading maintenance node attribute (permanent or transient)"
           xpath="//nvpair[@name='maintenance']"/>

       <acl_permission id="minimal-target-role" kind="read"
           description="allow reading resource target roles"
           xpath="//resources//meta_attributes/nvpair[@name='target-role']"/>

       <acl_permission id="minimal-is-managed" kind="read"
           description="allow reading resource managed status"
           xpath="//resources//meta_attributes/nvpair[@name='is-managed']"/>

       <acl_permission id="minimal-deny-instance-attributes" kind="deny"
           xpath="//instance_attributes"/>

       <acl_permission id="minimal-deny-meta-attributes" kind="deny"
           xpath="//meta_attributes"/>

       <acl_permission id="minimal-deny-operations" kind="deny"
           xpath="//operations"/>

       <acl_permission id="minimal-deny-utilization" kind="deny"
           xpath="//utilization"/>

       <acl_permission id="minimal-nodes" kind="read"
           description="allow reading node names/IDs (attributes are denied separately)"
           xpath="/cib/configuration/nodes"/>

       <acl_permission id="minimal-resources" kind="read"
           description="allow reading resource names/agents (parameters are denied separately)"
           xpath="/cib/configuration/resources"/>

       <acl_permission id="minimal-deny-constraints" kind="deny"
           xpath="/cib/configuration/constraints"/>

       <acl_permission id="minimal-deny-topology" kind="deny"
           xpath="/cib/configuration/fencing-topology"/>

       <acl_permission id="minimal-deny-op_defaults" kind="deny"
           xpath="/cib/configuration/op_defaults"/>

       <acl_permission id="minimal-deny-rsc_defaults" kind="deny"
           xpath="/cib/configuration/rsc_defaults"/>

       <acl_permission id="minimal-deny-alerts" kind="deny"
           xpath="/cib/configuration/alerts"/>

       <acl_permission id="minimal-deny-acls" kind="deny"
           xpath="/cib/configuration/acls"/>

       <acl_permission id="minimal-cib" kind="read"
           description="allow reading cib element and crm_config/status sections"
           xpath="/cib"/>

   </acl_role>

   <acl_target id="alice">
      <role id="minimal"/>
   </acl_target>

   <acl_target id="bob">
      <role id="read_all"/>
   </acl_target>

   <acl_target id="carol">
      <role id="read_all"/>
      <role id="operator"/>
   </acl_target>

   <acl_target id="dave">
      <role id="administrator"/>
   </acl_target>

</acls>

In the above example, the user alice has the minimal permissions necessary to run basic Pacemaker CLI tools, including using crm_mon to view the cluster status, without being able to modify anything. The user bob can view the entire configuration and status of the cluster, but not make any changes. The user carol can read everything, and change selected cluster properties as well as resource roles and location constraints. Finally, dave has full read and write access to the entire CIB.

Looking at the minimal role in more depth, it is designed to allow read access to the cib tag itself, while denying access to particular portions of its subtree (which is the entire CIB).

This is because the DC node is indicated in the cib tag, so crm_mon will not be able to report the DC otherwise. However, this does change the security model to allow by default, since any portions of the CIB not explicitly denied will be readable. The cib read access could be removed and replaced with read access to just the crm_config and status sections, for a safer approach at the cost of not seeing the DC in status output.

For a simpler configuration, the minimal role allows read access to the entire crm_config section, which contains cluster properties. It would be possible to allow read access to specific properties instead (such as stonith-enabled, dc-uuid, have-quorum, and cluster-name) to restrict access further while still allowing status output, but cluster properties are unlikely to be considered sensitive.