### Problem to solve Prior to Gitlab v12.0, Deploy Keys with write access could push commits to protected branches. This is no longer working, and makes Deploy Keys mostly unusable for our use case as they currently work. > Today, we don't treat a deploy key as a machine user, but we evaluate the permission through the owner of the key. This is not an ideal architecture as users are usually registering SSH key as a machine user, which is detached from any user accounts. ### 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 can be found at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ --> Sascha (Software Developer), Devon (DevOps Engineer) ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> We used a Deploy Key to push updated `package.json` version to the `master` branch whenever a new version of our NPM package was released. Now, we either have to unprotect the `master` branch (allowing all developpers to push to `master`) or create a bogus/bot user that has the correct permissions. Unprotecting `master` is obvious why it is not a good idea, one simple reason that comes to mind is that it's easy to push commits on the wrong branch by mistake. Creating a CI/bot user will cost additional money, as we are on the silver plan, as well as adding user management overhead. Old proposal; <details> For us, it would be fine if Deploy Keys could always push to protected branches. If there are concerns about this approach, I suggest that it's possible to allow Deploy Keys to push in either the settings for the deploy key or in the settings for the protected branches. * A Deploy Key currently has a "Write access allowed" setting. An additional setting could be added below: "Write access to protected branches allowed". * When setting protected branches, there could be an area next to "Roles" for deploy keys, that can be toggled on/off. It could simply say "Allow Deploy Key access". </details> ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> In this proposal, we're moving towards having an isolated permission model for deploy keys. Therefore, users can see the keys in the protected branches' interface. - Protected branches will rely on the access of the deploy key owner - Deploy keys are able to push to protected branch if the owner does not have permission to do, but does have access to the project. - When deploy keys are to be able to push the user is not made implicit with the same permission as this will cause unintended access. - When a user is deleted/unassigned from a project the deploy keys will become unavailable. - The workaround of the need for a bot/machine user account to not tie it to a real user account is known and deemed acceptable for now. - **At the project level: - protected branches ** The drop-down for `Allowed to deploy` will get an additional section dedicated to deploy keys: `Deploy keys` - Deploy keys section will feature an information hierarchy and architecture as depicted in the mockup. - The only exception is that we show the deploy key title/name instead of the fingerprint including the first few characters of the MD5 signature as seen at https://gitlab.com/gitlab-org/gitlab/-/issues/30769#note_381468877 - Ellipsing should happen if the content exceeds the width of the dropdown menu - After this change, all of the users have to manually add a deploy key to the protected branch interface for giving it write permission. This means this ~regression requires user action after it's shipped (the https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/44839 will help communicate this). - There will be an additional help text paragraph included in between the deploy keys tabs and the configuration UI with the copy: `Note: Deleting a deploy key might affect existing configurations.` as can be seen at https://gitlab.com/gitlab-org/gitlab/-/issues/30769#note_379238690 - Help text paragraphs `protected branches` section changes to: >>> **Protected Branches** Keep stable branches secure and force developers to use merge requests. By default, protected branches`<link>` are designed to: * prevent their creation from everybody except Maintainers`<link to permissions>` * prevent pushes from everybody except Maintainers * prevent anyone from force pushing to the branch * prevent anyone from deleting the branch You can change the defaults to allow specific users or deploy keys`<link>` to access protected branches. >>> | Mockup ([Figma document](https://www.figma.com/file/qZWFzTBF0ZJbt1CkyV8nAY/30769?node-id=0%3A1)) | | --- | |  | ### 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)? --> ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements --> ### 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? <!-- 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. --> ### Links / references https://gitlab.com/gitlab-org/gitlab-ce/issues/65715 (Documentation) ### Scoped off - https://gitlab.com/gitlab-org/gitlab/-/issues/223750 We eliminate the difference between CE/EE, [allowing to restrict by users, in addition to by roles](https://docs.gitlab.com/ee/user/project/protected_branches.html#restricting-push-and-merge-access-to-certain-users-starter) - https://gitlab.com/gitlab-org/gitlab/-/issues/223748 Update "protected environments" section in a similar way ### Merge request scoping MR breakdown: * ~database change and ~api update (for autocompletion) https://gitlab.com/gitlab-org/gitlab/-/merge_requests/34875 - Done * the ~frontend MR to refactor/start consolidating EE and CE: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/37499 - Done * the main ~frontend MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/35638 - Done * first support ~backend MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/47088 - Done * second support ~backend MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/47305 - Done * third support ~backend MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/47181 - Done * fourth support ~backend MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/48226 - Done * the main ~backend MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36345 - Done * ~documentation: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/42234 - Done * ~backend long-term fix after [regression](https://gitlab.com/gitlab-org/gitlab/-/issues/292450): https://gitlab.com/gitlab-org/gitlab/-/merge_requests/49723 - Done * FF rollout issue: https://gitlab.com/gitlab-org/gitlab/-/issues/247866