Environment.action: access and verify should not require the roles configured for protected environments

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Problem to solve

Release managers and developers need to run non-deployment jobs — such as terraform plan, smoke tests, or pre-deployment validation — against protected environments without being granted full deployment access. Today, all jobs targeting a protected environment require the user to be in the "allowed to deploy" configuration, regardless of whether the job actually modifies the environment.

The environment.action CI attribute has 5 valid values:

  • start (default)
  • stop
  • prepare
  • access
  • verify

The intended behavioral distinction between these actions is:

No timer reset Resets timer
No approval required verify access
Approval required (out of scope for this issue) prepare

start and stop represent actual deployment operations and are intentionally excluded from the above matrix.

A strongly related issue is #437132, which tightens the requirements on prepare. The two issues together define the full permission model for environment actions.

Proposal

Remove the "allowed to deploy" requirement for jobs with environment.action: verify or environment.action: access against protected environments. Developer-role users should be able to trigger, retry, and cancel these jobs without needing deployment permissions.

prepare, start, and stop actions remain restricted to users in the "allowed to deploy" configuration.

Implementation note: This change should be delivered as an opt-in per-environment setting in the protected environment configuration UI, not as a default behavior change.

Existing protected environments were configured with the assumption that "allowed to deploy" gates all environment interaction. A silent default change on upgrade breaks that contract. Maintainers who enable the setting are explicitly accepting the security tradeoff described below.

Security considerations

Scoped CI/CD variable exposure

Jobs with environment.action: verify or action: access still receive all CI/CD variables scoped to that environment. Those variables typically contain deployment credentials (cloud provider keys, API tokens, database connection strings). The environment.action value controls environment state (deployment records, timer resets, approval gates) — it does not control variable injection.

This means a Developer who triggers a verify job against a protected production environment will receive production credentials in the job's execution context. The action type does not constrain what the job script does with those credentials.

This is an accepted and documented tradeoff, not an oversight. The recommended pattern for customers who want to use this feature with minimal credential exposure is to use OIDC/short-lived tokens for cloud authentication rather than static secrets stored as CI/CD variables. This bounds the blast radius of any given job execution to the permissions of the OIDC role.

Audit Events

This feature requires an audit event.

When a Developer-role user (one not in the"allowed to deploy" list) triggers a verify or access job against a protected environment, that execution should be logged. This is a permission expansion from the current behavior and is a compliance requirement for the enterprise customers driving this request.

Intended User Personas

  • Rachel (Release Manager) — orchestrating production pipelines where prep/validation steps should not require elevated deployer access

  • Sasha (Software Developer) — running MR validation jobs (e.g. terraform plan) against protected environments to preview impact before merging

Customer value and demand

The primary customer demand for this feature is from self-managed GitLab Ultimate customers with enterprise deployment workflows that separate validation steps from deployment steps.

Feature Adoption Usage Metrics

Instrumentation needed to enable these metrics.

  • Number of protected environments with the opt-in setting enabled
  • Number of jobs triggered by Developer-role users (i.e., non-deployers) against protected environments with action: verify or action: access

Issue description archive

Release notes

Problem to solve

As a Release Manager, I want to make sure that engineers can run "plan" jobs that do not change the environment without maintainer rights or any special roles and processes.

The environment.action CI attribute has 5 valid values:

  • start (default)
  • stop
  • prepare
  • access
  • verify

We learned that prepare/access/verify are identical in terms of behaviour. At the same time, there are various requests asking for different behaviour in different use cases. We want to provide the following setup:

require approval \ reset timer ❌ reset timer ✅ reset timer
❌ approval verify access
✅ approval ❓ prepare

A strongly related issue is Environment.action: prepare should require the ... (#437132) that strengthens the requirements on prepare.

Proposal

Today, all jobs with environment.action: verify|access to a protected environment only allow users in the “allowed to deploy” configuration to run them. Remove this requirement and allow verify/access jobs to be triggered by regular (Developer) users.

Intended users

Feature Usage Metrics

  • MAU of environment.action jobs by value

Does this feature require an audit event?

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.

Edited by Darren Eastman