Skip to content
GitLab
Next
Projects Groups Snippets
  • /
  • 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 44,761
    • Issues 44,761
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1,332
    • Merge requests 1,332
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • GitLabGitLab
  • Issues
  • #30595
Closed
Open
Issue 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