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