Skip to content

GitLab Next

Project 'gitlab-org/gitlab-ce' was moved to 'gitlab-org/gitlab-foss'. Please update any links and bookmarks that may still have the old path.
Closed
Created by Mark Pundsack@markpundsackContributor

Support Kubernetes RBAC for GitLab Managed Apps

Note: we are forcing ABAC to be on when creating a new GKE cluster in CI/CD > Kubernetes, but we should revert this change when we'll have proper RBAC support, or at least auto-detect what we want to use based on the cluster.

Description

Kubernetes clusters support both Legacy authorization (ABAC) and full RBAC. We consider ABAC to be always enabled, and leverage this to install applications and to interact with the cluster.

Now that RBAC is enabled by default, and ABAC has been disabled by default on GKE, we want to support the new model.

Proposal

Implement support for RBAC authorization for the apps we install to Kubernetes from the clusters page.

  1. Enable RBAC by default on cluster creation.
    • Once we confirm RBAC is enabled, create cluster-wide access roles for Helm Tiller
    • Enable mutual TLS authentication for Tiller, with only GitLab having the private key. This will mitigate to a large degree the huge security hole we create * above with Tiller having cluster-wide access.
    • For all GitLab managed apps, enable RBAC role creation based on their helm chart settings.
  2. Restrict tiller to GitLab managed apps in the configured namespace
  3. Provide apps read access outside the namespace (if not provided by default)

The first iteration should support project isolation: it means that, if a cluster is used by different projects at the same time, a project cannot alter applications for other projects.

Instead of using the global admin credentials to interact with the cluster, we should:

  1. store the admin credentials in a safe place, without exposing them to pipelines
  2. create project-specific credentials and expose them to pipelines
  3. authorize changes only to the namespace associated to that project (must be unique)
  4. check that helper applications (tiller, ingress, etc) are still working as expected

Feature flag

Since we are are not planning to ship auto devops RBAC in 11.3, the plan is to provide RBAC support for GitLab Managed apps behind a feature flag. When the user/admin enables the "experimental RBAC support" feature flag (auto devops and web terminal support coming soon), then the front-end form will now include a check-box "RBAC-enabled cluster".

Links / references

Edited by Thong Kuah