Read-only deploy keys

https://github.com/blog/2024-read-only-deploy-keys

by bado • 11 years ago

144 51 11 years ago

renke1• 11 years ago

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.

icebraining2• 11 years ago

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?

detaro• 11 years ago

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

pwenzel• 11 years ago

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

emmelaich• 11 years ago

And in their enterprise equivalent Stash

kkirsche• 11 years ago

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

MatthewWilkes• 11 years ago

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

chrisfosterelli• 11 years ago

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

mdaniel2• 11 years ago

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.

DannyBee4• 11 years ago

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

Use API + oauth access?

ctz• 11 years ago

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

eeeeeeeeeeeee2• 11 years ago

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.

sytse5• 11 years ago

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

DannyBee4• 11 years ago

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

vacri• 11 years ago

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

kurttheviking• 11 years ago

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

hobarrera• 11 years ago

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.

nilved• 11 years ago

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.

tjbiddle• 11 years ago

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

eeeeeeeeeeeee2• 11 years ago

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?

gkop2• 11 years ago

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

andmarios• 11 years ago

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.

TimWolla• 11 years ago

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

datajeroen• 11 years ago

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

jtchang• 11 years ago

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

codyps• 11 years ago

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.

mianos• 11 years ago

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.

nitrogen• 11 years ago

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

baudehlo2• 11 years ago

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

philfreo• 11 years ago

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.

baudehlo2• 11 years ago

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

BillinghamJ• 11 years ago

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.

novaleaf• 11 years ago

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.

ryan-c• 11 years ago

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

sytse5• 11 years ago

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 :)

Read-only deploy keys

Related Stories