https://github.com/guardian/gu-who
answering: who are all these users in my GitHub org?
https://github.com/guardian/gu-who
production
Last synced: 8 months ago
JSON representation
answering: who are all these users in my GitHub org?
- Host: GitHub
- URL: https://github.com/guardian/gu-who
- Owner: guardian
- License: apache-2.0
- Created: 2014-01-31T14:10:51.000Z (over 11 years ago)
- Default Branch: main
- Last Pushed: 2024-12-27T11:30:04.000Z (10 months ago)
- Last Synced: 2025-02-17T10:29:49.333Z (8 months ago)
- Topics: production
- Language: Scala
- Homepage: https://gu-who.herokuapp.com/
- Size: 528 KB
- Stars: 225
- Watchers: 16
- Forks: 56
- Open Issues: 26
-
Metadata Files:
- Readme: README.md
- Contributing: CONTRIBUTING.md
- License: LICENSE
Awesome Lists containing this project
README
### This project is currently archived
_gu:who?_ was introduced in 2014, and was good at enforcing 3 things:
* Enforcing 2FA - this is now [the default across all of GitHub](https://docs.github.com/en/organizations/keeping-your-organization-secure/managing-two-factor-authentication-for-your-organization/requiring-two-factor-authentication-in-your-organization)
* Requiring users to set a non-empty and hopefully recognizable Display Name
* an audit log (in the 'people' repo) that gives an idea of where a user came from
The first of these 3 is now irrelevant, and the last two are prompted by the question "who _is_ this user in our org?",
which can also be given reasonable context by the use of GitHub Teams (a feature that was not widely used when _gu:who?_
was created)- ie if every GitHub user in an org is a member of a not-too-huge-team, then it becomes easy for that team
to bear some responsibilty for knowing who that team member is, and for the name of that team to be a clue in any case.
While we at the Guardian are completing some changes to infrastructure, it's most expedient to turn _gu:who?_ off, at
least for a while, and possibly permanently.
GU: Who?
========
_answering: "Who has access to my GitHub organisation - and why?"_
_gu:who?_ is a simple service for auditing the members of your GitHub
[organisation](https://github.com/blog/674-introducing-organizations).
It was written by The Guardian to get their 200-strong GitHub
organisation under control, resulting in 100% of membership being
accounted for and **98%** Two-Factor-Auth enabled, up from 54% -
you can read more about it in this
[Guardian Developers blogpost](http://www.theguardian.com/info/developer-blog/2014/apr/11/how-the-guardian-uses-github-to-audit-github).
If your organisation is large - and you have 3rd parties, contractors,
etc who you need to give access to your code - it can be very difficult
to work out whether some accounts are _legitimately_ members of
your GitHub organisation or not. Accounts which don't have many details
set in their profile are difficult to identify. When employees leave,
how sure are you that you'll remember to remove their account?
_gu:who?_ aims to make dealing with this all a little bit more easy...
it aims to ensure all users in your organisation meet some basic
requirements, and it makes it easy to see where requirements aren't
being met.
**It does this by using _GitHub_ as its user-interface:**
GitHub issues and simple text files stored in GitHub 'people' repo held
under your org- no other database or spreadsheet, no Active Directory
or LDAP.
Just the tools the developer already uses: GitHub
Enforced Requirements
--------
These requirements are intended to make it easier to manage the user
accounts and work out if they should be in your organisation or not:
* **Two-Factor-Auth** enabled (this requirement can be waived for users in the 'bots' team - for instance, for a long-lived CI bot account that may need to be accessed by multiple humans, who would otherwise have to share an authentication token)
* A **Full Name** set in the user GitHub Profile
* **Sponsor**: each GitHub username should be in github.com/_your-organization-name_/people/blob/main/users.txt (see an [example](https://github.com/gu-who-demo-org/people/blob/master/users.txt) or read more [details](people-repo.md)) - added by Pull Request by any senior member of the organisation (who, in effect, acts as the 'sponsor' for the user for being in the GitHub Org). The current GitHub admin interface doesn't give any long-term audit trail on how a user came to join an Org, so this file serves that purpose.
Actions taken by the gu-who bot...
----------------------------------
* Opens a GitHub issue against each user that doesn't pass the requirements
* Conceals organisation membership for users which don't comply with the requirements
* After a grace period of [1 month](https://github.com/guardian/gu-who/blob/main/app/lib/TerminationSchedule.scala#L28)
removes insecure users from the org - a final warning is given 1 week before removal.
Local Deployment
--------
You can start a local application at http://localhost:9000 with the command:
```
$ export APPLICATION_SECRET=
$ sbt start
```
Remote Deployment
----------
* [Heroku](heroku.md)
What's your logo?
-----------------
Well, obviously, it would be the ridiculously suitable
**[Riddlocat](https://octodex.github.com/images/riddlocat.png)** by [@cameronmcefee](https://github.com/cameronmcefee), but we can't use
it for legal reasons laid out
on the [GitHub Octodex FAQ](https://octodex.github.com/faq/index.html).
You'll just have to imagine the logo there.
What else?
----------
If you're interested in Git and security, you may also be interested in
[The BFG Repo-Cleaner](https://rtyley.github.io/bfg-repo-cleaner/), a
simpler, [faster](http://youtu.be/Ir4IHzPhJuI) alternative to
`git-filter-branch` for cleansing bad data out of your Git repository -
ie **Passwords, Credentials** & other private or unwanted data.
You might also be interested in [Prout](https://www.theguardian.com/info/developer-blog/2015/feb/03/prout-is-your-pull-request-out),
to tell you when your pull requests are reaching Production.