1. Bitbucket
  2. Public Issue Tracker
  3. master
  4. Issues

Issues

Issue #4285 open

Set deployment key as account-wide default (BB-4775)

Brendon Rapp
created an issue

Deployment keys are a great feature, but there ought to be a way to set a deployment key as an account-wide default, particularly for team accounts, rather than only being able to set them one repository at a time.

As it is now - having to add the key to every repository - they aren't a great substitute to using a read-only deployment user. Using deployment keys necessitates entering them in for each repo, one at a time, and then remembering to do it again when new repos are created.

The fact that you can set up a read-only deployment user makes this issue less than critical, but it would be nice to not eat up that user slot.

Comments (35)

  1. Gianluca Sforna

    In the meanwhile, I think I will implement some python code to set this (and other) default properties using the REST API. At least I will not need to manually check each and every of our repos

  2. stijn

    Another vote for this one. We now either have to create an account for a build server, which is weird, or have to add a key for all team's repositories. And in both cases multiple build servers means you either give them the same key which is normally frowned upon in ssh crowds (afaik) or you have to repeat the process.

  3. Asare Worae

    Upvoting this one too, right now we have 3 staging environments and 6 different repositories, it's a lot of overhead to keep on managing this manually every time when something changes.

  4. John Simpson

    I opened support ticket BBS-14524 with Atlassian about this. Their response was...

    Judging by the activity on the internal ticket, I don't think it is on the road map
    anytime soon. While I do agree this is a useful feature, there really isn't
    anything I can do from a support standpoint that would further the prioritization
    of this. Any comments / criticism should be made on the site/master ticket you
    mentioned, as it will be visible to the product management team.
    

    I can't say I like it, but at least it's honest, and now we know not to hold our breath because it's not even on the roadmap.

    In my case, it turns out we were already using one of our account's users as a "mirroring" account, to keep our local mirror of all of our repos up to date. This user has an SSH key which has read-only access to all repos, so I'm going to add our build server's SSH key to this "mirror" user, rather than adding it at the account level.

    It sucks that we have to use one of our user slots for this, but the other option is moving to another provider - which I'm not against doing, I just don't want to have to deal with the mechanics of moving everything.

  5. Hilton D

    I'm not sure what the yardstick for implementing a feature is? One thousand people begging for a feature that is reasonable and would save it's users time and complexity seems like a missed opportunity for a SaaS product.

    +1 for this.

  6. Daan van den Berg

    +1 This is really a feature that is needed! Especially if you have a project that pulls in several dependencies from different repositories. It's a big hassle setting deployment keys on all seperate repositories.

  7. Thomas Redstone

    As this can be implemented using an extra team member, with read only access, couldn't it be added as a feature by allowing an extra free team member with only read access? It could be further locked down so that it doesn't have the ability to login to the website, or use a password. I'm sure this idea has been thought by many already, but it would be interesting to know why it can't happen fairly easily!

  8. Sean Jeffrey Vaughan

    We have team SSH keys set up and are using them as team-wide deployment keys. Is this thread specifically about readonly keys? (One repository I tested it on I couldn't push my commits implying the key is for readonly access, but the SSH keys page indicates otherwise, that they can be used for pushing commits). It's in "Manage Team" -> "SSH keys". These SSH keys behave at least slightly differently than deployment keys: running the command "ssh -T git@bitbucket.org" does not return a list of repositories like the deployment keys do.

    (Screenshot)oris   ssh keys — Bitbucket.png

  9. Sean Jeffrey Vaughan

    Ok, so this thread is indeed about having a readonly alternative. We'd prefer that as well but we will work around it with this team-wide read/write ssh key and limit availability of the private key as best we can.

  10. Simon Jackson

    I found another account setup using same email, has it's own key set, and then I added a group Deployment Entity, and just add it to the project. The problem I'm having at the moment is locking down specific keys as write keys for specific repos.

  11. Steve Todorov

    I also believe this feature is a must. Imagine having many private repositories and a Jenkins server which needs READ-ONLY access to those repositories. Even though you could add an SSH key this opens up security concerns. And it's really not an option to go through hundreds of private repos and add the same deploy key in each one.

  12. Asare Worae

    We are currently migrating our 20 head dev team to gitlab.com and i would recommend anybody/everybody to do the same. They have a much bigger feature base, respond to (logical) requests, and the migration process is very easy.

    I have asked for this feature unlimited amount of times already through email's, and i can't believe that this is something that is so difficult to implement that after 4 years (!!) nothing has been done to come up with a solution for the (paying) community. We are dreading the process of adding the deployment keys every time we create new repo's and are drawing straws to see who is the lucky one to do this brainless task.

    The final straw was the moment when we had to move to our 3rd datacenter and had to setup our CI pipeline with 2 stages, this means ~160 copy pasting operations of 2 deployment keys in a total of ~80 repos into a web application which actually dropped out mid deployment.

    Screenshot-42.png

    The lack of care and/or activity in this thread from the Bitbucket staff over the last 4 years shows me the (future) quality of Atlassian.

    Can't say i'm going to miss this place. best of luck to you all <3

  13. Log in to comment