-
Suggestion
-
Resolution: Fixed
-
6
-
Hi everyone,
Thank you for voting on this suggestion. In Bitbucket Data Center 7.18 we've added HTTP Access Tokens for projects and repositories. More details can be found in the release notes and official documentation.
Anton Genkin
Product Manager
Original suggestion
As of now, build systems like TeamCity need to retrieve the sources via SSH and a private key infrastructure in order to be secure & do not use up an additional "service user" license for each project.
This has two major drawbacks:
- It forces us to manage the private key infrastructure (administrative overhead)
- It is not recommended to use SSH via automatic build tools according to the docs: https://confluence.atlassian.com/display/STASH/Enabling+SSH+access+to+Git+repositories+in+Stash
Furthermore, it forces us to enable SSH on Stash in the first place, this is not a huge drawback (due to the minimal configuration), however, still a security issue.
Optimally we would have:
- a default service user for each project
- enabling the "service users" feature costs only a single user license in total (regardless of how many projects provide service users)
- the service user can simply connect via HTTPS like all other Stash users
(see also https://answers.atlassian.com/questions/313156/stash-licensing-for-ci-build-systems for a discussion on the topic)
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[BSERV-4989] Access keys for HTTP/HTTPS
Furthermore, it forces us to enable SSH on Stash in the first place, this is not a huge drawback (due to the minimal configuration), however, still a security issue.
Just to provide a bit of background information about the SSH access to Stash: Stash runs a locked down embedded SSH server that only allows remote users to perform a number of operations: git upload-pack, git receive-pack, git upload-archive and whoami. The embedded SSH server does not allow a remote user to create a shell or access the file system directly. As such the security issue is very limited.
There is a related ticket STASH-2722 to allow token based HTTP access at a user level. I'm opening this request as the ability to do something similar at the project/repo level like the current SSH access keys implementation.
Bradley Baetz
added a comment - Would also be useful for the REST api - eg creating a backup user to do nightly backups also counts as a user...
Bradley Baetz
added a comment - Would also be useful for the REST api - eg creating a backup user to do nightly backups also counts as a user...
Thank you for elaborating on the SSH issue, still leaves us with the other two major drawbacks though.