dashboard: github connect: investigate potential UX improvements

[dbarrosop]

Right now, we have two simple rules to allow users connecting a github repository to a project:

• you are either the org admin that installed the github app in it
• you are a member of a workspace where a project was already connected to that repo

This has some pros (it is simple and effective) and some cons (some users may find it frustrating as they may not understand why they can't connect a repo despite having access to it.

This issue is about investigating potential solutions for the latter without compromising security.

[dbj]

Thank you for opening this issue so this can be discussed. I personally perceive a security issue with this approach - the security of my business.

Point 2 I understand and does not allow new projects to connect to github, so I will focus on point 1 with regards to my comments: "you are the org admin that installed the github app".

I am writing these comments from the perspective of the Org Owner. I will call the admin who added the Nhost github app to my Org the "Nhost admin".

I see the following security concerns with the current approach:

1. There is no way for me or my team to go to the Nhost app and identify the Nhost admin whom my team needs to contact to connect a repo to an Nhost project
2. If the Nhost admin were to become unexpectedly unavailable:
   • In the immediate, new projects for my consulting business are put on hold as I cannot set up new Nhost projects
   • As I understand it, Nhost requires the current Nhost admin's permission to switch to a new Nhost admin, therefore, in the long run, new projects for my consulting business are put on hold, thus essentially shutting down my business
3. Being the Owner of the Org grants no privileges in the Nhost app - this ignores the meaning of Owner and elevates the sole Nhost admin above the Owner, putting future business in the control of someone who does not have claim to that responsibility; this essentially gives the Nhost admin veto power over the Owner

Proposed short term solutions:

1. List who the Nhost admin is so that everyone in the Org knows whom to work with to set up Nhost projects
2. Before the Nhost app can be added to github, require the Owner to acknowledge your two security policies listed above so they know what they are signing up for and so they choose very carefully who their Nhost admin is
3. Create a Guide/Documentation that clearly states these two security policies that you have listed above so that when this confusion arises, there is documentation to clarify the situation

Before proposing long term solutions, a few points:

• Github has Owner and Admin roles and grants access and privileges based on these roles. They are, by definition, inherently trusted by Github to administer repos.
• Nhost has two roles for Workspaces: Owner and Member. Owner, I believe, always has full privileges for the Workspace.

I propose the following long term solution:

• Repo access is granted by the Nhost app if the Owner of the Workspace is also the Owner of the Github Org

This one security change addresses concerns 1-3 above.

Additionally, I propose for consideration:

• Repo access is granted by the Nhost app if the Member (or Owner) of the Workspace is also a Github Admin of the Repo

The reason for this security change is it makes it much easier for the Owner to reason about who has true Admin privileges for a repo and it allows quick demotion of privileges on the Nhost side (which is an important aspect of security).

In other words, if the Nhost app were to rely on and trust the Github Admin role to determine privilege to connect to an Nhost project, the Owner can easily revoke that privilege simply by demoting the current Nhost admin in Github. Under the current security policies, to demote the current Nhost admin requires:

• The current Nhost admin being willing to give permission to Nhost to be demoted (i.e., change to a new Nhost admin)
• The new Nhost admin must be involved in the process with Nhost
• Nhost themselves must make the change manually (which may take hours or even days), thus extending the window over which a "demoted" Nhost admin still has privileges

Thanks for considering these points. :)

[dbarrosop]

As I understand it, Nhost requires the current Nhost admin's permission to switch to a new Nhost admin, therefore, in the long run, new projects for my consulting business are put on hold, thus essentially shutting down my business

It is mostly treated on a case by case basis and usually handled quickly to avoid disruption.

Re the rest, thanks for the ideas. We will evaluate them and see how to move forward.