<div dir="ltr"><div>In support of the ongoing tools project work, we're proposing a new feature in Labs: per-project service users and groups. Feedback is welcome. Here's how it'll work:<br></div><div><br></div>

<div style>We're going to start by formalizing our uid and gid ranges. I'll leave the range specifics out for brevity. We'll be assigning a range of uids that can overlap between projects for the service users and groups.</div>

<div style><br></div><div style>Next, we're going to add an interface for managing users and groups within a project. projectadmins will be able to create new users, which will automatically create groups with the same names as the user names. The users and groups will automatically be prefixed with local-, as to avoid clashing with global users and groups (we've already disabled the creation of local-.* global users). So, mwbot would be: user: local-mwbot, group: local-mwbot. projectadmins will optionally select an initial member of the group.</div>

<div style><br></div><div style>When the user and group are created, a sudo rule will automatically be added to the project's sudo policy as well. This rule will allow anyone in the service group to sudo to the service user without authentication.</div>

<div style><br></div><div style>From a technical point of view, we're going to extend our abstraction of project trees in LDAP. Note, here's a shortened version of our DIT:</div><div style><br></div><div style>dc=wikimedia,dc=org</div>

<div style>    our base</div><div style><br></div><div style>ou=people,dc=wikimedia,dc=org</div><div style>    global user accounts</div><div style><br></div><div style>ou=groups,dc=wikimedia,dc=org</div><div style>    global groups</div>

<div style><br></div><div style>ou=projects,dc=wikimedia,dc=org</div><div style>    openstack projects</div><div style><br></div><div style>cn=<project>,ou=projects,dc=wikimedia,dc=org</div><div style>    a specific openstack project</div>

<div style><br></div><div style>ou=sudoers,cn=<project>,ou=projects,dc=wikimedia,dc=org<br></div><div style>    a sudo policy in a project</div><div style><br></div><div style>cn=default,ou=sudoers,cn=<project>,ou=projects,dc=wikimedia,dc=org<br>

</div><div style>    a rule in a sudo policy</div><div style><br></div><div style>cn=projectadmin,cn=<project>,ou=projects,dc=wikimedia,dc=org<br></div><div style>    a projectadmin role in a project</div><div style>

<br></div><div style>We'll be adding two OUs, each will hold a set of objects:</div><div style><br></div><div style>ou=people,<project>,ou=projects,dc=wikimedia,dc=org</div><div style>    a set of service users in a project</div>

<div style><br></div><div style>uid=local-<user>,ou=people,<project>,ou=projects,dc=wikimedia,dc=org</div><div style>    a service user in a project</div><div style><br></div><div style>ou=groups,<project>,ou=projects,dc=wikimedia,dc=org</div>

<div style>    a set of service groups in a project</div><div style><br></div><div style>cn=local-<group>,ou=groups,<project>,ou=projects,dc=wikimedia,dc=org</div><div style>    a service group in a project</div>

<div style><br></div><div style>We'll pull these in using nslcd.conf. It has support for multiple base entries per record type.</div><div style><br></div><div style>The service users will not be accessible via ssh, only via sudo. This will be our recommended use for shared applications, and will likely be our default for tools and bots.</div>

<div style><br></div><div style>- Ryan</div></div>