7 ms·
Read-only deploy keys
- pwenzel 11y agoRead only deploy keys are also a feature of Bitbucket: https://confluence.atlassian.com/display/BITBUCKET/Use+deployment+keys https://confluence.atlassian.com/display/BITBUCKET/Use+deplo...
- emmelaich 11y agoAnd in their enterprise equivalent Stash
- kkirsche 11y agoSadly stash really isn't that great compared to GitHub or GitLab IMHO
- iancarroll 11y agoThat's because any functionality not directly related to SCM is allocated to their other products, which integrate nicely.
- sytse 11y agoGitLab CEO here, thanks! And deploy keys in GitLab have always been read-only http://doc.gitlab.com/ce/ssh/README.html http://doc.gitlab.com/ce/ssh/README.html
- renke1 11y agoI would love to see auth token that provide read-only access to select repositories. I find SSH keys much harder to use in a Docker-based deployment.
- deleted 11y ago[deleted]
- icebraining 11y agoCouldn't you create a new user, give it access to those chosen repositories, and then use the API to access them with read-only permissions?
- detaro 11y agoIf I'm not mistaken you can't grant an application read-only access to a repository? GitHub really isn't very granular in their permissions...
- yeukhon 11y agoNot sure the best route, but the ugly route I know of is place the user in a group wich just have read-only. I am really shocked GH doesn't actually make role-based more granular. I have to add a group to a repository, and can't have the option now to add user to a repository....
- MatthewWilkes 11y agoDeploy keys weren't read-only already? Seriously?
- tjbiddle 11y agoYikes - seriously, I had always thought deploy keys were read-only by definition.
- chrisfosterelli 11y agoAgreed, I actually thought that was the main point of this feature the whole time.
- mdaniel 11y agoI don't know about your use-case, but in my experience by far the greatest use of these keys is (as they say in the linked article) for use by continuous integration servers. Some folks tag each build (if it creates an artifact), and almost everyone tags release builds created by CI. Thus, these keys need to be R/W to push tags back up.
- DannyBee 11y agohttps://developer.github.com/v3/git/tags/ https://developer.github.com/v3/git/tags/ Use API + oauth access?
- bobfunk 11y agoAPI access is a lot more permissive. A deploy key only have access to 1 repo, but there's no way to limit API tokens to a single repo (and by default they have access to all repos in all organizations the issuer of a token have access to).
- DannyBee 11y agoYes, I didn't realize how bad github's security model of this stuff was.
- andmarios 11y agoI always thought that deploy keys are read-only. I can't understand why one would need a special interface to add a read-write key that is the same as any other key you add manually. Iirc only the owner can create deploy keys, so it wasn't a feature aimed to teams either.
- TimWolla 11y agoThey are not tied to a specific, potentially personal, GitHub account.
- datajeroen 11y agoI asked this question 5 years ago on SO: http://stackoverflow.com/questions/2868432/github-readonly-access-to-a-private-repo http://stackoverflow.com/questions/2868432/github-readonly-a.... Glad it got addressed.
- jtchang 11y agoDeploy keys could only exist in one repo at a time. And I think a lot of people thought they were read only.
- codyps 11y agoNow we just need branch restricted keys & keys that aren't allowed to force push (both of these would make me feel a lot better about using certain 3rd party automation in combination with my github repos). Not that I really expect that to happen anytime soon, I believe others have been asking for the above for quite some time.
- codyps 11y agoNow we just need branch restricted keys & keys that aren't allowed to force push (both of these would make me feel a lot better about using certain 3rd party automation in combination with my github repos). Not that I really expect that to happen anytime soon, I believe others have been asking for the above for quite some time.
- mianos 11y agoNow we wait another five years for the ability to share deploy keys across repositories. If you have more than one project in your CI deployable app (for example a couple of internal python libraries), you can't use the same deploy keys. Their suggestion, "don't use modules, package everything in one application or use a full key". Now deploy keys can be R/O (fantastic), this limitation is double annoying.
- nitrogen 11y agoMachine users work pretty well for this. You can grant R/O access to a repo to the machine user.
- baudehlo 11y agoYou can, but the interface for doing so is significantly more annoying.
- philfreo 11y agoRather than using Deploy Keys at all it seems completely better in almost every way to create a fake GitHub user and use its account's regular SSH key. You can, using Teams, give that user read-only access to whichever repo(s) it needs access to for deployment.
- baudehlo 11y agoGithub calls these "machine users". But it's more annoying to manage than the deploy keys UI.
- BillinghamJ 11y agoHowever Github doesn't actually have support for "machine users" - they're just normal user accounts with full GUI access on Github.com. And if you are on Github's per-user pricing model, machine users are not free.
- novaleaf 11y agoThis is exactly what I do on bitbucket (which has had read only repo keys for a while) as repo keys are kind of a pain to use.