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,816
    • Issues 43,816
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1,426
    • Merge requests 1,426
  • 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

Scheduled maintenance on the database layer will take place on 2022-07-02. We expect GitLab.com to be unavailable for up to 2 hours starting from 06:00 UTC. Kindly follow our status page for updates and read more in our blog post.

  • GitLab.org
  • GitLabGitLab
  • Issues
  • #32810
Closed
Open
Created Sep 26, 2019 by Thong Kuah@tkuahMaintainer

Specify "Cluster management project" for a Kubernetes cluster

Problem to solve

In order to successfully configure clusters (e.g. installing cluster applications), a CI job needs to have cluster-admin privileges.

A cluster administrator will like to have a version-controlled repository to keep files related to that cluster. However they would like all other projects to continue to have edit privileges.

Intended users

See #7983 (closed)

Proposal

  1. On the cluster page, user selects which project can administer this cluster.
  2. The project will define a .gitlab-ci.yml using environment: as usual.
  3. We alter the hierarchy of clusters now to:
    1. Cluster management project for the cluster is this project, if scope matches
    2. Project-level cluster, if scope matches
    3. Group-level cluster, if scope matches
    4. Instance-level cluster, if scope matches
  4. The job of a project connected to a cluster management will receive cluster-admin credentials (TBC: if it's a separate account or not)

Update API as well to allow cluster to associate this cluster as well.

Permissions and Security

Documentation

TBC

Testing

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

What is the type of buyer?

Links / references

See also https://docs.gitlab.com/ee/user/admin_area/settings/instance_template_repository.html

Follow-up

  • #34650 (closed)
Edited Oct 24, 2019 by Thong Kuah
Assignee
Assign to
Time tracking