| taavi | |
| Mar 11 2024, 1:33 PM |
| F57523713: Skærmoptagelse 2024-09-19 kl. 15.30.36.webm | |
| Sep 19 2024, 1:37 PM |
Currently wikitech functions as an one-stop service to "globally" block a Developer account. Any Wikitech administrator and content administrator can use MediaWiki's Special:Block to block the user from
The relevant hooks providing this functionality resides under wmf-config/wikitech.php
Given that wikitech will have no ldap access and will function like every other wiki, we should move this to Bitu
| Status | Subtype | Assigned | Task | |
|---|---|---|---|---|
| · · · | ||||
| Duplicate | None | T367287 Update Wikitech's LDAP credentials to be read-only | ||
| Resolved | jijiki | T371592 LdapAuthentication: Disable extension from Wikitech | ||
| Resolved | SLyngshede-WMF | T359820 Developer Account Blocking: Migrate the one-stop Developer (un)Blocking from Wikitech to Bitu | ||
| In Progress | SLyngshede-WMF | T376991 Publically available log of blocked/unblocked accounts. | ||
| · · · |
On the LDAP account side, the block happens via the mechanism described in T168692: Blocking an account on wikitech should disable LDAP logins:
Undoing the block clears both attributes which allows the account to authenticate again. The lack of any mangling of account data (like changing the password to some unknown/invalid value) makes this an easily reversed action which in turn allows us to be bold in blocking by knowing that an incorrect block is easily reversed.
See https://gerrit.wikimedia.org/r/c/mediawiki/extensions/LdapAuthentication/+/500681 and https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/497866 for the initial PHP implementation.
When implemented, this blocking/unblocking mechanism should have a public audit trail similar to https://wikitech.wikimedia.org/wiki/Special:Log?type=block that records who was (un)blocked by whom, when, and why. The block/unblock actions should also ideally be exposed via a web API of some kind so that other tools can poke bitu to do the needful instead of needing to implement all of the logic again themselves.
Change #1060092 had a related patch set uploaded (by Slyngshede; author: Slyngshede):
[operations/software/bitu@master] Wikimedia: New management command for blocking users in systems.
Change #1060092 merged by jenkins-bot:
[operations/software/bitu@master] Wikimedia: New management command for blocking users in systems.
@SLyngshede-WMF I would like to understand how I and others will be able to use this new blocking functionality when the current system has been removed from Wikitech on (planned) October 1. A quick review of https://wikitech.wikimedia.org/wiki/Special:Log?type=block shows that @taavi, @JJMC89, and myself are the most common admins to deliver blocks recently, but a longer list when looking back over the past 12 months or so of activity.
@bd808 If you look at this patch: https://gerrit.wikimedia.org/r/c/operations/software/bitu/+/1066723 (Sorry for the title, I'm currently cleaning it up).
It is a Django management command, so from one of the idm hosts you'll be able to run e.g.
$ sudo bitu block -l <username>to block LDAP access, or -p for Phabricator (or -a) for all.
Who will have access to the idm hosts?
$ ssh idm1001.wikimedia.org bd808@idm1001.wikimedia.org: Permission denied (publickey).
@JJMC89 Nope, that an issue, but we have the functionality, so I'll add UI elements, so people without shell access can do the blocking.
I'll see how much I can get done tomorrow a send you something to review.
Has work started yet on the inverse unblock action? It has been an important principal of this functionality up to now that it is easily reversible so that we can block first and sort out details later knowing that it will be simple to restore access if the block was found to be hasty.
@bd808 No, not yet, but that is a good point. LDAP is easy enough. I'll take a look at what is involved in the others.
@SLyngshede-WMF The draft system also seems to be missing a public audit log of block/unblock actions and an admin provided description of each action. The Wikitech/MediaWiki functionality for this is exposed by https://wikitech.wikimedia.org/wiki/Special:Log?type=block.
All of the needed logic for restoring Phabricator, Gerrit, and GitLab accounts after the LDAP record is unblocked exists in the current hooks system at https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/wikitech.php. The $wgHooks['UnblockUserComplete'] hooks handle the unblock case.
Change #1074178 had a related patch set uploaded (by Slyngshede; author: Slyngshede):
[operations/software/bitu@master] UI for account blocking.
Where we're at after today. I've implemented much of the UI, I think. Logging is added. Gerrit integrations is of half way there.
Todo tomorrow:
Demo
Change #1074960 had a related patch set uploaded (by Slyngshede; author: Slyngshede):
[operations/software/bitu@master] Block User: Add LDAP blocking/unblocking.
Change #1075115 had a related patch set uploaded (by Slyngshede; author: Slyngshede):
[labs/private@master] Dummy Gitlab tokens for IDM.
A dedicated GitLab "bot" user account-blocking-bot was created to manage the API keys. I created the bot on the test instance and production (so it should be available later today on the replicas as well). The API keys are in private puppet ( /srv/git/private/hieradata/role/common/idm_test.yaml:profile::idm::gitlab_token).
Let me know if you need any help testing this against the test instance or replicas before production.
Change #1075115 merged by Slyngshede:
[labs/private@master] Dummy Gitlab tokens for IDM.
Change #1075141 had a related patch set uploaded (by Slyngshede; author: Slyngshede):
[operations/puppet@production] C:idm Add gitlab configuration for account blocking.
Change #1074178 merged by jenkins-bot:
[operations/software/bitu@master] Account blocking
Change #1074960 abandoned by Slyngshede:
[operations/software/bitu@master] Block User: Add LDAP blocking/unblocking.
Reason:
Merged to annoying, replaced by: 1075218
Change #1075141 merged by Slyngshede:
[operations/puppet@production] C:idm Add configuration for account blocking.
Change #1078535 had a related patch set uploaded (by Slyngshede; author: Slyngshede):
[operations/puppet@production] P:idm Add Taavi to list of "Account Manager".
Change #1078535 merged by Slyngshede:
[operations/puppet@production] P:idm Add Taavi to list of "Account Manager".
@taavi I just added you to the list of of people who can block users. You should have a "Block/unblock accounts" in the menu now.
I wonder if using existing ldap groups would be better than a list of individual users would be better, eg: wmf+ops+nda would probably cover enough people to deal with spam
I think the process is documented here: https://wikitech.wikimedia.org/wiki/IDM/Account_Blocking under the "Web UI" section. Docs could become a bit better, but it's definitely a start.
I have not found an explicit task in the backlog, but @SLyngshede-WMF has mentioned a plan to move the ACL from ops/puppet to an LDAP group with Bitu acting as the system to both request and approve changes to the group membership.
In the nearer term as @akosiaris mentioned in T359820#10233942 https://wikitech.wikimedia.org/wiki/IDM/Account_Blocking offers manual ACL curation by request. I think it would be nice to get at least a few stewards in the list; @JJMC89 would you mind talking to folks and coming up a set of accounts who we should grant the right to?
! In T359820#10234357, @bd808 wrote:
I think it would be nice to get at least a few stewards in the list; @JJMC89 would you mind talking to folks and coming up a set of accounts who we should grant the right to?
Change #1081220 had a related patch set uploaded (by BryanDavis; author: Bryan Davis):
[operations/puppet@production] bitu: Add some stewards to the list of account managers
Change #1081220 merged by Slyngshede:
[operations/puppet@production] bitu: Add some stewards to the list of account managers