| bd808 | |
| Aug 27 2022, 12:06 AM |
| F54077265: 0001-wikitech-Un-block-GitLab-accounts-when-un-blocked-on.patch | |
| May 21 2024, 4:52 PM |
| F42031563: 0001-wikitech-Un-block-GitLab-accounts-when-un-blocked-on.patch | |
| Feb 22 2024, 1:41 AM |
We have special hooks in the wikitech config which disable/enable associated accounts in Gerrit and Phabricator when blocking/unblocking a Developer account. We should add similar hook handlers for gitlab.wikimedia.org.
Relevant APIs:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Restricted Task | |||||
| Resolved | Security | bd808 | T316418 Add account locking for GitLab accounts to wikitech account blocking |
Filed as a security bug for WP:BEANS reasons only. Advertising this to our various technical LTAs before we close the loophole seems undesirable.
The patch needs a supporting patch in operations/puppet.git that I have prepared locally. That patch in turn needs a patch in labs/private.git to stub out the secret in non-production deployments that I have also prepared locally. Finally a prod root will need to make a patch to the private Puppet repo to set the real GitLab API token value for prod use. It will probably be easiest to post the Puppet patches through normal Gerrit workflows and get the SRE who merges them to also make the prod secret change. This is the sort of thing I often ask @Andrew to help with.
I have been testing using the API token that Tool-gitlab-account-approval currently uses, but we probably should have a separate token for this Wikitech integration. I'm ambivalent about this new token being tied to a new GitLab admin user or being generated as a new token on one of the existing bot admin accounts (StrikerBot, Gitlabaccountapprovalbot, or LDAP Sync Bot). @brennen and @thcipriani What are your thoughts on that?
Once we figure out the token and get it provisioned via the Puppet process we can deploy the hooks as a security patch, do some validation tests, and then upload the config change in Gerrit. Or honestly, we can simplify that flow a bit by going through Gerrit for the initial deployment. This task is currently only private because I didn't want a WP:BEANS announcement of "hey look! GitLab accounts aren't blocked when a Developer account is blocked" in the backlog for months. Having an unmerged patch in Gerrit for an hour or less seems much less concerning.
This seems like an extension of the functionality of the LDAP Sync Bot (if you squint hard enough), plus that means fewer credentials to rotate (using one bot vs multiple bots with multiple credentials).
Also tagging in collaboration-services since they helped us setting up credentials for that bot, and would need to be involved in any credential rotation needed going forward.
I am wondering if this should still be related to Wikitech because of the ongoing work on Bitu (idm.wikimedia.org) and it potentially replacing it.
I think that is a great, but also separate question @Dzahn. To date I have not had any questions from the Bitu folks about taking over this aspect of Developer account management, but at some point if we are going to fulfill the dream of T161859: Make Wikitech an SUL wiki it will need to move.
Removing collaboration-services, please tag us again if credential rotation is coming up.
I talked to @eoghan during today's Collab Services sync time and he graciously offered to handle the needed Puppet patches for me. I will get the two I can write up in Gerrit and then he can do the work to update the private repo and land the other patches.
How many devops nerds does it take to provision a secret on the cloudweb hosts? Today at least 4, but with help from @eoghan, @dcaro, @taavi, and myself it is now done. 😅
I have also prepared a "GitLab block test" Developer account and attached it on Phabricator, Gerrit, and GitLab to use in validating that blocks and unblocks work as hoped.
https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1035576 has been deployed and verified to block and unblock. The GitLab block takes effect immediately and the user is shown "Your account has been blocked. Please contact your GitLab administrator if you think this is an error." on the sign in screen.
[21:33] < wikibugs> (CR) TrainBranchBot: [C:+2] "Approved by thcipriani@deploy1002 using scap backport" [mediawiki-config] - https://gerrit.wikimedia.org/r/1035576 (https://phabricator.wikimedia.org/T316418) (owner: BryanDavis) [21:34] < wikibugs> (Merged) jenkins-bot: wikitech: (Un)block GitLab accounts when (un)blocked on wikitech [mediawiki-config] - https://gerrit.wikimedia.org/r/1035576 (https://phabricator.wikimedia.org/T316418) (owner: BryanDavis) [21:34] <logmsgbot> !log thcipriani@deploy1002 Started scap: Backport for [[gerrit:1035576|wikitech: (Un)block GitLab accounts when (un)blocked on wikitech (T316418)]] [21:37] <logmsgbot> !log thcipriani@deploy1002 thcipriani and bd808: Backport for [[gerrit:1035576|wikitech: (Un)block GitLab accounts when (un)blocked on wikitech (T316418)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug) [21:37] <thcipriani> now it's prompting me to continue since it's on testservers, but since this is a wikitech change we can't test it there. bd808 anywhere you want to "scap pull" before I tell it to go ahead? [21:38] < bd808> thcipriani: I can manually pull to the 2 wikitech boxen I suppose. Do you think that will test anything important? [21:39] < bd808> The change is on both of them already via manual patching I did before uploading to gerrit [21:40] <thcipriani> bd808: sounds like you tested the important bits on other machines right prior to this, so that'll probably only test the deploy [21:40] <thcipriani> so I'll go ahead and y [21:40] < bd808> coolio [21:40] <logmsgbot> !log thcipriani@deploy1002 thcipriani and bd808: Continuing with sync [21:52] <logmsgbot> !log thcipriani@deploy1002 Finished scap: Backport for [[gerrit:1035576|wikitech: (Un)block GitLab accounts when (un)blocked on wikitech (T316418)]] (duration: 18m 01s) [21:52] <thcipriani> ^ bd808 all done
This task can be made public now that the fix is deployed.