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.
On Thu, Feb 7, 2013 at 11:22 AM, Andrew Heagle <[email protected]> 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 > ,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 > >
