[tor-bugs] #32519 [Internal Services/Tor Sysadmin Team]: improve user onboard/offboarding procedures
Tor Bug Tracker & Wiki
blackhole at torproject.org
Tue Apr 28 00:25:08 UTC 2020
#32519: improve user onboard/offboarding procedures
-------------------------------------------------+---------------------
Reporter: anarcat | Owner: tpa
Type: defect | Status: new
Priority: Medium | Milestone:
Component: Internal Services/Tor Sysadmin Team | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------------------------------+---------------------
Old description:
> while working on the nextcloud project, we realized it wasn't exactly
> trivial to setup the LDAP bridge because of our specific requirements (no
> direct connexion, offline support). so we just didn't implement it yet
> (#32332). i added a note about this in the
> [https://help.torproject.org/tsa/howto/retire-a-user/ retire a user]
> procedure, but then i realized there are probably many other such
> services that do *not* connect with LDAP.
>
> On the top of my head, there's at least Trac and mailing lists, for
> example, which are managed completely separarely. Audit
> [[org/operations/services]] and see which services are manager manually
> and which aren't.
>
> Then make sure there's an automated way to add/remove users to services,
> either by hooking up the service with LDAP, or by creating a wrapper
> script that will manage those accesses.
>
> So the following needs to be done here:
>
> * [ ] document, in [https://help.torproject.org/tsa/howto/new-person/
> new-person] and [https://help.torproject.org/tsa/howto/retire-a-user
> retire-a-user], the various services to add/remove people to
> * [ ] automate the above with a script or LDAP
>
> Note that the two pages have different scope: `new-person` is about TSA
> while `retire-a-user` is broader. This should also be converged, probably
> in the broader sense.
>
> Also note that a particularly tricky situation is when we want to do a
> *partial* removal. For example, maybe the person needs to be removed from
> tor-internal, but keep access to some servers. Or removed from server,
> but keep an email alias.
>
> The latter case is especially sensitive: some people feel keeping their
> email alias around forever is an inalienable right and that we should
> keep forwarding their email even after they are fully retired from Tor.
> This policy needs to be clarified, see #32558 for that particularly
> tricky problem.
New description:
while working on the nextcloud project, we realized it wasn't exactly
trivial to setup the LDAP bridge because of our specific requirements (no
direct connexion, offline support). so we just didn't implement it yet
(#32332). i added a note about this in the
[https://help.torproject.org/tsa/howto/retire-a-user/ retire a user]
procedure, but then i realized there are probably many other such services
that do *not* connect with LDAP.
On the top of my head, there's at least Trac and mailing lists, for
example, which are managed completely separarely. Audit
[[org/operations/services]] and see which services are manager manually
and which aren't. Those services have been identified as particularly out
of sync:
* rt.torproject.org
* blog.torproject.org
* email, see also #32558
* IRC, the @tor-tpomember group
* Nagios contacts (almost cleaned up, but will still need checking for
sysadmins arriving/departing)
That list is not exhaustive.
Then make sure there's an automated way to add/remove users to services,
either by hooking up the service with LDAP, or by creating a wrapper
script that will manage those accesses.
So the following needs to be done here:
* [ ] document, in [https://help.torproject.org/tsa/howto/new-person/
new-person] and [https://help.torproject.org/tsa/howto/retire-a-user
retire-a-user], the various services to add/remove people to
* [ ] automate the above with a script or LDAP
Note that the two pages have different scope: `new-person` is about TSA
while `retire-a-user` is broader. This should also be converged, probably
in the broader sense.
Also note that a particularly tricky situation is when we want to do a
*partial* removal. For example, maybe the person needs to be removed from
tor-internal, but keep access to some servers. Or removed from server, but
keep an email alias.
The latter case is especially sensitive: some people feel keeping their
email alias around forever is an inalienable right and that we should keep
forwarding their email even after they are fully retired from Tor. This
policy needs to be clarified, see #32558 for that particularly tricky
problem.
--
Comment (by anarcat):
regroup the list of services in the description explicitely.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32519#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list