[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Using multi-value attributes for ACLs

Andrew Heagle wrote:

After reading Philip Colmer's "Access control" (Jan 24) thread and trying out
using sets on a test server, this solution will work out quite nicely. Just
have to change/add any "role" with the an appropriate owner attribute pointing
to the proper group.
Sets have a pretty high performance cost. The better solution in your case is to use an appropriately located "break" statement. Read slapd.access(5). 


On Thu, Feb 7, 2013 at 11:22 AM, Andrew Heagle <andrew@logaan.com
<mailto:andrew@logaan.com>> wrote:

    Hi,

    At my work, we use LDAP as the backend for Puppet node definitions. Each
    host would have an LDAP entry specifying things like which puppet classes
    to apply, host specific variables, environment (which git branch to use
    for puppet manifests and a few other things.

    There are different teams that would like to be able to manage these
    attributes when deploying software. For example, DBA should be able to
    manage DB servers while QA need to be able to configure their hosts to
    test different software.

    Any hosts that DBA can manage has a role=DBA applied and likewise an QA
    hosts has role=QA set. Since role is multi-valued, a QA DB can have
    role=DBA and role=QA set on it, since both QA and DBAs might need to be
    able to make changes to the host.

    Our slapd.conf has these ACLS
    access to dn.subtree="ou=hosts,dc=example,dc=info" filter=(role=DBA)
             attrs=puppetclass,puppetvar,environment
             by
    group/groupOfUniqueNames/uniqueMember="cn=dba,ou=groups,dc=example,dc=info" write
             by group="cn=sysadmin,ou=ldapgroup,dc=example,dc=info" write
             by * read

    access to dn.subtree="ou=hosts,dc=example,dc=info" filter=(role=QA)
             attrs=puppetclass,puppetvar,environment
             by
    group/groupOfUniqueNames/uniqueMember="cn=qa,ou=groups,dc=example,dc=info"
    write
             by group="cn=sysadmin,ou=ldapgroup,dc=example,dc=info" write
             by * read


    let say a LDAP host entry looks like this:
    dn: cn=qadb1.int.example.info
    <http://qadb1.int.example.info>,ou=QAServers,dc=tor,ou=hosts,dc=example,dc=info
    objectClass: puppetClient
    objectClass: device
    objectClass: exampleHost
    objectClass: dNSDomain2
    cn=qadb1.int.example.info <http://qadb1.int.example.info>
    role: DBA
    role: QA
    environment: qa
    datacenter: tor
    aRecord: 10.10.12.53
    dc: qadb1.int.example.info <http://qadb1.int.example.info>

    if a DBA wants to edit this entry, it hits the first ACL, sees the DBA
    user in the dba group and allows the change. If a QA person wants to edit
    the entry, it hits the first ACL, sees role=DBA, and checks the DBA group,
    but the QA user is not in the DBA group and rejects the change, even
    though the next ACL would have allowed the change, it just doesn't hit it.

    Is it possible to somehow use the ACLs above without have to make lots of
    ACL rules that combine all the possible combos, such as role=DBA, role=QA,
    role=DBAQA, role=DBADEV, role=DBABI, etc...? Such as adding a third entry
    (eg, this would work, but would like to find a more elegant solution):

    access to dn.subtree="ou=hosts,dc=example,dc=info" filter=(role=DBAQA)
             attrs=puppetclass,puppetvar,environment
             by
    group/groupOfUniqueNames/uniqueMember="cn=dba,ou=groups,dc=example,dc=info" write
             by
    group/groupOfUniqueNames/uniqueMember="cn=qa,ou=groups,dc=example,dc=info"
    write
             by group="cn=sysadmin,ou=ldapgroup,dc=example,dc=info" write
             by * read


    Thanks,
    Andrew





--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/