Review the use of Codespaces with private repositories

[StevenMaude]

We need to decide on policies and a process for OpenSAFELY users to work with Codespaces in private repositories.

:warning: This also has impacts on billing, and we may want to separate the billing issue out into another one.

Background

OpenSAFELY requires that users store their research code in the opensafely organization.

For public repositories, a user can always create a Codespace. This may end up being under their own GitHub account's usage.

Some OpenSAFELY users begin their work in a private repository, before later making it public. And, by default, there are restrictions on the use of Codespaces with private repositories in organizations.

This also has implications for billing. I believe. Bear with me, because it's a little convoluted. Here's my perhaps-not-complete understanding:

• it's possible to enable Codespaces for private repositories, and make those codespaces user-owned
  • That is, user-owned codespaces are always billed to the user.
• it's also possible to enable Codespaces for private repositories, and make those codespaces organization-owned
  • However, the organization-owned Codespaces setting seems to make the codespaces for that user in public repositories also organization-owned (I think).
  • So any use of Codespaces by that user in the organization then gets billed to the organization (again, I think, from quickly testing).

Tasks

• Look into and propose whether having user-owned or organization-owned codespaces is best for us.
  • User-owned means that we can allow access for all opensafely organization members globally. It does mean that users will have to individually work out how they pay for any extra Codespaces use exceeding the free tier.
  • Organization-owned means that the opensafely organization can manage billing for users working with Codespaces, should users need more credit than the free tier. It may mean that the opensafely organization also gets billed for those users in public repositories.
• Research if there are additional reasons, other than billing, to keep Codespaces in private repositories owned by our organization.
  • GitHub list other features of organization-owned codespaces.
• Confirm the steps needed to make this work for a given user working on a private repository in the OpenSAFELY organisation.
  • If we do restrict use with private repositories to a subset of users, this probably involves:
    1. User requests Codespaces access for a private repository, possibly asking tech support.
    2. Confirm the GitHub username of the user.
    3. Confirm that the user, or the institution/group that the user works for, is allowed access to Codespaces.
    4. If so, visit the opensafely organization Settings page.
    5. Select Codespaces
    6. Add a user to the list of Codespaces users.
    7. Press "Save".
  • Otherwise, we just allow all users to create codespaces for private repositories, and there is no further manual step.
• If we are going to incur billing for some external (to Bennett) user use of Codespaces, how do we recoup the costs?
  • There is a CSV report of who used what, updated daily..
  • How would we then collate that information, and bill the respective institution?
  • Would it be sensible/simpler in admin terms to have a small monthly threshold per external institution below which we accept the cost as the organization?
• If we allow for organization-owned repositories, what's a sensible spending limit?
• Suggest a process for auditing and removing users, once their projects have completed and they no longer need access. Is this tied to existing project completion tasks?

Assumptions

• There is still a need for some users to start working in private repositories, before making the repository public.

[lucyb]

Dependent on #12

[lucyb]

So, from what I can see within the UI and what I understand about Codespaces so far, there are two separate but related options here. Whether we allow our users to create Codespaces for private repos and who pays for them. The latter is being dealt with in #12 and the former is answered in this ticket. It seems like we will want our users to create Codespaces against private repos, especially since they're most likely to use them during the early part of their research when the repo is most likely to be private. I can't see any downsides to allowing them to do this, assuming we're happy with organisation ownership (#12), am I missing something?

I'm also assuming that a leaver's process is outside the scope of this work, as it belongs to the IG team and removing researchers from GitHub is a part of their process.

[StevenMaude]

I can't see any downsides to allowing them to do this, assuming we're happy with organisation ownership (https://github.com/opensafely-core/codespaces-initiative/issues/12), am I missing something?

I think the reason for the default "don't allow access to private repositories" is to limit where your code is being stored for risk/compliance reasons. From GitHub's documentation:

Alternatively, if you need to comply with security regulations that require increased control over the private code in your organization, you might want to disable GitHub Codespaces for all your members.

I don't believe this concern applies to opensafely as the intent is that most/all of the code should be eventually open. But this sounds like a formal decision that someone should make.

[StevenMaude]

I'm also assuming that a leaver's process is outside the scope of this work, as it belongs to the IG team and removing researchers from GitHub is a part of their process.

Incidentally, this is another reason why I think "organization-owned" makes sense, so that we have more control over access[^1]. "Organization-owned" means that the user shouldn't retain access to a codespace when removed. GitHub again:

If you remove a user's access to GitHub Codespaces, the user will immediately be unable to open existing codespaces they have created from your organization's private repositories.

I think this likely means the user immediately get removed from an open codespace. But maybe it needs confirming: the documentation's slightly unclear. I don't know if there are different behaviours on this surrounding:

• removing a user from the organization entirely
• removing a user from the list of approved Codespaces users, where a subset of users are allowed Codespaces access

[^1]: It additionally means we don't expect users to "pay" for codespace usage with their own monthly quota. And it also means that users don't have to manage their codespace usage individually, recording usage and expensing it to their employer. All that seems an improvement on the alternative. The only downside for us is that our Codespaces spending will be higher than it would be if each codespace was user-owned.

[lucyb]

I think the reason for the default "don't allow access to private repositories" is to limit where your code is being stored for risk/compliance reasons. From GitHub's documentation: I don't believe this concern applies to opensafely as the intent is that most/all of the code should be eventually open. But this sounds like a formal decision that someone should make.

The repo is expected to be made public after 12 months. It's the user's choice to keep it private before then. The only thing that might be of concern is the storage and processing of released outputs on the Codespace, which is being dealt with in #23 and being taken to Amir for a decision.

Incidentally, this is another reason why I think "organization-owned" makes sense

Agreed. This is being covered in #12.

I think this likely means the user immediately get removed from an open codespace. But maybe it needs confirming: the documentation's slightly unclear. I don't know if there are different behaviours on this...

Given that we expect to allow access to all organisation members, I would expect all users to lose access to Codespaces. I think the documentation is slightly unclear because it depends on if we've allowed collaborators or not (I don't think we should). There's also a slight behaviour difference with public repos rather than private. Probably we should ask the IG team to include a message to the user to save any work in a Codespace, although users shouldn't really be keeping unsaved work in a Codespace anyway.

---

I think the actions from this ticket are to:

• [x] Ensure the access policy is set to "all members"
• [x] Request that the IG Team update their leavers process to warn people about potentially losing access to Codespaces and to save anything that's not already been saved elsewhere. (DONE slack)

[lucyb]

I've now updated the Codespaces configuration in the opensafely organisation to be available to all researchers. I'll make a proper announcement tomorrow.

The configuration is as follows:

This was previously specific members only.

---

I've added quite a restrictive security policy to limit what people can do. I expect some people might want to do more than this, but I'd rather they asked us first

---

As part of this change I've also reduced the spend limit (discussed in #12). This is lower than it was, but slightly higher than we expect, so we get a warning if people start approaching that limit and we can investigate why