Merge pull request #172 from sgibson91/github-auth

admin/howto/manage-users.md

@@ -13,7 +13,7 @@ Users can prove who they are by logging in via an *authentication provider*. Cur
 
 1. *Google*. This includes public `@gmail.com` accounts, as well as [Google Workspace](https://workspace.google.com/) accounts set up for your workspace or university. If you use the GMail interface to access your work / university email, it can be used here.
 
-2. [*GitHub*](https://github.com/). Extremely popular community of people creating, publishing and collaborating on code. Accounts are free, and many people already have them especially since the target community for most hubs are people who also write some kind of code.
+2. [*GitHub*](https://github.com/). Extremely popular community of people creating, publishing and collaborating on code. Accounts are free, and many people already have them especially since the target community for most hubs are people who also write some kind of code. We can setup GitHub authentication so you can either manage a list of specific GitHub handles in the [JupyterHub ddmin panel]((admin/management/admin-panel)), or so that members of a specific GitHub organisation or team are automatically authorised to use the hub.
 
 3. Username / Password via [auth0](https://auth0.com/docs/connections/database).
    A traditional username / password interface where users can sign up. There are currently [limited
@@ -32,18 +32,32 @@ authentication provider! Instead, we support multiple ways for hub admins to
 specify which users are *authorized* to be on the hub.
 
 Authorizing regular users
-: Currently, there are only two supported methods for authorizing regular users:
+: Currently, there are only three supported methods for authorizing regular users:
 
   1. [Manually add users](../howto/manage-users.md) via the admin panel in JupyterHub
   2. (Google only) Allow all users who are logged in via a particular domain - so
      you can allow access to anyone who is part of your organization or
      educational institution.
+  3. (GitHub only) Allow all users who are members of a specific organisation or
+     team. This approach gives you fine-grained control over who has access to the
+     hub inline with your access policies on GitHub
+
+```{tip}
+If your hub has a range of different machine sizes or environments to choose from,
+we can also configure which users can see which options based on their GitHub team
+membership! For example, a team like `@MyCoolOrg/all-users` might be able to see
+Small and Medium sized machines, but the `@MyCoolOrg/advanced-users` team can additionally
+have access to the Large and GPU machines. You can manage these teams within GitHub.
+
+Speak to a Hub Engineer about enabling this feature for your hub.
+```
 
 Authorizing admin users
 : Admin users are authorized [in a hub's YAML config](https://github.com/2i2c-org/infrastructure/blob/c1d06be1eed2d748a4d39e4cba76436cffe89fb2/config/hubs/2i2c.cluster.yaml#L50-L55), with support from 2i2c staff.
 
 % TODO: Link to SRE docs on how to do this once we have it
 
+(admin/management/admin-panel)=
 ## Manage users from the administrator panel
 
 The **Administrator Panel** can be used to maintain the list of users
@@ -94,7 +108,7 @@ if you add them later, their files will still be present.
 ### Finding usernames
 
 Access is granted or revoked based on `usernames`, and these depend on the kind
-of (authentication provider)[admin/configuration/authentication] your hub is
+of [authentication provider](admin/configuration/authentication) your hub is
 using. In general, it matches whatever the visible 'username' in your
 authentication provider is. The table below lists the available providers, and
 how to determine their username.

policy/code-of-conduct.md

@@ -1,3 +1,3 @@
 # Code of Conduct
 
-See [2i2c's code of conduct](tc:code-of-conduct.md) for our Code of Conduct.
+See [2i2c's code of conduct](https://team-compass.2i2c.org/en/latest/code-of-conduct/index.html) for our Code of Conduct.