dc: qadb1.int.example.infoHi,environment: qa
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,ou=QAServers,dc=tor,ou=hosts,dc=example,dc=info
objectClass: puppetClient
objectClass: device
objectClass: exampleHost
objectClass: dNSDomain2
cn=qadb1.int.example.info
role: DBA
role: QA
datacenter: tor
aRecord: 10.10.12.53
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