Meta: Auto DevOps support for RBAC
Problem to solve
Auto DevOps does not currently support interacting with RBAC-enabled k8s clusters.
Auto DevOps deploys its own Tiller, to the project's namespace and creates the project namespace if it doesn't exist
- Automatically creates service account/role restricted to only the project's namespace - #51716
- Place service account info in environment variables, available on the Runner - #51716
- Update script to deploy Helm with the above account/role - gitlab-ci-yml#82 (closed)
- Use local tiller for enabling RBAC on Auto DevOps - !22036 (merged)
- Add a QA spec for RBAC cluster and auto devops - !22025 (merged)
Documentation issue: #51717
The major drawback here is that we by default share a common namespace across all environments in a single cluster. This means that you run the risk of code in a review branch being able to delete production.
Multiple clusters would solve that risk, but reduces the value of shared compute. We may also want to consider more first class support for namespaces per environment, similar to clusters. If RBAC works, you in theory don't need multiple clusters just namespaces.
What does success look like, and how can we measure that?
- Users that create clusters using GitLab's k8s integration will be able to use auto devops when using rbac-enabled clusters
- Users that bring their own rbac-enabled cluster will be able to take advantage of all auto devops features.
Links / references
VERSION: GKE: v1.8.5-gke.0 GITLAB-CE: 10.3.3
ERROR: $ deploy Error: UPGRADE FAILED: configmaps is forbidden: User "system:serviceaccount:demo-15:default" cannot list configmaps in the namespace "demo-15": Unknown user "system:serviceaccount:demo-15:default"
WORKAROUND kubectl create clusterrolebinding demo-15-cluster-rule --clusterrole=cluster-admin --serviceaccount=demo-15:default