Skip to content
GitLab Next
  • Menu
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 43,800
    • Issues 43,800
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1,402
    • Merge requests 1,402
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & 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.org
  • GitLabGitLab
  • Issues
  • #18984
Closed
Open
Created Aug 02, 2017 by Shinya Maeda@shinya.maeda🌴Maintainer

Identify container images as protected to prevent accidental deletion/updates

Problem to solve

The following permissions are available to all developers of a project:

  • Update a container registry
  • Remove a container registry image
  • Publish to Conan repository, Maven repository, or NPM registry

There is currently no way to limit this.

The following features are already available to protect the release process:

  • Protected Branches
  • Protected Tags
  • Protected Environments
  • Protecting Pipeline Settings by hosting .gilab-ci.yml in a separate project

Using these features one can protect every aspect of the release process, except the actual result (container or package). This means any developer of the project can:

  • Delete a container or package that was created by a protected release process.
  • Overwrite a container or package that was created by a protected release process.

Intended users

  • Devon (DevOps Engineer) will restrict the access to container registries and package repositories as part of implementing a secure CI/CD approach.
  • Sam (Security Analyst) will validate that the access to container registries and package repositories was restricted to verify that the CI/CD approach was implemented securely.

Proposal

Add configuration options for restricting all actions except read (create, update and delete) on container registries similar to the existing Protected Branches, Protected Tags and Protected Environments.

The configuration options can be put under Project Settings -> General -> Visibility, project features, permissions ->

  • Container registry
  • Packages

A control can be put next to the checkbox. Similar to the other controls in this section.

Questions

  1. Is there a way to prevent image tags from being overwritten (e.g. protected tags)
  2. Can we ensure that there is no way to change an image's metadata?
  3. Can we ensure that there is no way to push a new image with manually created pipeline metadata (i.e. incorrect metadata)?

Permissions and Security

This change would align the ability to configure permission settings for container registries and package repositories with the existing approach to protected assets.

What does success look like, and how can we measure that?

Container registries and package repositories can be properly protected.

What is the type of buyer?

Either Starter/Bronze or Premium/Silver:

  • Protected Branches is Starter/Bronze.
  • Protected Tags is Starter/Bronze.
  • Protected Environments is Premium/Silver.
Edited Mar 09, 2021 by Tim Rizzi
Assignee
Assign to
Time tracking