feature: HTTPS based deploy keys

[TomFreudenberg]

Description

Hi, I have found at https://gitlab.com/gitlab-org/gitlab-ce/issues/20845 a really senseful feature request and would like to ask for something similar at gitea.

We have a client service that needs to clone a repository. It cannot use ssh, and thus cannot use a regular ssh-based deploy key.
Is it possible to create a HTTP(S)-based deploy key, so that we can configure the client to access https://[email protected]/repo.git?

The repo can be accessed like this:

git clone https://gitlab-ci-token:<YOUR_TOKEN>@<GITLAB_INSTANCE_URL>/<USERNAME_OR_GROUPNAME/<REPO_NAME>.git

Customer Proposal

Would it not be smart to extend the "deploy keys" concept with HTTPS-based keys, like this:

• Create the deploy key directly in the user interface (no need to run ssh-keygen locally)
• Works like the ssh-based deploy key, but for https
• (?) Share it between projects, for easy managability
• Create multiple keys for multiple clients, and revoke the ones you need

Thanks for your work and feedback

Tom

[silverwind]

Seconding this request. It would be quite handy if there were per-repo access tokens which allow read or read/write access to a single repo via HTTPS, so basically the same functionality like deploy keys, but over HTTPS.

[kgraefe]

I think it would be nice to have both per-account and per-organization access tokens.

[DjSni]

I think it would be nice to have both per-account and per-organization access tokens.

i agree with you, but you should be able to set for each token which rights the token has.
For example, only read rights, read and write rights...
But I hope this will be implemented soon.

[Snck3rs]

would be a great feature! i hope someone will be found to implement that.
Great work, btw!

[multicast]

https based deploy key per organization would also be interesting, as well as ssh deploy key per organization would simplify many setups.
currently I had to create "technical" user to achieve this and make it a member of the team/organization. The organization admin should be able to generate such tokens or mark keys as deploy keys for organization or multiple repositories.

[skorokithakis]

Yes please, HTTPS cloning with tokens would be great for times where adding an SSH key is inconvenient.

[vbichov]

this issue is open for almost 5 years - what are the chances this will actually be implemented?

[lunny]

I think it's not very difficult, if the token is a user's personal access token. We need to change here https://github.com/go-gitea/gitea/blob/main/routers/web/repo/http.go#L113 and create a new implementation of

gitea/services/auth/interface.go

Line 23 in 34b5436

