
Read-only deploy keys - bado
https://github.com/blog/2024-read-only-deploy-keys
======
pwenzel
Read only deploy keys are also a feature of Bitbucket:
[https://confluence.atlassian.com/display/BITBUCKET/Use+deplo...](https://confluence.atlassian.com/display/BITBUCKET/Use+deployment+keys)

~~~
emmelaich
And in their enterprise equivalent _Stash_

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

~~~
sytse
GitLab 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)

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

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

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

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

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

~~~
DannyBee
[https://developer.github.com/v3/git/tags/](https://developer.github.com/v3/git/tags/)

Use API + oauth access?

~~~
bobfunk
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).

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

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

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

------
datajeroen
I asked this question 5 years ago on SO:
[http://stackoverflow.com/questions/2868432/github-
readonly-a...](http://stackoverflow.com/questions/2868432/github-readonly-
access-to-a-private-repo). Glad it got addressed.

------
andmarios
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
They are not tied to a specific, potentially personal, GitHub account.

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

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

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

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

