[GH Request] Enable edx-status-bot to get access to dependabot alert status to all openedx repos

[ohnickmoy]

Firm Name

2U

Urgency

Medium (< 2 weeks)

Requested Change

the edx-status-bot needs permission to access the dependabot alert status for open edx repositories. There's an accompanying issue here: openedx/edx-repo-health#366

Reasoning

There was a recent check added to edx-repo-health for dependabot alert status. However, when inspecting the dashboard spreadsheet, there's no info populating for the openedx repos, save for one, openedx/edx-app-android. We suspect that the edx-status-bot doesn't have access to the repo info, either because on the token level, or on the repo level.

More info about dependabot alert can be found here: https://docs.github.com/en/rest/dependabot/alerts?apiVersion=2022-11-28#list-dependabot-alerts-for-a-repository

[openedx-workflow-automation]

Thank you for your report! @openedx/axim-oncall will triage within a business day. Simple requests usually take 2-3 business days to resolve; more complex requests could take longer.

[ormsbee]

@feanil, @kdmccormick: Is there an appropriate group to add edx-status-bot to?

[kdmccormick]

It depends, what type of access does edx-status-bot need? Reading the linked issues, @ohnickmoy I'm not sure whether you're requesting increased repository access (which we can do with teams) or access token scopes (which we'd have to do by regenerating the bot's token).

[ormsbee]

FWIW, right now, edx-status-bot is listed as an outside collaborator with Write access to only edx-app-android.

[ohnickmoy]

That's what I'm trying to figure out. What's the access that will allow the edx-status-bot to read dependabot alerts to add it to the health dashboard checks. Will it be on the token level, or repo level. If we can do it on the repo level with current token access in place, then increase the repo access for the bot.

As of now, I'm waiting on github to provide access to the account so I can see what's going on with the token permissions.

[ohnickmoy]

@ormsbee, @kdmccormick, I believe the bot needs access to the repos. My though process being, I got access back to edx-status-bot when github temporarily removed 2FA. By removing 2FA, it got removed from the edx org, but lost access to openedx/edx-app-android. Afterward, I noticed that the dependabot alert stats weren't being reported for the edx-app-android repo.

To @ormsbee's original comment, the bot was listed as an outside collaborator with write access. Will this be alright for the other repos?

[kdmccormick]

Thanks for the context Nick. We prefer that all repository access is done through teams rather than granted to individual users as it's easier for us to audit. Since outside collaborators cannot be added to teams, we'd rather avoid the outside collaborator model. I think it would sense to add the edx-status-bot back to the org, and then add to it a team (creating a new team if necessary) that grants it the appropriate access.

[ohnickmoy]

@kdmccormick, is there a team or group that edx-status-bot can be added to already?

[ohnickmoy]

interestingly enough, i can't invite people to the org, but I can make a team, so if possible, can someone add https://github.com/edx-status-bot to @openedx/edx-status-bot and then set the right permissions structure to the team. i think after that gets squared away, i can run the jenkins job for the health dashboard to see if the data gets picked up and then we are on our way.

[kdmccormick]

Sorry @ohnickmoy , I should've been clearer, I was recommending that @ormsbee do those things.

[feanil]

Isn't edx-status-bot the bot user whose credentials we no longer have? I thought its 2FA was lost and we couldn't login as that user anymore. That's why it wasn't previously added because it can't accept the invite to the org. Were the 2FA keys for it recovered?

[feanil]

Also, when we do get the user part figured out, the user will need write or higher access to be able to see the dependabot alerts. There is currently no group that provides write access to all public openedx repositories so a new one will probably have to be created. We'll probbaly want to add a repo-check.py check for this user/team to ensure that as we add new repos it continues to get access, if we decided having a bot with write access to all public repos is a thing we're okay with.

At first blush, I'm not excited about a bot user with write access to all the repos, but sadly it's not a new pattern, we may want the new user to be managed by Axim and simply provide 2U with a access token that has just the permissions they need for the health check jobs to succeed.

[feanil]

Missed Nick's message, sounds like we have access to the user again. My note above about the access stand, that user was never added to the org during the initial transition so can be treated essentially as a new bot user being added to the org. The security implications of it's write access are complex.

[kdmccormick]

I think we are in a bit of a funny situation. I think we need to choose one of two paths forward:

1. Axim takes control of the bot user (or makes a new one) and begins to run the repo health job on our infrastructure. We could then feel more comfortable granting the bot write access to every repo in the org.

2. 2U continues to manage the bot user and run the repo health job. We grant bot user access to push-pull-all., giving it write access to same repos which 2U employees currently have write access. This means that there are some repos (the ones outside push-pull-all) whose dependabot alerts will not show up on the repo health dashboard.

@feanil , does that sound right to you from a security perspective?

[feanil]

Yea, I would prefer 1, but would be cool with 2 as it doesn't raise any maintainer or CC related questions.

[kdmccormick]

@ohnickmoy , I think the choice is up to you. Option 2 is something we could do right now, easily. Option 1 is something we'd need to scope out a bit. We could always start with 2 and then do 1 later if it was helpful for you all.

[ormsbee]

I'd also lean to (2) in the short term because I'm not sure when we'd do (1), FWIW. @ohnickmoy: What do you think?

[ohnickmoy]

I'll consult the brain trust. Thanks for providing options and responding to this.

[ohnickmoy]

@kdmccormick , @feanil , @ormsbee , so after mulling over it and consulting people, seems like people are down with option 1. axim would run the job on open edx repos, and edx could run a similar, or same, job on edx repos.

[ohnickmoy]

@kdmccormick, @feanil, @ormsbee, getting back to this. how do you propose the execution of option 1? i'm trying to determine what edx needs to do, if applicable. A new bot for axim would probably be best, IMO. Would we need to create a new token, or would that be handled by axim? Also, does the jenkins job itself need to be modified?

Thanks!

[kdmccormick]

@ohnickmoy , I think it'd be best to treat this as a brand new request, under the context that 2U/edX is asking Axim to run a tool (edx-repo-health) that Axim doesn't know much about. We'd need to know:

• What code do you want us to run, and how often?
• How do you recommend we automate it? eg, Can we run this through GitHub Actions? We don't have a Jenkins server and I don't imagine we would want to create one.
• Where should the output go?

[ohnickmoy]

Thanks for the fast reply. This was helpful and will help us sort out next steps.

For point one: this is the code that gets run: https://github.com/openedx/edx-repo-health/blob/master/repo_health/check_dependabot_alerts.py and it gets run daily based on the jenkins job

For point two, most likely GH actions. There's something in the works (edx/edx-arch-experiments#66) to at least see feasibility.

Output goes to a spreadsheet (repo-health-dashboard), but i'm wondering if two different job runs (one for edx repos and one for open edx) will cause weird issues to the output (don't think so with some tweaks, but i could be proven otherwise)

[ohnickmoy]

In any case, I'll formally move this over into a new request soon.

[kdmccormick]

Thanks Nick!

[kdmccormick]

Closed in favor of #738