CircleCI Ideas

Granular scopes for GitHub

We would like to see CircleCI use the newer GitHub API to lessen the privileges needed for integration.

I see that when linking GitHub with CircleCI you still require write access to pretty much everything in my GitHub account.

I know, that in the past this was do to a limitation of GitHub OAuth scopes, but now that they have GitHub Apps which allows more granular permission, I would appreciate if I could specify a lower privileged access so that CircleCI cannot arbitrarily modify code in GitHub.

New API should allow much more granular access so that by default you don’t get write access. I see this as a real differentiator when picking the most secure CI SAAS.

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Nov 20 2017
  • Taking votes
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    March 29, 2019 16:21
    Yes, please! We would like to use CircleCI but I'm not giving you write-permission to everything I have on GitHub. I don't think CircleCI is malicious, but mistakes happen and I don't see any reason for you to have write-permission in the first place.
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    April 19, 2019 09:52

    For what it's worth Travis CI has this already

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    April 30, 2019 17:10

    Thank you for all of your feedback. We definitely understand the value that this would give to our customers by adding this. However, supporting granular scopes is a big change for our system and requires significant engineering effort that we are not prioritising right now

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    May 28, 2019 16:49

    This issue has come up for us as well. You can find the detailed conversation here: https://discuss.circleci.com/t/github-org-permissions-only-access-public-repos/30525/9

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    July 31, 2019 06:14

    I would like to use CircleCI, but I will never ever ever use the service if my only option is to always give you access to ALL repos attached to my GitHub account or all repos belonging to an organization. This is a massive security and privacy risk. I will go create a TravisCI account specifically because they support this feature.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    August 19, 2019 08:28

    This needs a higher priority. For customers with privacy and security in mind, it's extremely necessary that the permissions are granular. 


    I understand there's no "prioritising right now" because of other features, but you are actually losing  and hurting customers by not adding it. 

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    December 04, 2019 22:10

    Need to see better division of repo visibility. Though it retains the Github permissions model bt this thread seems to suggest that anyone can see any repo. Is this true?

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    December 05, 2019 08:32

    It's definitely not the case that "anyone can see any repo" -  we mirror the permissions that exist in GitHub relative to repo access. So someone with write access in GitHub gets access to the project in CircleCI - it means they can do triggering, write project settings and view the pipelines via the API/UI if you have write access in GitHub. If you have read access in GitHub you can only read from the project. Does that clarify?

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    December 05, 2019 09:42

    I think it's still worth doing. Within one organisation, mirroring GitHub access control is probably fine, but this falls down when you consider multiple organisations.

     

    If I'm a member of OrgA and OrgB, then OrgA's CircleCI install shouldn't have permissions on OrgB's GitHub repos, which it currently does. This means that any sort of permissions issue in CircleCI is far worse as it exposes cross-organisation control. The same is true for personal repos vs organisation repos. My organisation should not have access to my personal repos.

     

    Whether these are accessible in UI on CircleCI or not is irrelevant, CircleCI has an access token that is capable of controlling those resources. This puts CircleCI in a very critical security position for far more than it should. It's reasonable that this might violate OrgB's security controls, but they don't have the option to make that decision because of OrgA having decided to use CircleCI.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    December 05, 2019 14:18

    Nathan - I can't find the enforcement of Github permissions documented anywhere and though I have ticket out with Support, have not got a good answer on this yet.

    On the related topic of cross-org access, it would also be interesting to understand the permissions model. If I understand the thread and the docs, access from CircleCI is often done in the context of a user (it's their token). SO whatever that person has access is exposed in Circle CI. Is this changed in a eaningful way if you switch to using "machine accounts" for each org?

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    28 Feb 12:46

    Just chiming in, CircleCI requiring even momentary full access is a blocker for my org.