Respect protected branches for manual actions

Description

We should make sure that permissions for manual actions aligns with expectations of developers, especially for protect branches.

Proposal

Treat manual actions like a repo write.

Example: If the master branch is protected, only people with full permission to that branch can trigger a manual action on that branch.

UX

Hiding any controls to whom is not allowed to

Show the action as disabled, and clearly let the user know why they can't do it with a tooltip.

Tooltip should state: Action not possible due to protected branch

Links

• From https://gitlab.com/gitlab-org/gitlab-ce/issues/17010#note_13272378
• Master issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/21911

Documentation blurb

Manual actions now require the same permissions as a repository write, allowing control over who can trigger manual actions. For example, triggering a manual deploy job to production from the master branch can now be restricted to a narrower set of users with access to commit.

The proposal may be too simple. People already want to allow merging a MR without having full write access to master. And I could easily imagine the master branch having both a "Deploy to staging" and a "Deploy to production" action, with different permission levels. But maybe this will have to do until we have per-environment variables and possibly protected environments.

mentioned in issue #17010 (closed)

Added ~19492 meta labels

Without this feature the manual deploys are not usable for teams. At the moment it doesn't look like it's checking any permissions. Even developer access to a protected branch can trigger the manual build.

I suggest we think about what a reasonable default mapping of permissions is for CE, and if absolutely necessary, create a new issue for EE to have custom permissions or other overrides.

@ayufan What's the current permission model for manual actions? What role can trigger them and what is the interaction with protected branches?

Milestone changed to %Backlog

Added ~307502 label

Removed meta label

Added ~19173 label

Doing mision-crtitical things like deploying to production could be really easily exploited by any user with push rights, regardless of their "manual action permission" (if we had such a thing):

Scenario:

• the project has a pipeline with a manual deployment at the end, only for master branch.
• only the project lead is allowed to deploy to production (this means that our CI image is allowed to access production servers)
• I am a rogue user without permissions to deploy anything but I want to do bad things

Now I can create a branch rogue-user-deployment, and change the deployment job in .gitlab-ci.yml to:

• remove when: manual
• remove only: master

When I push, my code is run in CI and automatically deployed without anyone having reviewed my code. Unfortunately, Permissions for manual actions don't really help here. Does anyone of you have an idea on how we could solve this?

mentioned in issue #21809 (closed)

One option would be to require someone who can action all steps in the default branch's .gitlab-ci.yml to manually start any builds that change the .gitlab-ci.yml in another branch. Another, which would be similar, is to support file locking across branches.

A third is to allow for user/group-specific variables, which override the project and YAML ones, and have the deploy steps rely on one of those (e.g. a SSH key or AWS token).

Now I can create a branch rogue-user-deployment, and change the deployment job in .gitlab-ci.yml to

There is a gitlab-org/gitlab-ce#20826 as a part of securing this case.

mentioned in issue #21770 (moved)

mentioned in issue #21911 (moved)

@siebertm I think we'd need to have multiple things to make this work. e.g. block manual actions on protected branches unless you have access to push to that branch AND have branch- or environment-specific secure variables. This way even if you hacked the .gitlab-ci.yml on a branch, you wouldn't have credentials to do a deploy.

@markpundsack

I posted my comments about protecting important actions. The good thing is that since we are moving into direction of tightening CI with User triggering it will possible make more of this features much easier to implement.

In some big companies only system administrators could deploy to production but they could not see the source code.
Maybe we could have a permission to allow specific user to trigger an specific manual action.

deploy to production but they could not see the source code

@paulobezerra Anybody who has shell access to the production server can simply access the repositories. So in your case administrators can not be prevented from accessing the source code.

Well @winniehell, in some cases it is true. Here we deliver only the binaries to them. Anyway the biggest problem is that: the developers could not deploy to production.
All stages are automated but least production deploy for permission issues (In this case the developers could not trigger manual actions to deploy in production).

