Specify "Cluster management project" for a Kubernetes cluster (#32810) · Issues · GitLab.org / GitLab

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

On the cluster page, user selects which project can administer this cluster.
The project will define a .gitlab-ci.yml using environment: as usual.
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
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

Follow-up

#34650

### 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

<!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later.

* [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer)

### Further details

See https://gitlab.com/gitlab-org/gitlab/issues/7983#alternative-proposal-2

### Proposal

1. On the cluster page, user selects which project can administer this cluster.
1. The project will define a `.gitlab-ci.yml` using `environment:` as usual.
1. We *alter* the hierarchy of clusters now to:
   1. Cluster management project for the cluster is this project, if scope matches
   1. Project-level cluster, if scope matches
   1. Group-level cluster, if scope matches
   1. Instance-level cluster, if scope matches
1. 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

* https://gitlab.com/gitlab-org/gitlab/issues/34650

Edited Oct 24, 2019 by Thong Kuah

Discussion
Designs