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
,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
environment: qa
datacenter: tor
aRecord: 10.10.12.53
dc: 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