type Method interface {

only for SmartHTTP routers.

[silverwind]

It should generate a unique token per-repo, not re-use a user's personal token. But I guess the implementation can probably share some of code with the personal token mechanism, like the generation part.

[lunny]

It should generate a unique token per-repo, not re-use a user's personal token. But I guess the implementation can probably share some of code with the personal token mechanism, like the generation part.

Share it between projects

One key could be used for multiple repositories, one repositories could also have multiple keys.

[skorokithakis]

@lunny I disagree, sharing one key for multiple repositories is the job of the personal token. A deployment key is bound to a single repo, and you may have multiple keys for one repo.

[silverwind]

One key could be used for multiple repositories, one repositories could also have multiple keys.

That would be different to how deploy keys currently work (which are 1 per repo IIRC), but I guess one layer of indirection via a dropdown of selectable deploy keys (ssh and http) would be nice to have, but not required initially imho.

Also, it would present an issue regarding ownership of shared deploy keys. Would it be users/orgs who own it? would they be global? I think we can sidestep such questions by first binding them only to the repo.

[TomFreudenberg]

I agree to @skorokithakis

If you will use such deploy keys - I guess you will use https - so you will deploy your repo on several instances - each instance could have its own key per repo

[multicast]

Share it between projects

One key could be used for multiple repositories, one repositories could also have multiple keys.

I fully agree. One https token (or ssh key) should be usable in more repositories, and one repository should be able to have more tokens (ssh keys). Some of them read-only, some read-write. Also a per-organization tokens (keys) should exist. Now I have to solve it via some bot account, even this is not enough often.

Currently I can have an ssh deploy key in a repository (and enable write access if necessary), so my production servers can use the ssh key when pulling from host e.g. git.corp. Since the deploy key cannot be reused in other repo, I am forced to use the ssh config file:

Host foo.git.corp
  IdentityFile ~/.ssh/foo
Host bar.git.corp
  IdentityFile ~/.ssh/bar
Host *.git.corp
  Hostname git.corp
  User git

If the project is composed from dozens of repos, I need dozens keys, one for every new repo. Reusing one deploy key for several repos would be a valuable feature, and the same applies for the https token.
If all repos for particular project are grouped in an organization, this would make use case for the per-organization deploy key (or https token).
Replicating the production setup to run independently an integration, q&a, or a test environment makes perfect sense not to share ssh key with production. That's why more deploy keys are already possible per repo (and so more https tokens must be possible too).

I do not use above setup any more - instead of managing multiple keys, on multiple servers, in multiple environments, I have a bot and that bot is an organization member or collaborator. It's enough to use bot's private key instead of mine or managing dozens of keys. Replacing this with single https token would make things incredibly simpler.

Do not limit an https token (or a deploy key) to single repo. It should work, potentially with different privilege level, for multiple other repos. If somebody "overloads" the key or token with access to a too-many repos, the key or token has more "power", but it means you can also revoke/invalidate a key or token from all repos efficiently.

[techknowlogick]

Tbh I use bot accounts for this so I can assign exactly which repos/orgs they have access to.

[multicast]

Me too, but sometimes you I have a "3rd party" for single or few closely related repos, for which the https token is the only way (i.e. no ssh access, so no deploy keys). having a thousands 3rd parties means thousands of bot accounts versus simple https token. The 3rd party can be a single server or a cluster, not actualy a human, obviously.

[multicast]

I just found a bot account issue #13044, which helps using bot accounts, but is still not a replacement for https tokens.

[silverwind]

Yes, I also use "bot" style accounts to share one "deploy token" for multiple repos. But sharing such tokens with access to multiple repos is not a good practice security-wise because if one system gets compromised, more data is at risk than it needs to be.

So I would even prefer if a HTTPS deploy token is only valid for a single repo, just like SSH deploy keys currently are.

[MrSuicideParrot]

Bot accounts are a hacky way to minimise this problem and not the solution.
This issue has been open for 4 years and in my point of view, this is the only major feature that is missing when compared with gitlab and GitHub.
Thus, I don't understand why this feature isn't a priority...

[lunny]

Vote:

• 🚀 One key one repo
• 👍 One key could be used for multiple repositories, one repository could also have multiple keys.
• 🎉 Just keep to use bot account
• ❤️ One repository can have multiple keys but they can't be reused on another repo.

Or if you have any other options, please let me know.

[mgax]

Or if you have any other options, please let me know.

GitHub allows you to set multiple deployment keys per repo, but you're not allowed to reuse a key on multiple repos (which is a royal pain). Also, GitHub only allows SSH deployment keys, it would be great to have HTTPS deployment keys too. So, for completeness sake, there can be another option, one repository can have multiple keys but they can't be reused on another repo. Not that I'm advocating for it :)

[lunny]

Or if you have any other options, please let me know.

GitHub allows you to set multiple deployment keys per repo, but you're not allowed to reuse a key on multiple repos (which is a royal pain). Also, GitHub only allows SSH deployment keys, it would be great to have HTTPS deployment keys too. So, for completeness sake, there can be another option, one repository can have multiple keys but they can't be reused on another repo. Not that I'm advocating for it :)

Added as a new vote option.

[DjSni]

Would like to set a 🥇 but i can´t. I can only set 👍, 👎,😄,🎉,😕,❤️,🚀,👀
Thanks

[lunny]

Would like to set a 🥇 but i can´t. I can only set 👍, 👎,😄,🎉,😕,❤️,🚀,👀 Thanks

Changed to ❤️

[jerrykan]

Would like to set a 1st_place_medal but i can´t. I can only set +1, -1,smile,tada,confused,heart,rocket,eyes Thanks

Changed to heart

what about 💯 ? It isn't a valid option either.

[silverwind]

Can't vote 💯, but it's definitely my favorite. Keep it simple and secure, at least initially. More flexibility can be added later and such stuff could then also apply for SSH-based deploy keys.

[lunny]

@jerrykan @silverwind Don't know why I can. Changed to 🚀

[multicast]

@silverwind - I fully agree with security-wise practice of not sharing keys. but one key/token per repo forces me to share key on multiple clients. so, security-wise, repo must have possibility of more keys.

on the other side, sharing single key/token for multiple repos puts them all at the same risk when a key/token is compromised. but possibility to reuse the key/token in multiple repos does not require you to do so. you can still follow policy of not reusing the key. but where appropriate, greatly simplifies setups.

@techknowlogick - I also agree that a bot account is workaround, not a solution.

[MarZab]

Could the deploy sha key be used to validate a token generated and signed using the private key ?

To expand on this idea, imagine we have something like a JWT:

{
   validUntil: "2021-10-01-10-10-10",  // iso like date
   repository: "a-repo", // limit to a repo
   privileges: "read,write" // limit to certain actions
}

We sign and base64 encode the token and produce a link:

git clone https://jwt:<JWT_LIKE_TOKEN>@<GITLAB_INSTANCE_URL>/<USERNAME_OR_GROUPNAME/<REPO_NAME>.git

The server would validate it using the deploy sha key and apply the permission set.

This way there is no additional management for the keys, they keep the same access levels and are added/removed with the deploy sha key - but we get this extra level of configurability we can use to produce really specific access tokens.

[benedictjohannes]

Is there any fork already working on this? I'd be interested to implement it with "One key could be used for multiple repositories, one repository could also have multiple keys."

[manuelchichi]

Any update on this feature?

[netthier]

This would also be useful for fine-grained control over the Gitea container registry, as it does not support SSH authentication, only HTTP(S).

[cwchristerw]

This is maybe related to #24767

[Jamesits]

Fine-grained API tokens would be great. Rather than having deploy keys shared between projects, would it be better to just have bot accounts that are PAT&SSH keys only, no UI login, no SSO? This allows sharing keys between projects. We also want different username and profile pictures for these bot accounts, so that CI released packages does not say they are uploaded by some human.

(BTW, do allow a bot account to have multiple PAT and SSH keys so credential rotating can be implemented in an easier way. )

[HammyHavoc]

Is anyone currently working on this? Just hit this problem and might be interested in taking it on. Any rough stuff or notes anyone has about it would be appreciated.

[multicast]

I am not, even I miss this feature. Is it worth to summarize the target? Or settle on the winner - #2051 (comment)

[lesinigo]

IMHO sharing the same project deploy key between multiple use cases should be avoided at all costs for security reasons (as @multicast also said). This brings us to the requirement of supporting more than one key per project.

Personally I'm against sharing the same "key" between multiple projects, I'd prefer the "bot account" approach, that would also probably be easier to implement since the logic and UI to manage which projects can be accessed by which users is already there.

Still, simple "deploy tokens" for projects, with read only access and with the ability to create more than one for each project, would probably solve 90% of use cases out there and can co-exist with a future "bot account" implementation. Gitlab does the same too, for example.

[multicast]

Bot accounts are already possible and are certainly workaround

• they must be specialy secured (password, key, api tokens...)
• they steal the first level of namespace used by users or organizations
• they clutter the list of instance users, members of the repository, organization or team
• to change their public key or token, you must login to them
• to create account a developer needs enough privileges (or bother admin)
• overtime, nobody remembers who created or "owns" the bot12345 and if it can be deleted
• managing bot's properties via command line or API needs bot's own credentials
• accounts can be in an external corporate system (SAML, LDAP...) the gitea admin has no easy control of.

Tokens or keys:

• your (developer) account is probably already secured
• no additional namespace pollution or any user lists with new entry
• changing your keys can be done yourself
• removing repository or the organization also removes key/token association
• should be naturally managed using API or tea command line (with your credentials)

Using the same "key" for multiple projects is not sharing. It's empowering the key for having access to more, often tightly related repositories (e.g. subtree or submodules). Allowing to reuse key or token does not block your preferred approach - feel free to use any key or token only once, have different per each repo.

Preventing reuse of a repo-based deploy public ssh key from accessing more than one repo, or blocking a token access to multiple repositories, implies creation of many keys or tokens and their management on clients accessing Gitea. Allowing single powerful token to access multiple repositories also allows (e.g. after a compromise) to revoke, delete or update single key and effectively block access of the old token wherever it ever had access to.

The winner says it all: One key could be used for multiple repositories, one repository could also have multiple keys