"Fossies" - the Fresh Open Source Software Archive

Member "pacemaker-Pacemaker-2.0.2/doc/acls.txt" (6 Jun 2019, 7159 Bytes) of package /linux/misc/pacemaker-Pacemaker-2.0.2.tar.gz:


As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    1 Pacemaker Access Control Lists
    2 ==============================
    3 Tim Serong <tserong@novell.com>
    4 
    5 == Introduction
    6 
    7 The various tools for administering Pacemaker clusters (crm_mon,
    8 crm shell, cibadmin and friends, Python GUI, Hawk) can be used by
    9 the +root+ user, or any user in the +haclient+ group.  By default,
   10 these users have full read/write access.  Starting with Pacemaker
   11 version 1.1.5, flexible access control lists are introduced to
   12 provide different levels of administration to different users.
   13 
   14 == Prerequisites
   15 
   16 * Users are regular UNIX users, so the same user accounts must
   17   be present on all nodes in the cluster.
   18 * All user accounts must be in the +haclient+ group.
   19 * Pacemaker 1.1.5 or newer must be installed on all cluster nodes.
   20 * The CIB must be configured to use the pacemaker-1.1 or 1.2 schema.
   21   This can be set by running:
   22 
   23   cibadmin --modify --xml-text '<cib validate-with="pacemaker-1.1"/>'
   24 
   25 * The +enable-acl+ option must be set.  If ACLs are not explicitly
   26   enabled, the previous behaviour will be used (i.e. all users in
   27   the +haclient+ group have full access):
   28 
   29   crm configure property enable-acl=true
   30 
   31 * Once this is done, ACLs can be configured as described below.
   32 * Note that the +root+ and +hacluster+ users will always have full
   33   access.
   34 * If nonprivileged users will be using the crm shell and CLI tools
   35   (as opposed to only using Hawk or the Python GUI) they will need
   36   to have +/usr/sbin+ added to their path.
   37 
   38 == Configuring ACLs
   39 
   40 Access control lists consist of an ordered set of access rules.
   41 Each rule allows read or write access or denies access completely
   42 to a part of the CIB.  Rules are typically combined to produce a
   43 specific role, then users may be assigned to that role.  It is
   44 also possible to configure ACLs directly for individual users.
   45 
   46 ACLs may be configured using the crm shell or the Python GUI.
   47 The shell syntax is documented here.  Using the Python GUI should
   48 be reasonably straightforward once the concepts are understood.
   49 
   50 Note that rules are applied from first to last with the first
   51 matching rule being used.  This means specific +write+ rules
   52 usually need to be listed before general +read+ rules.  Any
   53 permission not explicitly granted is denied by default, but note
   54 that +write+ implies +read+, so there is no need to specify both
   55 to allow full read/write access.
   56 
   57 === Minimum Required ACLs
   58 
   59 In order for the various tools to work correctly, a certain minimum
   60 amount of data must be readable by the user invoking the tool.  In
   61 general, the safest thing to do is simply allow all users and roles
   62 read access to the entire CIB.
   63 
   64 === Role Syntax
   65 
   66 An ACL role is a set of rules which describe access rights to
   67 CIB.  Rules consist of an access right +read+, +write+, or +deny+
   68 and a specification denoting part of the configuration to which
   69 the access right applies.  The specification can be an XPath or a
   70 combination of tag and id references.  If an attribute is appended,
   71 then the specification applies only to that attribute of the matching
   72 element.
   73 
   74 ==== Usage
   75 
   76 ...............
   77     role <role-id> rule [rule ...]
   78 
   79     rule :: acl-right cib-spec [attribute:<attribute>]
   80 
   81     acl-right :: read | write | deny
   82 
   83     cib-spec :: xpath-spec | tag-ref-spec
   84     xpath-spec :: xpath:<xpath>
   85     tag-ref-spec :: tag:<tag> | ref:<id> | tag:<tag> ref:<id>
   86 ...............
   87 
   88 ==== Example Role: Read-only Access
   89 
   90 ...............
   91     role monitor \
   92         read xpath:"/cib"
   93 ...............
   94 
   95 This is a single rule which allows read-only access to the entire
   96 CIB.  Users with this role will be able to view the status of
   97 the cluster, but not make any changes.
   98 
   99 ==== Example Role: ``Operator'' Access
  100 
  101 ...............
  102     role operator \
  103         write xpath:"//crm_config//nvpair[@name='maintenance-mode']" \
  104         write xpath:"//op_defaults//nvpair[@name='record-pending']" \
  105         write xpath:"//nodes/node//nvpair[@name='standby']" \
  106         write xpath:"//resources//nvpair[@name='target-role']" \
  107         write xpath:"//resources//nvpair[@name='is-managed']" \
  108         write xpath:"//constraints/rsc_location" \
  109         read xpath:"/cib"
  110 ...............
  111 
  112 These rules specify that users with this role will be able to:
  113 
  114 . Turn maintenance mode on or off
  115 . Change whether pending operations are recorded
  116 . Put any node on standby, and bring any node back online
  117 . Start, stop, promote or demote any resource
  118 . Tell the cluster to manage, or not manage any resource
  119 . Migrate/move resources from node to note
  120 . View the status of the cluster
  121 
  122 Users with this role will not be able to reconfigure resources
  123 (change parameters, operations, etc.) or colocation or ordering
  124 constraints.
  125 
  126 ==== Example Role: Full Access
  127 
  128 ...............
  129     role administrator \
  130         write xpath:"/cib"
  131 ...............
  132 
  133 This is a single rule which allows full read-write access to the
  134 entire CIB.  Users with this role will have equivalent access to
  135 the +root+ and +hacluster+ users.
  136 
  137 === User Syntax
  138 
  139 ACLs can be defined for individual users using the same syntax
  140 as for roles.  Alternately, users can simply be assigned a given
  141 role.  The latter is considered best practice.
  142 
  143 ==== Usage
  144 
  145 ...............
  146     user <uid> {role:<role-ref>|rule [rule ...]}
  147 
  148     rule :: acl-right cib-spec [attribute:<attribute>]
  149 
  150     acl-right :: read | write | deny
  151 
  152     cib-spec :: xpath-spec | tag-ref-spec
  153     xpath-spec :: xpath:<xpath>
  154     tag-ref-spec :: tag:<tag> | ref:<id> | tag:<tag> ref:<id>
  155 ...............
  156 
  157 ==== Example
  158 
  159 ...............
  160     user alice role:monitor
  161     user bob role:operator
  162 ...............
  163 
  164 The above example assigns +alice+ the +monitor+ role and +bob+ the
  165 +operator+ role.
  166 
  167 == Advanced Usage
  168 
  169 Because ACLs can refer to elements and attributes in the CIB in a
  170 very granular way, it is possible to configure very specific rules.
  171 A refinement of the ``operator'' role above would be to allow
  172 manipulation of only a specific resource, for example:
  173 
  174 ...............
  175     role bigdb_admin \
  176         write xpath:"//primitive[@id='bigdb']/meta_attributes/nvpair[@name='target-role']" \
  177         write xpath:"//primitive[@id='bigdb']/meta_attributes/nvpair[@name='is-managed']" \
  178         write xpath:"//constraints/rsc_location[@rsc='bigdb']" \
  179         read ref:"bigdb" \
  180         read xpath:"//nodes/node" uname \
  181         read xpath:"//nodes/node" type \
  182         read xpath:"//crm_config/cluster_property_set" \
  183         read xpath:"/cib/status"
  184 ...............
  185 
  186 The first four rules are specific for the +bigdb+ resource. They
  187 allow modifying the +target-role+ and +is-managed+ meta
  188 attributes which effectively enables users in this role to
  189 stop/start and manage/unmanage the resource.  The constraints
  190 write access rule allows moving the resource around.  Finally, the
  191 user is granted read access to the resource definition.
  192 
  193 The bottom four rules are the absolute minimum read permissions
  194 necessary for proper operation of various Pacemaker tools,
  195 including `crm_mon` and the shell.  This is fine for viewing
  196 cluster status, but there are some tools for which this will
  197 not be sufficient access (notably `crm_simulate`), which is why it is
  198 generally recommended that read access be allowed to the entire
  199 CIB.
  200