Read-only deploy keys | Hacker News Reader

Read-only deploy keys

github.com

144 pointsbado51 comments

Read only deploy keys are also a feature of Bitbucket: https://confluence.atlassian.com/display/BITBUCKET/Use+deplo...

And in their enterprise equivalent Stash

Sadly stash really isn't that great compared to GitHub or GitLab IMHO

That's because any functionality not directly related to SCM is allocated to their other products, which integrate nicely.

GitLab CEO here, thanks! And deploy keys in GitLab have always been read-only http://doc.gitlab.com/ce/ssh/README.html

Now 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.

Machine users work pretty well for this. You can grant R/O access to a repo to the machine user.

You can, but the interface for doing so is significantly more annoying.

Rather 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.

Github calls these "machine users". But it's more annoying to manage than the deploy keys UI.

However 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.

This 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.

workaround - add this to ~/.ssh/config

    Host *.github.com
    IdentitiesOnly yes
    IdentityFile ~/.ssh/%h_id_rsa
    HostKeyAlias github.com
    ProxyCommand nc github.com %p

use whatever.github.com as the hostname when cloning, and put the key in ~/.ssh/whatever.github.com_id_rsa

GitLab CEO here, sharing deploy keys has been a feature for a long time in GitLab http://doc.gitlab.com/ce/ssh/README.html No need to wait five years :)

Deploy keys weren't read-only already? Seriously?

Agreed, I actually thought that was the main point of this feature the whole time.

I 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.

https://developer.github.com/v3/git/tags/

Use API + oauth access?

API 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).

Yes, I didn't realize how bad github's security model of this stuff was.

Yeah, it's terrible.

You can't give read only Oauth access to private repos....it has to be read/write. Which means if you want to use online CI tools with those private repos....you've got to hope they don't either turn malicious, or they get hacked and have their keys copied.

Can you limit the user permissions to only affect tags? Otherwise, I'm not seeing the advantage.

From what I can tell, there's no write:tags scope: https://developer.github.com/v3/oauth/#scopes

Ugh. You are right, it looks like they screwed this up.

Pushing a new tag is a vastly smaller privilege than pushing arbitrary objects.

Actually, pushing objects is a smaller privilege.

Fine, let's be picky. Pushing a new tag onto an existing commit is a vastly smaller privilege than being able to push objects and point branches at them.

You can have a read-write user on your CI server, but use a read-only user for any remote server where code is deployed. It's bad security policy that GitHub ever allowed deploy keys to be RW.

I don't understand, won't you tag a release commit first manually and than have it be created by the CI server?

Some people using manual tagging as a mechanism to communicate something to CI as you suggest, but others let CI tag successful builds. When I re-did my team's CI a few years ago I chose the latter because it creates less friction for continuous deployment -- every commit which passes the tests automatically becomes a deployable artifact with a monotonically increasing build number which can be tracked across SCM, CI, and deployment.

Why not use the sha as the build identifier across SCM, CI and deployment? It exists already.

Heh, you've never worked with a project/product manager, have you? "Yes, ma'am, version 1b6411f has been deployed successfully. Now I just need to edit the pom and bump the version to 2e1080d"

Good point, but if you bump the version yourself why not set a tag?

I never understood why nobody cared. We had banned use of deploy keys on our repos precisely because they weren't read-only.

Yep, and there was a big fat warning in the documentation saying that they had full access to the repo. Couple this with being able to be used on only a single repo - github blocks other repos from using the same key - and you may as well just make a normal github account for your deploy system and manage it that way...

It's weird that they didn't have an option to write only for tags. "CI build X"...

Yeah, one or more deployment accounts is the approach I've seen most "in the wild". Machine users[1] with tightly scoped access to a collection of repos. Access can then be managed through the relevant Read-only GitHub team.

[1] https://developer.github.com/guides/managing-deploy-keys/#ma...

They're not really "deploy-only" keys, but rather "automation keys".

Personally, I've used them a lot to mirror from my own gitlab server onto github, so having them be read+write was a good thing in my case.

I know a lot more people use them to mirror stuff onto gh as well.

My thought exactly. I thought deploy keys were deploy keys because they were read-only. I don't think this is a feature announcement as much as a CVE.

Yikes - seriously, I had always thought deploy keys were read-only by definition.

It's ridiculous it has taken GitHub so long to provide this basic functionality. Judging by comments on this thread, it looks like a lot of people assumed the keys were already read-only. And i'm not surprised because GitHub has never made it explicitly clear in documentation and their website that the keys had full write access!

I stopped using deploy keys long ago because of the security issue and instead opted to create additional github users with read-only access for each use case.

Why did GitHub call these "deploy" keys if they had write access? Why would a deploy user need full write privileges to a repository to deploy something?

I asked Zach Holman at one of his tech talks a couple years ago and he replied (paraphrasing): "Yes read/write deploy keys are not ideal. That's why we don't ourselves use deploy keys at GitHub, and in fact we regret that the feature exists." I think he used an expression like "deploy keys are a red-headed stepchild".

I like to pride myself on never having used a clumsy phrase like that. That said, machine users were en vogue at GitHub, although maybe that's changing with more consideration being given to deploy keys nowadays.

Sorry, I believe you used a more palatable expression than that, but having a similar meaning.

Edit: and to paint a more complete picture, you pointed out in your answer that many folks were using deploy keys to promote from a development branch to the master branch. Some commenters in this thread may, like myself, just not have thought to use deploy keys for this purpose, or that others would want to.

Now 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.

I asked this question 5 years ago on SO: http://stackoverflow.com/questions/2868432/github-readonly-a.... Glad it got addressed.

I 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.

They are not tied to a specific, potentially personal, GitHub account.

Deploy keys could only exist in one repo at a time. And I think a lot of people thought they were read only.

I 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.

Couldn'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?

If 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...

Not 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....

Reply on news.ycombinator.com