Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: GitHub Org Audit Tool

github.com

Post reply on HN
Print view View original

11–20 of 24 posts

Re: Show HN: GitHub Org Audit Tool

#11

Post by benfrancom »

nathanwallace wrote: post #9
atonse wrote: post #4

How about using steampipe for this?

Thanks atonse for the shout out! Steampipe [1] is an open source CLI to query your cloud resources (e.g. GitHub, AWS, Splunk, etc) with SQL. The GitHub plugin has 44 tables to query [2]. The "GitHub Sherlock" mod includes 34 automated controls for organization, repo and issue best practices. The "GitHub Compliance" mod has 35 automated controls for supply chain security. Mods are written in HCL + SQL. [3] 1 - https:/…

Thanks for sharing! Love these other options!

Re: Show HN: GitHub Org Audit Tool

#12

Post by pquerna »

megamorf wrote: post #3

Unfortunately, it leaves a lot to be desired. I've actually had to do a fair bit of GH access reporting myself recently and I can recommend the GraphQL API as it allows you to properly list direct and indirect permissions on repositories (org + team + direct collaborator) that are alot harder to do with the REST API due to its inconsistent permissions model.

i've also been working on a similar tool -- working towards open sourcing it too. would you be interested in taking a look? paul.quenra at conductorone com

Re: Show HN: GitHub Org Audit Tool

#13

Post by FBISurveillance »

nathanwallace wrote: post #9
atonse wrote: post #4

How about using steampipe for this?

Thanks atonse for the shout out! Steampipe [1] is an open source CLI to query your cloud resources (e.g. GitHub, AWS, Splunk, etc) with SQL. The GitHub plugin has 44 tables to query [2]. The "GitHub Sherlock" mod includes 34 automated controls for organization, repo and issue best practices. The "GitHub Compliance" mod has 35 automated controls for supply chain security. Mods are written in HCL + SQL. [3] 1 - https:/…

Quick feedback: Just noticed that you can get rid of one setup step at https://steampipe.io/downloads - you don't need to brew tap & brew install, you can just use one command: `brew install turbot/tap/steampipe` without doing `brew tap` first.

Re: Show HN: GitHub Org Audit Tool

#14

Post by LukeShu »

megamorf wrote: post #3

Unfortunately, it leaves a lot to be desired. I've actually had to do a fair bit of GH access reporting myself recently and I can recommend the GraphQL API as it allows you to properly list direct and indirect permissions on repositories (org + team + direct collaborator) that are alot harder to do with the REST API due to its inconsistent permissions model.

IME, the problem with the GraphQL API is that it does a poor job of indicating where permissions came from, and you have to fall back to bad heuristics.

For example, if team="company" has "READ", and team="company/dev" has "WRITE", and Bob is in team="company/dev" but not team="company", then Bob will have both "READ" and "WRITE" because of his membership in team="company/dev"; the API will give no indication that the "READ" indirectly came from team="company".

Also, the permissions that the PAT needs in order for GraphQL to even list those things is excessive.

Anyway, here's my audit script for such things: https://github.com/datawire/collaborators

Re: Show HN: GitHub Org Audit Tool

#15

Post by kataklasm »

pquerna wrote: post #12
megamorf wrote: post #3

Unfortunately, it leaves a lot to be desired. I've actually had to do a fair bit of GH access reporting myself recently and I can recommend the GraphQL API as it allows you to properly list direct and indirect permissions on repositories (org + team + direct collaborator) that are alot harder to do with the REST API due to its inconsistent permissions model.

i've also been working on a similar tool -- working towards open sourcing it too. would you be interested in taking a look? paul.quenra at conductorone com

I believe you might have a typo in your mail? Just making sure you're not missing out on something useful :)

Re: Show HN: GitHub Org Audit Tool

#16

Post by playingalong »

coenhyde wrote: post #5
candiddevmike wrote: post #2

Why audit when you can declare all of this in Terraform? https://registry.terraform.io/providers/integrations/github/...

As much a fan of Terraform I am. If you didn't started defining your repos in Terraform from day 0, importing hundreds of repos, members, permission sets would be quite a lot more work than running this audit tool.

And here comes Terraformer: https://github.com/GoogleCloudPlatform/terraformer It doesn't import anything, but generates the .tf files for you.

Disclaimer: I have used that, but not for GitHub.

Re: Show HN: GitHub Org Audit Tool

#17

Post by maartenh »

Awesome! I built something like this for $JOB-1 too. Unfortunately didn't get to open source this before I left.

I built in an a mechanism for policy checks too, e.g. to check that only an allowed list of repositories was public, and that permissions were only assigned through teams.

Re: Show HN: GitHub Org Audit Tool

#18

Post by megamorf »

LukeShu wrote: post #14
megamorf wrote: post #3

Unfortunately, it leaves a lot to be desired. I've actually had to do a fair bit of GH access reporting myself recently and I can recommend the GraphQL API as it allows you to properly list direct and indirect permissions on repositories (org + team + direct collaborator) that are alot harder to do with the REST API due to its inconsistent permissions model.

IME, the problem with the GraphQL API is that it does a poor job of indicating where permissions came from, and you have to fall back to bad heuristics. For example, if team="company" has "READ", and team="company/dev" has "WRITE", and Bob is in team="company/dev" but not team="company", then Bob will have both "READ" and "WRITE" because of his membership in team="company/dev"; the API will give no indication that th…

That's actually incorrect. Check out this query: https://gist.github.com/megamorf/9c105ac9cc13a93b5449a7b683d...

I have added two output examples. One for when you only want to find users that have been directly assigned to a repo (DIRECT) and one that shows how their roles and team memberships decide what permissions they have on a repo.

Re: Show HN: GitHub Org Audit Tool

#19

Post by sigio »

LukeShu wrote: post #14
megamorf wrote: post #3

Unfortunately, it leaves a lot to be desired. I've actually had to do a fair bit of GH access reporting myself recently and I can recommend the GraphQL API as it allows you to properly list direct and indirect permissions on repositories (org + team + direct collaborator) that are alot harder to do with the REST API due to its inconsistent permissions model.

IME, the problem with the GraphQL API is that it does a poor job of indicating where permissions came from, and you have to fall back to bad heuristics. For example, if team="company" has "READ", and team="company/dev" has "WRITE", and Bob is in team="company/dev" but not team="company", then Bob will have both "READ" and "WRITE" because of his membership in team="company/dev"; the API will give no indication that th…

Having write already implies that you have read, it't not something related to being in a team with read, it's just that write always gives you read. The permission levels are pull(read), triage(read+issues/pr's), push(read+write), maintain, and admin

Re: Show HN: GitHub Org Audit Tool

#20

Post by LukeShu »

sigio wrote: post #19
LukeShu wrote: post #14

Earlier quoted context omitted.

IME, the problem with the GraphQL API is that it does a poor job of indicating where permissions came from, and you have to fall back to bad heuristics. For example, if team="company" has "READ", and team="company/dev" has "WRITE", and Bob is in team="company/dev" but not team="company", then Bob will have both "READ" and "WRITE" because of his membership in team="company/dev"; the API will give no indication that th…

Having write already implies that you have read, it't not something related to being in a team with read, it's just that write always gives you read. The permission levels are pull(read), triage(read+issues/pr's), push(read+write), maintain, and admin

> Having write already implies that you have read

Yes, but if it's just being implied then it won't list "READ" separately in the "permissionSources", it will just list "WRITE".

Post reply on HN