Added ~897282 label

Removed ~307502 label

Changed title: Permissions for manual actions → Respect protected branches for manual actions

Refocusing this issue on specifically handling protected branches.

@ayufan let's try to get this in soon.

@dimitrieh I've labeled it with coming soon so you can pick up design for it ahead of engineering.

Mentioned in issue #21911 (moved)

@markpundsack after this release manual actions will most probably be implemented. The first thoughts towards this is hiding any controls to whom is not allowed to.

@dimitrieh yeah, it's probably as simple as hiding the actions.

I will unlabel UX for now ;)

updated issue body

Removed ~19492 label

My organization cannot use gitlab until this feature is implemented. This is absolutely critical

@dimitrieh Then again, following a previous conversation, it might be better to show the action as disabled, and clearly let the user know why they can't do it, so they at least know it's possible but they just don't have permissions rather than being confused why it's just not showing up. Any thoughts how we'd want to show disabled manual actions?

@grzesiek In the meantime, can we make the underlying permissions follow this logic regardless of UI changes? If someone clicks the manual action and it fails with an appropriate message, that's not a horrible experience and at least we'd close the security gap.

@markpundsack It is currently quite easy to restrict the visibility of the play button for manual actions if someone does not have ability to write to the branch that pipeline was created for. Checking permissions in other parts of the code related to starting manual jobs also seems to be feasible without significant effort. Would it make sense to schedule this issue for a release?

@grzesiek I'm suggesting the first step is to harden the backend, not the UI. i.e. Even if the play button is visible, clicking on it should fail. Using the API or Chatops should also fail. Getting it into 9.0 would be great, especially since it changes default behavior and could be seen as a breaking change.

changed milestone to %9.0

added Stretch label

removed ~897282 label

added ~14106 label

@markpundsack I think it doesn't make much difference in the amount of work to fix that on the backend and frontend at the same time, because when we fix that in the backend, no additional ~Frontend work is necessary. I think it makes sense to ship that in 9.0. /cc @ayufan

@grzesiek I assume you're talking about just hiding the manual actions in the frontend. Showing the actions as disabled (as in https://gitlab.com/gitlab-org/gitlab-ce/issues/20261#note_23105398) would take at least some frontend work, right? At any rate, it's fine if frontend is also tackled, I'm just making sure the priorities are clear.

mentioned in issue #28120 (closed)

It will be cool to allow assign deploy option to some users without give master. F.e. for devops which is not developers at all.

It doesn't have to be a role, it can just be a permission that can be applied to any role.. Would even be better if you owners could define roles and then assign the permissions to them.

added ~1071781 ~113220 labels

Yep, it would be great if permissions can be handled in such a way that a user can be given the permission to do a manual deploy (to production) but does not have access to the source code. We only deploy binaries and need this separation to follow regulations otherwise we can not use gitlab ci to deploy to prouction.

Gitlab MUST implement this if it wants to make further inroads into the enterprise market.

@markpundsack i suppose we would show a tooltip with the reason why the button is disabled?

updated issue description to reflect this

@dimitrieh Yeah, that would be ideal.

We need this too asap

@grzesiek @ayufan Any chance of this getting into 9.0?

changed milestone to %9.1

added Deliverable and removed Stretch labels

Looks like it's not possible for 9.0. Moved to 9.1 and tentatively marked as Deliverable, subject to regular planning process.

There is interest from a GitLab customer https://na34.salesforce.com/00161000003RIGC who is very interested in seeing this feature and has indicated that this could help them grow their footprint with GitLab.

mentioned in issue #29131 (moved)

assigned to @grzesiek

Can we also have an option to define who can execute a certain job given the role of the user? e.g., in our organization (who needs SOX-compliance) we need to make sure that developers cannot deploy code to production, only ops can.

@hierarchicalpolymorphist We plan to use protected branches settings to define abilities. In EE we also have ability to restrict push and merge to certain users which can help in your case (if you are EE customer).

