[Pacemaker] Multi-level ACLs for the CIB

[Andrew Beekhof]

On Mon, Dec 7, 2009 at 9:06 AM, Yan Gao <ygao at novell.com> wrote:
> Hi all, Andrew,
>
> This planned feature was proposed by Lars. After some discussions
> with Lars and Tim, I'm sharing it here, and looking forward to hearing
> your thoughts and suggestions.
>
> The goal of this feature is to provide different levels of
> administration to users.
>
> Some of the common scenarios:
> 1. There are cluster admins who are allowed to do "everything", usually
> they have root on the cluster.
>
> 2. Some operators, allowed to see the cluster status, perhaps modify
> node status (shutdown/standby). Possibly not allowed to see specific
> bits of the CIB (such as passwords for the stonith devices).
>
> 3. Admins who are allowed access only to a very specific resource, but
> not to others. (ie, application admins who only may (re-)start/stop
> their own service/VM.) Also restricted read rights.
>
> 4. Monitors who only have restricted read rights.
>
> There might be others...So we'd like to make it flexible. Users should
> be able to configure any of the system accounts to be a particular role
> as they wish.
>
> Basically, we'd like to see an ACL mechanism. It would be implemented at
> the CIB level. So that all the clients - CLI , CRM shell, GUI, etc... -
> could benefit. Clients are authenticated via PAM, so we can use uid/gid
> for identification.

Actually you probably can't do this.
Daemons (like the cib) which are not running as root can only
authenticate the username/password of the user they're running as.

>
> The original idea is using XPath/XSLT to achieve this. But it was
> considered impractical. The syntax would become so ugly. Hence we now
> prefer a black-/whitelist, and the first match defines whether access is
> granted or denied.
>
> The basic implementation idea is to introduce a new "acls" section in
> the CIB under "configuration" which defines these permissions.
>
> Example syntax:
>
> ..
>  <configuration>
>    <resources>
>      <primitive id="stonith1" class="stonith" type="external/riloe">
>        <instance_attributes id="stonith1-instance_attributes">
>          <nvpair id="stonith1-instance_attributes-hostlist"
> name="hostlist" value="host1"/>
>          <nvpair id="stonith1-instance_attributes-ilo_hostname"
> name="ilo_hostname" value="192.168.0.101"/>
>          <nvpair id="stonith1-instance_attributes-ilo_user"
> name="ilo_user" value="admin"/>
>          <nvpair id="stonith1-instance_attributes-ilo_password"
> name="ilo_password" value="123456"/>
>        </instance_attributes>
>        <meta_attributes id="stonith1-meta_attributes">
>          <nvpair id="stonith1-meta_attributes-target_role"
> name="target_role" value="stopped"/>
>        </meta_attributes>
>      </primitive>
>    </resources>
>    <constraints>
>      <rsc_location id="loc-stonith1" node="host2" rsc="stonith1"
> score="1000"/>
>    </constraints>
>    <acls>
>      <acl uid="ygao">
>        <write ref="stonith1-meta_attributes-target_role"
> attribute="value" />
>        <write ref="loc-stonith1"/>
>        <deny ref="stonith1-instance_attributes-ilo_password" />
>        <read ref="stonith1" />
>        <read ref="#status" />

Please, no hashes here.

>        <deny />
>      </acl>
>    </acls>
>  </configuration>
> ..
>
> Basically, this means that the user "ygao" would be allowed to write to
> the target-role and the location of the resource "stonith1", read all of
> the "stonith1" definition except the "ilo_password" nvpair,  and be
> allowed to see the "status" section; everything else would be denied.
>
> The final "<deny />" might not be needed. As Tim suggested, if no ACL
> matches the object, it's more secure to just assume access is denied.
>
> Data going out from or in to the CIB from these accounts would be
> matched against and filtered through this list.
>
>
> Hence if "ygao" excutes:
>> cibadmin -Q -o resources
>
> The outputs would be:
>    <resources>
>      <primitive id="stonith1" class="stonith" type="external/riloe">
>        <instance_attributes id="stonith1-instance_attributes">
>          <nvpair id="stonith1-instance_attributes-hostlist"
> name="hostlist" value="host1"/>
>          <nvpair id="stonith1-instance_attributes-ilo_hostname"
> name="ilo_hostname" value="192.168.0.101"/>
>          <nvpair id="stonith1-instance_attributes-ilo_user"
> name="ilo_user" value="admin"/>
>        </instance_attributes>
>        <meta_attributes id="stonith1-meta_attributes">
>          <nvpair id="stonith1-meta_attributes-target_role"
> name="target_role" value="stopped"/>
>        </meta_attributes>
>      </primitive>
>    </resources>
>
> He cannot see the "ilo_password".
>
> If there's more than one user that needs the same access rights. We
> could specify that like:
>
> ..
> <acl role="ha_monitor">
>  <read ref="#status"/>
> </acl>
> <acl uid="ygao">
>  <ref role="ha_monitor"/>
> </acl>
> <acl uid="tesrong">
>  <ref role="ha_monitor"/>
> </acl>
> ..
>
> or could be like:
> ..
> <acl role="ha_monitor">
>  <users>
>    <uid="ygao"/>
>    <uid="tesrong"/>
>  </users>
>  <read ref="#status"/>
> </acl>
> ..
>
> And it should also support system group:
> ..
> <acl gid="ha_group">
>  <read ref="#status"/>
> </acl>
> ..
>
> I think the syntax isn't perfect yet, but that should be the basic
> direction. I'd like to hear your thoughts about it.

Seems reasonable.
I do worry about how big the acls section is going to grow though.

>
> Andrew ever mentioned two criteria:
>> It should be implemented cleanly.
> I'll look into it, and see how we could achieve that. Andrew, if you
> have any suggestions on that, I would be very appreciated:-)
>
>> It could be compiled out.
> The basic consideration is this would impact the performance of CIB.
> Actually for superusers (root/hacluster), all these security checks
> would be bypassed. So for all of the current operations which is done by
> superusers including the internal processes, the performance would be
> preserved. Anyway, we'll make it optional when compiling.

If you can keep the overhead to near zero for the root/no-acls case,
then I'd not be too concerned about being able to compile it out.

>
> Any comments or suggestions are welcome.
>
> Thanks,
>  Yan
> --
> ygao at novell.com
> Software Engineer
> China Server Team, OPS Engineering
>
> Novell, Inc.
> Making IT Work As One™
>
> _______________________________________________
> Pacemaker mailing list
> Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>