Skip to content

Quickstart 4: GitOps

Warning

This page is in an alpha stage. Content may be modified anytime.

So far, you’ve seen how to interact with the Kubernetes cluster manually, using your own personal account. This is all good and well, but you may want to do things a bit differently. Indeed, manual actions are hard to track : if a deployment has failed, how do you know when and how it was modified ? With Helm, you may have versioned in Git your chart and its values, but what if the manual helm upgrade was using a local-only test version, or an outdated one ?

GitOps aims at solving these issues : everything, including the launch of deployment commands must be logged, whether in Git, or in a pipelines history. This also helps with reproducibility : your deployment workflow is written in a file, and not a list of command you must memorize and type yourself.

ServiceAccount

To automatically interact with a Kubernetes cluster from a CD tool, one needs to authentify to WoK through a ServiceAccount.

Using the CLI

Once in the correct project (use oc project to switch), you will need to create the ServiceAccount using the following command :

oc create sa quickstart-gitlab-ci

Here, we name it quickstart-gitlab-ci, but you may change the name as you see fit.

Using the WebUI

The ServiceAccount creation requires the following snippet of YAML :

apiVersion: v1
kind: ServiceAccount
metadata:
  name: quickstart-gitlab-ci
  namespace: test-quickstart-serviceaccount

ServiceAccount creation

Here, we name it quickstart-gitlab-ci, but you may change the name as you see fit.

Access Token

When creating a ServiceAccount, a bound secret is made as well, named quickstart-gitlab-ci-dockercfg-xxxxx. While this secret contains access tokens (in the form of a JWT), they are only temporary, with a one hour lifespan. This makes them impractical for our current use. Instead, you will need to create a long-lived secret.

Using the CLI

Create the following resource using either oc apply or oc patch :

apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
  name: quickstart-gitlab-ci-token
  annotations:
    kubernetes.io/service-account.name: quickstart-gitlab-ci

You may either create a file (quickstart-token.yaml for instance) with this content, then do oc apply -f quickstart-token.yaml, or pass it directly from stdin :

cat <<EOF | oc create -f -
apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
  name: quickstart-gitlab-ci-token
  annotations:
    kubernetes.io/service-account.name: quickstart-gitlab-ci-token
EOF

You will then be able to retrieve the token value using :

oc get secret quickstart-gitlab-ci-token --template {{.data.token}} | base64 -d

Using the WebUI

Here too, you will need to create the resource from a YAML file :

Access Token Secret creation

Once done, you can access the token value in the data field token.

Token access

RoleBinding

Using the token you’ve created, you may access WoK. However, you will quickly come to realize this doesn’t help much :

$ oc get pods
Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:test-quickstart-serviceaccount:quickstart-gitlab-ci" cannot list resource "pods" in API group "" in the namespace "default"
$ oc project test-quickstart-serviceaccount
error: You are not a member of project "test-quickstart-serviceaccount".
You are not a member of any projects. You can request a project to be created with the 'new-project' command.
To see projects on another server, pass '--server=<server>'.

Indeed, the ServiceAccount you’ve just created is bound to no Role. It has no permission, and while it can connect to the Kubernetes API, it may perform no further action. Reading or creating resources is forbidden by default on OKD !

A ClusterRole need to be assigned, one which can effectively modify the resources of the namespace.

Using the CLI

oc create rolebinding edit --clusterrole edit --serviceaccount <namespace name>:quickstart-gitlab-ci

Using the WebUI

Go to the RoleBindings page of your project, and fill out the following form :

RoleBinding creation

You will then be able to interact with Kubernetes resources !