@grzesiek We are evaluating gitlab as our CI/CD system, as we need to be SOX-compliant, the CI/CD system cannot let developers to start the "depoy to prod" job. With the protected branch, I guess we need to setup a "production" branch, make it protected and only pushable (and therefore, deployable) by certain users?

@hierarchicalpolymorphist The branch we will evaluate permissions for is a target branch of a merge request.

@grzesiek I just finished going through the whole thread. I guess the approach of permissioning on protected branch could work in our case, but is there any particular reason why permissioning on manual action was not going to implemented / prioritized?

Thanks!

Hmm sorry that I have to step in, but during this thread I think the problems brought up in the first few comments got lost. Just adding the ability to disable the manual action will only look like a secure solution but be easily exploitable! The problem is always where to get the credentials from for a deploy. Right now I have to add them to either the e.g. the docker image, which anyone then can easily read back or to secure variables which anyone who can trigger builds also can read back. The only way that would solve this are imho user or role based secure variables. With those I don't even need a way to disable the manual actions. They will just fail due to missing credentials (of course I can make my deploy script nice and give a good error message in that case). As a good example for secure handling of credentials see e.g. travis-ci.

@hierarchicalpolymorphist @fabio.sturm We plan to improve this, see https://gitlab.com/gitlab-org/gitlab-ce/issues/17010#note_13211412. Using protected branches is the most simple step for now, but this is not the final one. We will probably iterate on top of that!

@grzesiek How would that help? I could just push to a non protected branch which does an "echo credential" to the console and get access. I also don't want multiple environments, e.g. one docker container for developers and one for owners or similar since it breaks reproducability and create a "works in my environment" case...

@fabio.sturm These are really good points, and I agree that being able to define permissions to read secret variables would be better, but it would be also far more difficult to implement. Using protected branches strategy is a most viable change here (/cc @markpundsack @joshlambert). If there is something as simple as that, that would work better for you, let us know!

added docs-missing label

@markpundsack @ayufan In order to ship that in 9.1 we would need to skip showing a tooltip. Is that okay?

mentioned in merge request !10494 (merged)

Yes

changed milestone to %9.2

As discussed with @ayufan we are moving this to 9.2!

mentioned in issue #24196 (closed)

mentioned in issue #30634 (closed)

mentioned in merge request gitlab-com/www-gitlab-com!5551 (merged)

We have a prospect https://na34.salesforce.com/001610000120Exq that is looking for deploy capabilities as follows:

1.  Can we limit who can deploy to specific environments?
        a. I’d like developers to be able to run a pipeline for Environment A (development environment)
        b. I’d like Testers to be able to run a pipeline for Environment B-D (testing environments)
        c. I’d like the Change Control team to run a pipeline for Environment E (Production)

This feature is something my team definitely needs. I work in a highly regulated environment, and I absolutely cannot automate any of our production deploys using GitLab until I can control who has access to trigger manual jobs.

@markpundsack this feature seems to be a good candidate for EE. Thoughts?

Some good points brought up above, and for security, it's important to recognize that this issue is not sufficient. "Protect variables and runners" (https://gitlab.com/gitlab-org/gitlab-ce/issues/24196) is the MVP for securing things, and it's currently slated for 9.3. Technically we probably could have done that one first, but this one has WIP so at this point it makes sense to finish it.

@ChadMalchow Thanks for the suggestion. I think this issue represents some very basic security considerations that should be in CE. Some of the other security issues in the master issue (https://gitlab.com/gitlab-org/gitlab-ce/issues/21911) might be better suited for EE. Perhaps "Environment-specific variables" (https://gitlab.com/gitlab-org/gitlab-ce/issues/20367) and "Protected environments" (https://gitlab.com/gitlab-org/gitlab-ce/issues/20368).

closed via merge request !10494 (merged)

mentioned in issue #36406

mentioned in issue gitlab#6127