Teams need to create manual jobs to do things like deployments, or to implement approvals, but it's not obvious how to prevent just anyone from running the action, indicating their approval or actually running the deployment. It's actually possible using protected environments, letting you set the approval list for a job to only be the users associated with that environment, but this needs to be documented better.
Proposal
Add documentation specifically about how to restrict manual jobs, and mention the deploy and approve use cases. To protect a manual job, you need to add the environment key:
deploy_prod:stage:deployscript:-echo "Deploy to production server"environment:name:productionurl:https://example.comwhen:manualonly:-master
Then, configure the environment as protected and allow maintainers/developers or individual users with at least developer access to click on it:
Approval Jobs
An approval job could be implemented in a similar way, it would have no action itself in its script section, but you could structure your stages/DAG such that the pipeline does not proceed past a point until the manual job with the appropriate environment approval has been run. The documentation update should reference approval jobs by name so it's easy to find the solution for this use case.
Reference
We should also reference the new documentation being written for https://gitlab.com/gitlab-org/gitlab-ee/issues/15632 from here, since some users who protect their manual jobs in this way may also want to protect their pipelines.
Category:Fuzz Testing
GitLab Ultimate
devops
application security testing
feature flag
frontend
fuzzing
coverage
group
dynamic analysis
missed:14.7
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
missed:14.3
missed:14.4
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
We'd also like this, potentially with the option to have different deploy tasks requiring different permissions (e.g., live deploy requiring master but a testing deploy allowing developers).
This would be really nice for us if I'm understanding the original request properly. What I am after (and I believe this is outlining) is that there are requirements around who can deploy to certain environments for us. So developers can deploy to lower environments (or the CI pipeline can if your project is setup to automatically deploy) but there is a subset of humans that have to manually verify the site/application before it can be deployed to production.
Right now that means we have to build a custom application to facilitate this complete with permissions and SAML authentication. Ideally we'd keep using the GitLab pipelines for all of this and be able to control some level of access control on who could do those things. Normally we let developer maintainers to do all the things but in this case it's likely a subset of non-maintainers that we would give access to. In our case they are normally reporters that function as "Application Managers" in our world. They own the app from the business sense and are the ones currently allowed to deploy to production as a separate group from a developer that can modify the content of that code. It's a separation of duties discussion (at least within our group) and is maybe not something that is seen as standard in a truly continuous delivery-capable world.
This probably gets into a broader need for better access controls within GitLab that are beyond the capabilities of the RBAC system that's currently in place.
My proposal on how to handle access to manual jobs would be to make this configurable inside the gitlab-ci.yaml so you can adjust this on a per job basis. There are also use cases where you would want to restrict this per role (only maintainers may deploy to production) and other where you'd want to restrict this per user (like for blacklisting trainees or similar)
Hi,
Is Gitlab serious competitor to other build tools and willing to implement user permission levels for build/deployment pipeline. This is a must have option for product where we restrict who can deploy where based on user groups/levels like other build tools have(ie bamboo). If there is option in Gitlab paid version please en-light me if I'm not aware.
The use case is that sometimes you just don't want anyone but Admins to push the button, but you still need the ability to allow pushes/merges in from non-Admins, so protected branch rules aren't stringent enough.
It is pretty easy to change a username so if an approver changes their username and the repository is not updated, someone could potentially change their username to the approver's original name. However, the user with malicious intent would also already require pipeline permissions. Just food for thought.
Correct me if i'm wrong but there is a partial solution for paid users:
You can control who is authorised to deploy to environments by first configure Gitlab Environments and then you can leverage the protected environments feature to control the authorisation.
The protected environments feature is currently available only for Gitlab PREMIUM and gitlab.com SILVER subscriptions.
Jason Yavorskachanged title from Ability to restrict running manual gitlab-ci tasks to admin permission to Ability to restrict running manual gitlab-ci tasks to admin/group/user permission
changed title from Ability to restrict running manual gitlab-ci tasks to admin permission to Ability to restrict running manual gitlab-ci tasks to admin/group/user permission
@ayufan any thoughts on a nice syntax here? There are a few options but each of the ones I've thought of has some downside. It should be clear in some way that the selection is only relevant to manual jobs. The proposal at https://gitlab.com/gitlab-org/gitlab-ce/issues/21809#note_124247071 is interesting.
Yes, it is definitely interesting, but is not valid YAML.
We have already built extensions into when syntax with when: delayed. Should we follow something similar here or is this an anti-pattern?
when combined with start_in:
timed rollout 10%:stage:deployscript:echo 'Rolling out 10% ...'when:delayedstart_in:30 minutes
Introduce a new top level keyword following the start_in example
deploy_production:stage:deployscript:-echo "Deploy to production"when:manualtrigger_permissions :only:roles:-maintainers
Change when to a accept a dictionary and move the string value to a new key in this hash. when: string must remain valid
deploy_production:stage:deployscript:-echo "Deploy to production"when:trigger:manualpermissions:only:roles:-maintainers
But it's clear that it applies only to manual jobs.
I don't think that this should be part of .gitlab-ci.yml if developer can change .gitlab-ci.yml.
Maybe this is somehow connected with protected environments, and maybe we need protected actions on some pipelines?
Or maybe we say that if pipeline is created on protected branch, all manual actions are protected and can be only executed by allowed users (as defined by protection).
We are also looking to restrict modifying Protected Environments access to
Owners.
It should be different from Repository owners vs Environment owners.
After thinking about this a bit more, the protected environments / actions or maybe stages looks like a more desirable approach:
We can use the user id for more granular access control, not the username which would lead to maintainability problems.
New rules are applied right after definition, no need to propagate the config changes on all branches.
when can be part of rules, so we will have to implement access control here.
Protected environments + the ability to prevent developers to edit the CI file seem to fulfill the need to protect manual actions in the deploy stage for static environments. Are there any other use cases for protected actions?
It would be better if you can separate Repository maintainers with
Environment maintainers. So that a maintainer cannot able to change the
environment owners themselves.
Our use case is developers and repo maintainers are CODEOWNERS but not
deploying to all environments themselves.
Developers should be able to auto deploy to lower environments like dev
though.
@mbobin great. I love the brainstorming that's been happening here. So if a job is marked as manual/requiring approval, what does that look like in the yaml? And who then is allowed to click on it?
By default, a protected environment does one thing: it ensures that only people with the right privileges can deploy to it, thus keeping it safe.
A GitLab admin is always allowed to use environments, even if they are protected.
To protect, update, or unprotect an environment, you need to have at least Maintainer permissions
In the Allowed to Deploy dropdown menu, select the role, users, or groups you want to give deploy access to. Keep in mind that:
There are two roles to choose from:
Maintainers: will allow access to all maintainers in the project.
Developers: will allow access to all maintainers and all developers in the project.
You can only select groups that are already associated with the project.
Only users that have at least Developer permission level will appear in the Allowed to Deploy dropdown menu.
Jason Yavorskachanged title from Ability to restrict running manual gitlab-ci tasks to admin/group/user permission to Document how to protect manual jobs for deploys or approvals
changed title from Ability to restrict running manual gitlab-ci tasks to admin/group/user permission to Document how to protect manual jobs for deploys or approvals
I've updated the description with the plan as discussed above. Would love to hear from others in the issue if this will (or won't) cover your use cases.
I think I misunderstood, I was waiting for #15632 (closed) to do the documentation work, but now that I reviewed the previous discussions, I realize that there seem to be two different documentation tasks. One for #15632 (closed), and one based on the discussion at #15819 (comment 215394696).
I'll see if I can do an MR to cover the discussion, and updated description in this issue.
Hi,I am using gitlab-ce:13.4.4, I want to protect manual jobs by creating an additional private repo,but
I am confused about fetch that repo using JOB_TOKEN and I have checked the documentation, but could not find the relevant content. Can you provide an example or tell me where to find related documents? thank you very much.
Sure, no problem (our stack is JS/TS so we're using JS for tooling and utils), and that's basically a standard CI step:
File: accessControl.js:
(replace @ PUT YOUR ACCESS CONTROL REPO HERE with your hidden repo)
constexecSync=require('child_process').execSync;constexecSyncOptions={encoding:'utf-8',cwd:__dirname+'/..',shell:'/bin/bash'};if (!process.env['CI']){console.info('No need to run this outside CI.');process.exit(0);}console.info('[Access Control]: Checking your permissions to run this job...');if (!process.env['CI_JOB_TOKEN']){console.error('Missing CI_JOB_TOKEN environment variable!');process.exit(1);}constremote='https://gitlab-ci-token:'+process.env['CI_JOB_TOKEN']+'@ PUT YOUR ACCESS CONTROL REPO HERE';try{execSync(`git clone ${remote}`,execSyncOptions);console.info('[Access Control]: You are allowed to run this job.');}catch (e){console.error('[Access Control]: You are NOT allowed to run this job! Please contact your TL for assistance.');process.exit(1);}