Skip to content

GitLab Next

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
GitLab GitLab
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 38,038
    • Issues 38,038
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 1,345
    • Merge requests 1,345
  • Requirements
    • Requirements
    • List
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Operations
    • Operations
    • Metrics
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI/CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • 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
12.8
Milestone
12.8 (Past due)
Assign milestone
Time tracking