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.
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.
Implement support for RBAC authorization for the apps we install to Kubernetes from the clusters page.
- 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.
- Restrict tiller to GitLab managed apps in the configured namespace
- 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: store the admin credentials in a safe place, without exposing them to pipelines create project-specific credentials and expose them to pipelines authorize changes only to the namespace associated to that project (must be unique)
- check that helper applications (tiller, ingress, etc) are still working as expected