Search code examples
kubernetesgitlabgitlab-cikubernetes-helmgitlab-ci-runner

Create cluster wide service account to connect with gitlab

I have a self hosted gitlab and I want to deploy applications. I am trying to deploy a runner so that gitlab can connect to the kubernetes cluster. My kubernetes cluster is RBAC enabled.

Here is my gitlab-ci.yml for the runner:

services:
  - docker:18-dind
    
stages:
  - deploy
      
deploy:
  image:
    name: thorstenhans/helm3:latest
    entrypoint: ["/bin/sh", "-c"]
  stage: deploy
  environment:
    name: staging
    kubernetes:
      namespace: runners
  script:
    - echo ${CI_JOB_NAME}
    - helm version
    - kubectl version
    - helm repo add gitlab https://charts.gitlab.io/
    - helm install gitlab/gitlab-runner --version 0.20.0 -f values.yml

Here is the values.yml file:

## The GitLab Server URL (with protocol) that want to register the runner against
## ref: https://docs.gitlab.com/runner/commands/README.html#gitlab-runner-register
##
gitlabUrl: https://gitlab.mydomain.com/
    
## The registration token for adding new Runners to the GitLab server. This must
## be retrieved from your GitLab instance.
## ref: https://docs.gitlab.com/ee/ci/runners/
##
runnerRegistrationToken: "registration code here"
    
## Set the certsSecretName in order to pass custom certificates for GitLab Runner to use
## Provide resource name for a Kubernetes Secret Object in the same namespace,
## this is used to populate the /etc/gitlab-runner/certs directory
## ref: https://docs.gitlab.com/runner/configuration/tls-self-signed.html#supported-options-for-self-signed-certificates
##
#certsSecretName:
    
## Configure the maximum number of concurrent jobs
## ref: https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-global-section
##
concurrent: 10
    
## Defines in seconds how often to check GitLab for a new builds
## ref: https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-global-section
##
checkInterval: 30
    
## For RBAC support:
rbac:
  create: false
    
  ## Run the gitlab-bastion container with the ability to deploy/manage containers of jobs
  ## cluster-wide or only within namespace
  clusterWideAccess: true
    
  ## If RBAC is disabled in this Helm chart, use the following Kubernetes Service Account name.
  ##
  # serviceAccountName: default
    
## Configuration for the Pods that the runner launches for each new job
##
runners:
  ## Default container image to use for builds when none is specified
  ##
  image: ubuntu:18.04
    
  ## Run all containers with the privileged flag enabled
  ## This will allow the docker:stable-dind image to run if you need to run Docker
  ## commands. Please read the docs before turning this on:
  ## ref: https://docs.gitlab.com/runner/executors/kubernetes.html#using-docker-dind
  ##
  privileged: false
    
  ## Namespace to run Kubernetes jobs in (defaults to 'default')
  ##
  # namespace:
    
  ## Build Container specific configuration
  ##
  builds:
    # cpuLimit: 200m
    # memoryLimit: 256Mi
    cpuRequests: 100m
    memoryRequests: 128Mi
    
  ## Service Container specific configuration
  ##
  services:
    # cpuLimit: 200m
    # memoryLimit: 256Mi
    cpuRequests: 100m
    memoryRequests: 128Mi
    
  ## Helper Container specific configuration
  ##
  helpers:
    # cpuLimit: 200m
    # memoryLimit: 256Mi
    cpuRequests: 100m
    memoryRequests: 128Mi

How can I create a service account for gitlab so that it can deploy applications cluster wide?

Solution

  • You can find this informations in gitlab documentation.

    Enabling RBAC support

    If your cluster has RBAC enabled, you can choose to either have the chart create its own service account or provide one on your own.

    To have the chart create the service account for you, set rbac.create to true:

    rbac:
  create: true

    To use an already existing service account, use:

    rbac:
  create: false
  serviceAccountName: your-service-account

    So you would have to change your values.yaml to

    rbac:
  create: false
  clusterWideAccess: true
  serviceAccountName: your-service-account

    There is related documentation about rbac and service accounts.

    There is another stackoverflow post and a gitlab issue which should help with creating the service account for your use case.