Skip to content

GitLab Next

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 39,512
    • Issues 39,512
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 1,222
    • Merge requests 1,222
  • Requirements
    • Requirements
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
    • Value stream
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.org
  • GitLabGitLab
  • Issues
  • #30595

Closed
Open
Created Aug 01, 2019 by kvijay460@kvijay460

Manage protected environments from the command line

Problem to solve

We should be able to manage access to environments via API so DevOps can able to provide better access privileges to developers and maintainers.

Intended users

We need to maintain same level of environment access across group(s). A script and API should do this. So it would be better if we do it via API like protected branches have.

Further details

Proposal

Adding attribute to current environment get, edit and create API:

  • GET /projects/:id/environments
  • POST /projects/:id/environments

protecting/unprotecting environments

GET /projects/:project_id/protected_environments
[{name: string, id: integer}]

GET /projects/:project_id/protected_environments/:id
{name: string, id: integer}

POST /projects/:project_id/protected_environments
{name: string, id: integer}

PUT /projects/:project_id/protected_environments/:id
{name: string}

DELETE /projects/:project_id/protected_environments/:id

GET /projects/:project_id/protected_environments/:id/deploy_access_levels
[{id: integer, user_id: integer, group_id: integer, access_level: something}]

GET /projects/:project_id/protected_environments/:id/deploy_access_levels/:id
{id: integer, user_id: integer, group_id: integer, access_level: something}

POST /projects/:project_id/protected_environments/:id/deploy_access_levels
{id: integer, user_id: integer, group_id: integer, access_level: something}

PUT /projects/:project_id/protected_environments/:id/deploy_access_levels/:id
{user_id: integer, group_id: integer, access_level: something}

DELETE /projects/:project_id/protected_environments/:id/deploy_access_levels/:id

This directly matches our data structure:

  1. protected environments are not dependent on the environments in any way, they just have name which matcher the environment
  2. we have this nested deploy_access_level model with different options to set user or group or access_level(maintainer/developer and maintainer), which can't be set simultaneously

Permissions and Security

Only Maintainers can set the environment can configure an environment to be protected (via API or UI) https://docs.gitlab.com/ee/ci/environments/protected_environments.html

Edited Nov 12, 2020 by Orit Golowinski
Assignee
Assign to
Time tracking