GitLab issueshttps://gitlab.com/gitlab-org/gitlab/-/issues2024-03-02T03:04:27Zhttps://gitlab.com/gitlab-org/gitlab/-/issues/271545Gitlab Registry Login Timeout using Deploy Token2024-03-02T03:04:27ZWerner RaathGitlab Registry Login Timeout using Deploy Token<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "regression" or "bug" label:
- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression
- https://gitlab....<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "regression" or "bug" label:
- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression
- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=bug
and verify the issue you're about to submit isn't a duplicate.
--->
### Summary
When logging into my docker registry using my deploy key, it fails. This is inconsistent, because sometimes it works and sometimes it fails. Definitely not network related.
### Steps to reproduce
```
docker login registry.gitlab.com -u gitlab+deploy-token-XXXXX -p XXXXXXXXXXXXXXXXXXXX
```
### What is the current *bug* behavior?
```
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Error response from daemon: Get https://registry.gitlab.com/v2/: Get https://gitlab.com/jwt/auth?account=gitlab%2Bdeploy-token-XXXXX&client_id=docker&offline_token=true&service=container_registry: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) (Client.Timeout exceeded while awaiting headers)
```
### What is the expected *correct* behavior?
```
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
```Awaiting further demandhttps://gitlab.com/gitlab-org/gitlab/-/issues/233869Can't upload pypi packages to public repositories - 403 Forbidden2023-10-24T02:05:34ZJorge C. LeitãoCan't upload pypi packages to public repositories - 403 Forbidden### Summary
Uploading to the repository's Pypi registry fails with 403 Forbidden on public repositories.
### Steps to reproduce
1. Fork [jorgecarleitao/test-pypi](https://gitlab.com/jorgecarleitao/test-pypi)
2. Add a new deploy token...### Summary
Uploading to the repository's Pypi registry fails with 403 Forbidden on public repositories.
### Steps to reproduce
1. Fork [jorgecarleitao/test-pypi](https://gitlab.com/jorgecarleitao/test-pypi)
2. Add a new deploy token with scopes to read and write from/to registry:
![Screenshot_2020-08-06_at_07.12.44](/uploads/3651db3bf101d77fad1c117c1cf86a6d/Screenshot_2020-08-06_at_07.12.44.png)
3. Add two variables in CI/CD with those credentials:
![Screenshot_2020-08-06_at_07.15.18](/uploads/316552d4d54e8de212e711ade8958e38/Screenshot_2020-08-06_at_07.15.18.png)
4. Trigger a build on master.
This will run
```
- pip install twine
- python setup.py sdist
- python -m twine upload --repository-url https://gitlab.com/api/v4/projects/${CI_PROJECT_ID}/packages/pypi dist/*
```
5. See the upload to fail (e.g. https://gitlab.com/jorgecarleitao/test-pypi/-/jobs/673337176)
I also reproduced this in my local computer by running the steps above after `export`ing the two variables.
### What is the current *bug* behavior?
The package upload fails with a 403 Forbidden
### What is the expected *correct* behavior?
The package should be correctly uploaded to the package registry.
### Output of checks
This bug happens on GitLab.comBackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/216245Non-admin user cannot view Project Usage or padlock symbol of enabled deploy key2023-10-24T02:07:03ZAdam MulvanyNon-admin user cannot view Project Usage or padlock symbol of enabled deploy key
### Summary
Non-admin user cannot view Project Usage or padlock symbol of enabled deploy keys under CI/CD settings -> Deploy Keys
### Steps to reproduce
As a non-admin user:
1. Add a deploy key to project under Settings -> CI/CD ->...
### Summary
Non-admin user cannot view Project Usage or padlock symbol of enabled deploy keys under CI/CD settings -> Deploy Keys
### Steps to reproduce
As a non-admin user:
1. Add a deploy key to project under Settings -> CI/CD -> Deploy keys
2. Look at "Project Usage", it will say "None".
This will work for "Privately accessible keys" (disabled but available) but does not work for "Enabled keys".
There are no issues if viewing the keys as the admin user.
Behavior is the same if the key has been added to multiple projects.
### Example Project
Requires own login to reproduce.
### What is the current *bug* behavior?
"Project Usage" says "None" next to the key fingerprint. Padlock symbol that represents whether the key has read/write access is not visible.
### What is the expected *correct* behavior?
It should say "Current Project" with a padlock symbol that represents whether the key has read/write access.
### Relevant logs and/or screenshots
##### When working, i.e. using admin user it should look like:
![image](/uploads/8e589c13dc37ae93ddad1c31ae2c3f4f/image.png)
##### However when using a non-admin user:
![image](/uploads/9b202c9ea2e7db5d422856fd92ebdbde/image.png)
### Output of checks
#### Results of GitLab environment info
Tested on 12.8.2 and 12.10.1
#### Results of GitLab application Check
### Possible fixes
Issue reported by customer in: https://gitlab.zendesk.com/agent/tickets/155101 (Internal Use Only)
@psureshbabuBackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/232767[Proposal][UI][Deploy Tokens] Show token in kubernetes.io/dockerconfigjson se...2023-03-17T14:36:49ZBuk Bukowski[Proposal][UI][Deploy Tokens] Show token in kubernetes.io/dockerconfigjson secret format### Problem to solve
In order to setup secrets in kubernetes for user and password for gitlab container registry we have to perform steps that can be done automatically on the frontend.
### Intended users
Container registry and kubernet...### Problem to solve
In order to setup secrets in kubernetes for user and password for gitlab container registry we have to perform steps that can be done automatically on the frontend.
### Intended users
Container registry and kubernetes users.
### User experience goal
After creating new deploy tokens, under new login and password that is shown there should be additional format for kubernetes secrets explained below.
### Proposal
Show additional box with either:
- a) full kubernetes yaml secret: (replace env vars)
======================
![mspaint_KomKPfjefO](/uploads/b05da1cbadc15915d94bf114c0674263/mspaint_KomKPfjefO.png)
=====================
- b) just the token for example:
````
UmVhbGx5IHJlYWxseSByZWVlZWVlZWVlZWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGx5eXl5eXl5eXl5eXl5eXl5eXl5eSBsbGxsbGxsbGxsbGxsbG9vb29vb29vb29vb29vb29vb29vb29vb29vb25ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==
````
### Further details
This format is really simple, its just json file below but base64 encoded:
````json
{
"auths": {
"$registry-address": {
"auth": "base64($deploy-token-user:$deploy-token-password)"
}
}
}
````
### Availability & Testing
Simple test decoding back.
### Links / references
https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials
https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#inspecting-the-secret-regcredBackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/335785[Deploy Keys] Allow administrators to view list of all privately added deploy...2023-02-28T19:55:54ZHarsh Chouraria[Deploy Keys] Allow administrators to view list of all privately added deployed keys<!-- This issue template can be used a great starting point for feature requests. The last section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated ...<!-- This issue template can be used a great starting point for feature requests. The last section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated using the release post item generator: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator. The remaining sections are the backbone for every feature in GitLab. -->
### Release notes
<!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " -->
Administrators can view a list of all non-global deploy keys, and their project associations
### Problem to solve
<!-- What is the user problem you are trying to solve with this issue? -->
Currently there's no central view for administrators to view deploy keys that were added by users at the project level and shared between their owned projects.
Administrators can currently only view the list of deploy keys added at the instance level (public marked deploy keys) under **Admin Area > Deploy Keys**, and only query the remainder via the REST API: https://docs.gitlab.com/ee/api/deploy_keys.html#list-all-deploy-keys
### Proposal
<!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. -->
Add a view that can allow administrators to list all deploy keys and their associated projects, regardless of the visibility level of the key.Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/332322Deploy key management2023-03-22T20:32:34ZRoel HelsenDeploy key management<!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.-->
# Proposal
<!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details...<!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.-->
# Proposal
<!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. -->
<!-- Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section.
-->
### Background
The current deploy key system works well, but is very cumbersome if you have many projects.
I am using gitlab with deploy keys for a git project with submodules, where both the parent project and the submodules are projects in our gitlab instance. Currently I have to go to the deploy keys section of the parent project and all the submodules to enable the deploy key for a new machine. Since there are a lot of submodules, this is a cumbersome job.
### Solution
I would like to have an interface where I can manage the deploy keys for many projects at once.
One possibility would be to have a list of deploy keys, showing all the available deploy keys and an add button to add a new deploy key.
When you select to edit a deploy key from this list, you get the current edit window and then below that a list of all projects, grouped by groups with two checkboxes; one for enabling the deploy key for the project and a second one to allow write access for that project.
In this way, one can add a deploy key for a new machine and configure it for all projects in one go.
Ideally there will also be a delete button to remove the deploy for all projects at onceBackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/327212Have a different welcome message for ssh connections with deploy keys2023-03-22T20:32:56ZSabine CarpenterHave a different welcome message for ssh connections with deploy keys<!-- The first section "Release notes" is required if you want to have your release post blog MR auto generated. Currently in BETA, details on the **release post item generator** can be found in the handbook: https://about.gitlab.com/ha...<!-- The first section "Release notes" is required if you want to have your release post blog MR auto generated. Currently in BETA, details on the **release post item generator** can be found in the handbook: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator and this video: https://www.youtube.com/watch?v=rfn9ebgTwKg. The next four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended in your first draft, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. -->
### Release notes
<!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " -->
### Problem to solve
<!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." -->
When adding a deploy key to a particular repository and then using this ssh key to create an ssh connection to GitLab.com, the output will be `Welcome to GitLab! @CreatorUsername`. This gives the user the impression, they are creating the ssh connection with the ssh key associated with their GitLab account. When they then try to push to any of their private repositories, this will fail if they are still using the deploy key. This can be misleading, as the welcome message outputs the creator's name.
As a GitLab user when creating an ssh connection with a deploy key (e.g. with `ssh -T git@gitlab.com`), I would expect the ouput of the welcome message to be something like `Welcome to GitLab, deployKeyName (fingerprint)!)` because this would not give me the impression that I am logging in to my personal GitLab account.
### Intended users
<!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later.
Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/
* [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager)
* [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager)
* [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead)
* [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer)
* [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer)
* [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer)
* [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator)
* [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst)
* [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager)
* [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer)
* [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test)
* [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops)
* [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#priyanka-platform-engineer)
* [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst)
* [Eddie (Content Editor)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#eddie-content-editor)
-->
Unknown (all GitLab users)
### User experience goal
<!-- What is the single user experience workflow this problem addresses?
For example, "The user should be able to use the UI/API/.gitlab-ci.yml with GitLab to <perform a specific task>"
https://about.gitlab.com/handbook/engineering/ux/ux-research-training/user-story-mapping/ -->
The user should be able to distinguish from the Welcome message, whether they have established an ssh connection to GitLab with their private ssh key or a deploy key.
### Proposal
<!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey -->
- User adds an ssh key to their account
- User then adds a deploy key to one of their existing repositories (repo1)
- User forgets about the deploy key but their local is using it for the ssh connection
- User pushes to a repository, where the deploy key has not been assigned to (repo2) -> this will fail
- User troubleshoots it by running `ssh -T git@gitlab.com` -> This will now output `Welcome to GitLab, deployKeyName (deployKeyFingerprint)!`
- Now the user knows that they have misconfigured their local to use the wrong ssh key and can correct it
### Further details
<!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. -->
This would help GitLab users to troubleshoot the issue themselves, resulting in finding the solution sooner.
### Permissions and Security
<!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?
Consider adding checkboxes and expectations of users with certain levels of membership https://docs.gitlab.com/ee/user/permissions.html
* [ ] Add expected impact to members with no access (0)
* [ ] Add expected impact to Guest (10) members
* [ ] Add expected impact to Reporter (20) members
* [ ] Add expected impact to Developer (30) members
* [ ] Add expected impact to Maintainer (40) members
* [ ] Add expected impact to Owner (50) members -->
Anyone who is allowed to push code/pull from/to repository.
### Documentation
<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change
* Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/workflow.html
* If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html -->
### Availability & Testing
<!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier.
What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?
Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
* Unit test changes
* Integration test changes
* End-to-end test change
See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning -->
### Available Tier
<!-- This section should be used for setting the appropriate tier that this feature will belong to. Pricing can be found here: https://about.gitlab.com/pricing/
* Free
* Premium/Silver
* Ultimate/Gold
-->
Free
### What does success look like, and how can we measure that?
<!--
Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this.
Create tracking issue using the the Snowplow event tracking template. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Snowplow%20event%20tracking.md
-->
Success would be to be able to distinguish from the Welcome message, whether a user has used their own ssh key or a deploy key they have created for the connection.
### Is this a cross-stage feature?
Most likely.
<!-- Communicate if this change will affect multiple Stage Groups or product areas. We recommend always start with the assumption that a feature request will have an impact into another Group. Loop in the most relevant PM and Product Designer from that Group to provide strategic support to help align the Group's broader plan and vision, as well as to avoid UX and technical debt. https://about.gitlab.com/handbook/product/#cross-stage-features -->Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/326814Docs feedback: Documentation on publicly-accessible deploy keys is inaccurate2023-03-22T20:32:59ZKostiantyn VolenbovskyiDocs feedback: Documentation on publicly-accessible deploy keys is inaccurate
Current documentation in https://docs.gitlab.com/ee/user/project/deploy_keys/ seem to have following issues :
-https://docs.gitlab.com/ee/user/project/deploy_keys/#public-deploy-keys doesn't indicate that is applicable only on self-man...
Current documentation in https://docs.gitlab.com/ee/user/project/deploy_keys/ seem to have following issues :
-https://docs.gitlab.com/ee/user/project/deploy_keys/#public-deploy-keys doesn't indicate that is applicable only on self-managed instances. Well, there is indication on that saying 'admin area' and 'admin area' applies only to self-managed (https://docs.gitlab.com/ee/user/admin_area/)
-it doesn't explain on what SaaS customers see when they click 'publicly-accessible deploy keys' in any of their projects and if those are of any use for any of the integrations. I see certain keys that I have no clue about.
<!-- Don't edit below this line -->https://gitlab.com/gitlab-org/gitlab/-/issues/282535Deploy tokens to have read/write access to Artifacts2023-03-27T16:16:36ZTim Rizzitrizzi@gitlab.comDeploy tokens to have read/write access to Artifacts### Release notes
Do you use GitLab Ci/CD and need to download your pipelines artifacts? Have you been using your personal access token and thinking about how you don't like using your PAT like this. Well, now you can use your Deploy to...### Release notes
Do you use GitLab Ci/CD and need to download your pipelines artifacts? Have you been using your personal access token and thinking about how you don't like using your PAT like this. Well, now you can use your Deploy token (group or project level) to download your pipeline artifacts.
### Problem to solve
Deploy tokens do not currently allow you to download build artifacts. As a workaround, you are probably using your personal access token or job token. However, many customers would prefer to use a project or group deploy token instead.
<!-- What is the user problem you are trying to solve with this issue? -->
### Proposal
Allow a user to create a project or group level deploy token that will allow them read and/or write access to their Artifacts.
<!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. -->Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/255606Group Deploy tokens to grant access to "shared projects" within a group2022-12-14T13:43:42ZTim Rizzitrizzi@gitlab.comGroup Deploy tokens to grant access to "shared projects" within a group### Problem to solve
You can [share projects with other groups](https://docs.gitlab.com/ee/user/project/members/share_project_with_groups.html#sharing-a-project-with-a-group-of-users). This makes it possible to add a group of users to a ...### Problem to solve
You can [share projects with other groups](https://docs.gitlab.com/ee/user/project/members/share_project_with_groups.html#sharing-a-project-with-a-group-of-users). This makes it possible to add a group of users to a project with a single action. And [a deploy token created at the group level](https://docs.gitlab.com/ee/user/project/deploy_tokens/#group-deploy-token) can be used across all projects that belong either to the specific group or to one of its subgroups.
However, a group deploy token does not grant access to any "Shared Projects" within the group.
#### User quote
As a Developer, I've got a group with most of the projects/images I need, but I also have some "shared" projects/images that I need the deploy token to have access to as well.
If the Group Deploy Token worked also with that shared projects/images it would fix all.
### Intended users
* [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead)
* [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer)
* [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer)
### User experience goal
A Developer can use their Deploy token for all projects within their group, including Shared projects.
### Proposal
A Group deploy token may be granted Developer (or below) permissions on any shared projects within their group, so that they can push images and code to projects their group has been invited to.
### Further details
<!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. -->
### Permissions and Security
- Similar to how shared projects work now, Developer will be a maximum level of permissions for shared projects.
- And it is possible to prevent projects in a group from sharing a project with another group. This allows for tighter control over project access.
### Documentation
- [Group deploy token docs will need to be updated](https://docs.gitlab.com/ee/user/project/deploy_tokens/#group-deploy-token)
- [Share projects docs](https://docs.gitlab.com/ee/user/project/members/share_project_with_groups.html)
### Availability & Testing
<!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier.
What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?
Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
* Unit test changes
* Integration test changes
* End-to-end test change
See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning -->
### What does success look like, and how can we measure that?
Success looks like we help Developers work efficiently and safely by ensuring that Deploy tokens for all of their projects that they are responsible for.
#### Metrics
- Measure the number of Deploy tokens created (group vs. project)
- Measure the number of Deploy tokens used (group vs. project)
- Measure the number
### What is the type of buyer?
<!-- What is the buyer persona for this feature? See https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/
In which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers -->
### Is this a cross-stage feature?
Yes, this impacts the Package stage and the Release stage
### Links / references
- https://gitlab.com/gitlab-org/gitlab/-/issues/22718#note_375656743
- https://docs.gitlab.com/ee/user/project/members/share_project_with_groups.html
- https://docs.gitlab.com/ee/user/project/deploy_tokens/#group-deploy-token
- https://docs.gitlab.com/ee/user/permissions.htmlBackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/234232Deploy Keys for "Protected Environment" - preparatory work2023-02-28T19:56:27ZEtienne BaquéDeploy Keys for "Protected Environment" - preparatory work<!-- The first four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended, while the rest of the sections can be filled out during the problem validation or breakdown phase. Howe...<!-- The first four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. -->
### Problem to solve & proposal
This is an attempt to reduce the scope of https://gitlab.com/gitlab-org/gitlab/-/issues/223748.
Introducing Deploy Keys for Protected Environment will require some preparatory work (which we will offload from the issue linked above):
* Create `deploy_key_id` column in `protected_environment_deploy_access_levels` table.
* Update Protected Environment API to add `deploy_key_id` column in responses. Hide behind FF.
More details about main task breakdown here: https://gitlab.com/gitlab-org/gitlab/-/issues/223748#note_392625872
cc @ogolowinski @csouthard
### Permissions and Security
<!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?
Consider adding checkboxes and expectations of users with certain levels of membership https://docs.gitlab.com/ee/user/permissions.html
* [ ] Add expected impact to members with no access (0)
* [ ] Add expected impact to Guest (10) members
* [ ] Add expected impact to Reporter (20) members
* [ ] Add expected impact to Developer (30) members
* [ ] Add expected impact to Maintainer (40) members
* [ ] Add expected impact to Owner (50) members -->
### Documentation
Documentation will be dealt with in https://gitlab.com/gitlab-org/gitlab/-/issues/223748
### Availability & Testing
<!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier.
What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?
Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
* Unit test changes
* Integration test changes
* End-to-end test change
See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning -->
### What does success look like, and how can we measure that?
<!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. -->
### Is this a cross-stage feature?
<!-- Communicate if this change will affect multiple Stage Groups or product areas. We recommend always start with the assumption that a feature request will have an impact into another Group. Loop in the most relevant PM and Product Designer from that Group to provide strategic support to help align the Group's broader plan and vision, as well as to avoid UX and technical debt. https://about.gitlab.com/handbook/product/#cross-stage-features -->
### Links / references
<!-- Label reminders - you should have one of each of the following labels if you can find the correct ones!
Type - for example ~feature ~bug ~documentation ~meta /label ~"feature::addition" ~"feature::maintenance" ~tooling ~"tooling::pipelines" ~"tooling::workflow" per https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#type-labels
DevOps stage - for example ~"devops::secure"
Group - for example ~"group::composition analysis"
Category - for example ~"Category:Dependency Scanning"
<!-- Label reminders - you should have one of each of the following labels if you can figure out the correct ones! -->Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/214483Docs feedback - feature proposal: Add api to alllow write access to enabled d...2023-02-28T19:57:11ZSebastian Ortiz Vasquezsebastianortiz@seven4n.comDocs feedback - feature proposal: Add api to alllow write access to enabled deploy keys<!-- The first three sections: "Problem to solve", "Intended users" and "Proposal", are strongly recommended, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that p...<!-- The first three sections: "Problem to solve", "Intended users" and "Proposal", are strongly recommended, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. -->
### Problem to solve
Allow an API to give `write access` permission to enabled deploy keys in a project. Right now there is not API to give write access to enabled deploy keys.
### Intended users
Devops
### Proposal
<!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey -->
Add `can_push` parameter to the enable deploy key api.
### Documentation
<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html
* Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements
* If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html -->
### Availability & Testing
<!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier.
What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?
Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
* Unit test changes
* Integration test changes
* End-to-end test change
See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning -->
### What does success look like, and how can we measure that?
<!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. -->
### What is the type of buyer?
<!-- What is the buyer persona for this feature? See https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/
In which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers -->
### Is this a cross-stage feature?
<!-- Communicate if this change will affect multiple Stage Groups or product areas. We recommend always start with the assumption that a feature request will have an impact into another Group. Loop in the most relevant PM and Product Designer from that Group to provide strategic support to help align the Group's broader plan and vision, as well as to avoid UX and technical debt. https://about.gitlab.com/handbook/product/#cross-stage-features -->
### Links / references
https://github.com/terraform-providers/terraform-provider-gitlab/issues/294#issuecomment-613866186Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/212383DSA keys: we appear to support them in our UI2023-10-02T14:48:51ZMike JangDSA keys: we appear to support them in our UI<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "regression" or "bug" label:
- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression
- https://gitlab....<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "regression" or "bug" label:
- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression
- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=bug
and verify the issue you're about to submit isn't a duplicate.
--->
### Summary
Even though we've depreciated DSA keys for SSH, we enable them by default, at least as shown in our UI. [deprecation note](https://about.gitlab.com/releases/2018/06/22/gitlab-11-0-released/#support-for-dsa-ssh-keys)
### Steps to reproduce
Install and configure Omnibus 12.9-ee
Follow the instructions in https://docs.gitlab.com/ee/user/admin_area/settings/visibility_and_access_controls.html
Scroll down to see:
![Screenshot_from_2020-03-24_14-39-11](/uploads/e39fc793b5c97ac078097d41f2eb0d28/Screenshot_from_2020-03-24_14-39-11.png)
(How one can reproduce the issue - this is very important)
### Example Project
(If possible, please create an example project here on GitLab.com that exhibits the problematic behavior, and link to it here in the bug report)
(If you are using an older version of GitLab, this will also determine whether the bug is fixed in a more recent version)
### What is the current *bug* behavior?
DSA keys are enabled by default
### What is the expected *correct* behavior?
DSA keys should at least be disabled, since they were deprecated in 11.0
### Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console output,
logs, and code as it's tough to read otherwise.)
### Output of checks
(If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com)
#### Results of GitLab environment info
<details>
<summary>Expand for output related to GitLab environment info</summary>
<pre>
(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)
(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)
</pre>
</details>
#### Results of GitLab application Check
<details>
<summary>Expand for output related to the GitLab application check</summary>
<pre>
(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:check SANITIZE=true`)
(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true`)
(we will only investigate if the tests are passing)
</pre>
</details>
### Possible fixes
(If you can, link to the line of code that might be responsible for the problem)Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/29761Deploy key no longer has access to delete protected branches2023-03-22T20:41:24Z..:: Mark Veenstra ::..Deploy key no longer has access to delete protected branches### Summary
Yesterday the deploy key stop working for deletions of branches, the following error occurs: `You can only delete protected branches using the web interface.`
### Steps to reproduce
* Add protected branch with wildcard, li...### Summary
Yesterday the deploy key stop working for deletions of branches, the following error occurs: `You can only delete protected branches using the web interface.`
### Steps to reproduce
* Add protected branch with wildcard, like: `feature-*`
* Create a new branch like `feature-delete-test`
* Create a CI/CD pipeline/job that executes `git push origin --delete feature-delete-test`
### Example Project
https://gitlab.com/mobilea/development/modules/tslintworm/-/jobs/241729506
### What is the current *bug* behavior?
Throws the error
### What is the expected *correct* behavior?
Have an alternative way for CI/CD to delete protected branches.
### Output of checks
This bug happens on GitLab.com
### Possible fixes
* Let the deploy key behave the same as the user it is assigned to
* Alternate way I am implementing now is delete the branch through the API, which is allowed: https://docs.gitlab.com/ee/api/branches.html#delete-repository-branchAwaiting further demandhttps://gitlab.com/gitlab-org/gitlab/-/issues/29760Deploy keys aren't allowed to push anymore when push rule "Reject unsigned co...2023-03-06T21:19:03Z..:: Mark Veenstra ::..Deploy keys aren't allowed to push anymore when push rule "Reject unsigned commits" is checked### Summary
Since yesterday deploy keys are not allowed to push to the remote anymore when the push rule "Reject unsigned commits" is checked.
### Steps to reproduce
* Have a deploy key enabled on the repository with write access
* Ch...### Summary
Since yesterday deploy keys are not allowed to push to the remote anymore when the push rule "Reject unsigned commits" is checked.
### Steps to reproduce
* Have a deploy key enabled on the repository with write access
* Check the push rule "Reject unsigned commits"
* Within the CI/CD create a pipeline/job that pushes to the remote
* An error will occur: `remote: GitLab: Commit must be signed with a GPG key`
### Example Project
https://gitlab.com/mobilea/development/modules/tslintworm/-/jobs/241729505
### What is the current *bug* behavior?
Throws an error `remote: GitLab: Commit must be signed with a GPG key`
### What is the expected *correct* behavior?
That deploy keys can still push to the remote.
### Relevant logs and/or screenshots
`remote: GitLab: Commit must be signed with a GPG key`
### Output of checks
This bug happens on GitLab.com
### Possible fixes
1. Allow deploy keys to be handle differently
2. Deploy keys are assigned to a user, maybe also configure it with a GPG to pass the checks?
3. Alternate way would be do allow unsigned commits for a short moment in CI/CD and then re-enable the option through the API, but unfortunaly the API does not allow to change this setting: https://docs.gitlab.com/ee/api/projects.html#edit-project-hookAwaiting further demandhttps://gitlab.com/gitlab-org/gitlab/-/issues/29516Activity via Deploy Keys should be presented differently than Users2023-03-22T20:41:28ZAaron RussoActivity via Deploy Keys should be presented differently than Users### Problem to solve
When a user creates a deploy key for a project and then uses that deploy key, the activity stream shows the user themselves performing the actions and does not indicate that this may be an automated process via depl...### Problem to solve
When a user creates a deploy key for a project and then uses that deploy key, the activity stream shows the user themselves performing the actions and does not indicate that this may be an automated process via deploy key.
This is particularly jarring once such a user has left the organization and is blocked, but they continue to appear in the activity stream.
### Intended users
Systems Admin, Security Analyst
### Further details
By clearly showing the activity is being done via a Deploy Key, it more accurately represents the activity taking place on the system. In addition, it could allow for users to filter out automated processes from the activity stream though I'm not sure how useful that would be.
### Proposal
Instead of showing the activity as being from the user, the activity stream should show a deploy key was the source of the activity and the name of the deploy key.
Taken a step further, it seems like it would be useful to have a better management pane (or at least information page) for individual project deploy keys in the admin interface and that the activity stream should link to such a page for each deploy key for users that are admins.
### Permissions and Security
NA
### Documentation
Deploy Key and/or Activity Stream docs would probably need to be updated.
### Testing
<!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/ -->
### What does success look like, and how can we measure that?
Activity stream no longer shows users that created the deploy key as having performed the actions that the deploy key performed, and clearly denotes that it was a particular deploy key.
### Links / referenceshttps://gitlab.com/gitlab-org/gitlab/-/issues/29034Detach global deploy keys from admin user who created them2023-05-12T22:14:12ZBlair LuncefordDetach global deploy keys from admin user who created them### Problem to solve
An admin user account created [global deploy keys](https://docs.gitlab.com/ee/ssh/#global-shared-deploy-keys) with read-write privileges for use in automated scripts. Some scripts push to repositories every 15 minut...### Problem to solve
An admin user account created [global deploy keys](https://docs.gitlab.com/ee/ssh/#global-shared-deploy-keys) with read-write privileges for use in automated scripts. Some scripts push to repositories every 15 minutes. Every time the script executes a push, it shows as activity by the admin user and notifies that user.
This activity drowns out the actual activity of the admin user, and doesn't depict the actual activity - of the automated script. It would be preferable not to attach the global deploy keys to the admin who created them.
Proposed in this ticket: https://gitlab.zendesk.com/agent/tickets/120055 (internal use only)
### Intended users
Admin users of GitLab creating global deploy keys
### Further details
From the user:
>I always get notifications like "You pushed to yesss-deva1-search01 at Operations / etckeeper just now" in my gitlab web interface. This is annoying, because I don't see my own changes anymore.
>
>Also, all those pushes are recorded as activity of my user account, but clearly these are not mine.
### Proposal
The deploy keys should be associated with either a robot "user" or a group.
### What does success look like, and how can we measure that?
The deploy keys are not associated with my user account and I do not get notifications or activity recorded for pushes done with the deploy key.
### Links / referencesBackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/24477"Publicly accessible deploy keys" shows keys from other users and leaks name ...2023-03-22T20:42:19ZClaas Augner"Publicly accessible deploy keys" shows keys from other users and leaks name of private repository### Summary
At https://gitlab.com/claasaug/test-deploy-key/settings/repository#js-deploy-keys-settings, I can see a list of 15 publicly accessible deploy keys with their project usage.
Apart from the fact that I probably shouldn't see ...### Summary
At https://gitlab.com/claasaug/test-deploy-key/settings/repository#js-deploy-keys-settings, I can see a list of 15 publicly accessible deploy keys with their project usage.
Apart from the fact that I probably shouldn't see these keys, at least one of the projects appears to be private, namely `pinocchio / skd` (i.e. [pinocchio/skd](https://gitlab.com/pinocchio/skd) is not accessible).
![image](/uploads/e6eef37a88113b93ec24fadb92240136/image.png)
### Steps to reproduce
1. Create project.
2. Go to "Settings" > "Repository" > "Deploy Keys" > "Publicly accessible deploy keys"
### Example Project
(See above.)
### What is the current *bug* behavior?
1. Deploy keys from other users are displayed.
2. The name of a project I don't have access to is shown.
### What is the expected *correct* behavior?
1. The deploy keys shouldn't be displayed.
2. Projects that I don't have access to shouldn't be listed.
### Relevant logs and/or screenshots
(Not applicable.)
### Output of checks
This bug happens on GitLab.com
#### Results of GitLab environment info
(Not applicable.)
#### Results of GitLab application Check
(Not applicable.)
### Possible fixes
(If you can, link to the line of code that might be responsible for the problem)https://gitlab.com/gitlab-org/gitlab/-/issues/5902Global Deploy Tokens2023-03-22T20:44:56ZDavid De SousaGlobal Deploy Tokens### Description
Currently, if you need external access to many container registry images that require authentication (i.e. a microservice architecture), you have two options:
- The newly introduced Deploy Tokens would mean you have to ...### Description
Currently, if you need external access to many container registry images that require authentication (i.e. a microservice architecture), you have two options:
- The newly introduced Deploy Tokens would mean you have to create one deploy token per project and then the script/person/cluster that needs all the images should handle N amount of credentials which is not fun.
- Have a user with Reporter role access to all the projects you need and use an access token, that way you can get a single set of credentials to pull all the images, which if you are in a paid tier it means paying one extra user for the priviledge. This is what I'm doing now and worst is I have two extra users because of this and I'll probably need to add more because of this scenario.
### Proposal
Have a way to create Deploy Tokens with functionality similar to the Deploy Keys, which you can create once in the admin and then assign them per project, that would take the best of the two options above, a non-personal registry-only access to the images while not having to pay for an extra user.
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->
*This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.*
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->Backlog