We'll start by creating the same Jenkins StatefulSet we used in the previous chapter. Once it's up-and-running, we'll try to use Jenkins Kubernetes plugin(https://github.com/jenkinsci/kubernetes-plugin). If we're successful, we'll have a tool which could be used to execute continuous delivery or deployment tasks inside a Kubernetes cluster.
1 cat sa/jenkins-no-sa.yml
We won't go through the definition since it is the same as the one we used in the previous chapter. There's no mystery that has to be revealed, so we'll move on and create the resources defined in that YAML.
OpenShift does not allow setting fsGroup in the security context, it uses Routes instead of Ingress, and Services accessible through Routes need to be the LoadBalancer type. Due to those changes, I had to prepare a different YAML specification for minishift. Please execute oc apply -f sa/jenkins-no-sa-oc.yml --record instead of the command that follows.
1 kubectl apply 2 -f sa/jenkins-no-sa.yml 3 --record
Next, we'll wait until jenkins StatefulSet is rolled out.
1 kubectl -n jenkins 2 rollout status sts jenkins
GKE uses external load balancer as Ingress. To work properly, the type of the service related to Ingress needs to be NodePort. We'll have to patch the service to change its type. Please execute the command that follows.
kubectl -n jenkins patch svc jenkins -p '{"spec":{"type": "NodePort"}}'
Next, we'll discover the DNS (or IP) of the load balancer.
Please change hostname to ip in the following command. The jsonpath should be {.status.loadBalancer.ingress[0].ip}. Please note that GKE Ingress spins up an external load balancer and it might take a while until the IP is generated. Therefore, you might need to repeat the command that follows until you get the IP.
Please change the following command to CLUSTER_DNS=$(minikube ip).
Please change the following command to CLUSTER_DNS=jenkins-jenkins.$(minishift ip).nip.io.
1 CLUSTER_DNS=$(kubectl -n jenkins
2 get ing jenkins
3 -o jsonpath="{.status.loadBalancer.ingress[0].hostname}"
4
5 echo $CLUSTER_DNS
Now that we know the address of the cluster, we can proceed and open Jenkins UI in a browser.
1 open "http://$CLUSTER_DNS/jenkins"
Now we need to go through the setup wizard. It's a dull process, and I'm sure you're not thrilled with the prospect of going through it. However, we're still missing knowledge and tools that will allow us to automate the process. For now, we'll have to do the boring part manually.
The first step is to get the initial admin password.
The command that follows might result in no such file or directory error. In that case, please replace / with // in the path. Continue applying the same fix throughout the book if you continue experiencing the same problem.
1 kubectl -n jenkins 2 exec jenkins-0 -it -- 3 cat /var/jenkins_home/secrets/initialAdminPassword
Please copy the output and paste it into the Administrator password field. Click the Continue button, followed with a click to Install suggested plugins button. Fill in the Create First Admin User fields and press the Save and Finish button.
Jenkins is ready, and only a click away. Please press the Start using Jenkins button.
If we are to use the Kubernetes plugin (https://github.com/jenkinsci/kubernetes-plugin), we need to install it first. We'll do that through the available plugins section of the plugin manager screen.
1 open "http://$CLUSTER_DNS/jenkins/pluginManager/available"
Type Kubernetes in the Filter field and select the checkbox next to it.
Since we are already in the plugin manager screen, we might just as well install BlueOcean as well. It'll make Jenkins prettier.
Type BlueOcean in the Filter field and select the checkbox next to it.
Now that we selected the plugins we want, the next step is to install them. Please click the Install without restart button and wait until all the plugins (and their dependencies) are installed.
We are not yet finished. We still need to configure the newly installed Kubernetes plugin.
1 open "http://$CLUSTER_DNS/jenkins/configure"
The plugin adds Kubernetes as yet another cloud provider. Please expand the Add a new cloud drop-down list inside the Cloud section, and select Kubernetes. The section you're looking for should be somewhere close to the bottom of the screen.
Now that we added Kubernetes as a cloud provider, we should confirm that it works. Please click the Test Connection button.
Unless you forgot to unable RBAC in your cluster, the output should be similar to the one that follows.
Error testing connection : Failure executing: GET at: https://kubernetes.default.svc/api/v1/namespaces/jenkins/pods. Message: Forbidden!Configured service account doesn't have access. Service account may have been revoked. pods is forbidden: User "system:serviceaccount:jenkins:default" cannot list pods in the namespace "jenkins".
Even though Docker for Mac or Windows supports RBAC, it allows any internal process inside containers to communicate with Kube API. That is quite the opposite from what you'll experience in other Kubernetes platforms. As a result, you'll see a few discrepancies between the outputs in this chapter and those you'll see in your cluster. You'll notice that you'll be able to perform actions that are forbidden in other Kubernetes platforms.
API server rejected our request to list the Pods in the jenkins Namespace. Such a reaction makes perfect sense. If any process in any container could request anything from the API, our security efforts would be useless. What would be the point of trying to restrict users (humans), if all it takes is to create a single Pod that sends a request to the API server? Kube API rightfully denied our request to list the Pods.
Just as a username provides a sort of identity to humans, a ServiceAccount is an identity for all the processes that run in containers. Since we did not specify any ServiceAccount for the Pod where Jenkins is running, Kubernetes assigned one for us. The Pod is authenticated as the default account which happens to be bound to roles that give almost no permissions. In other words, if we do not define a ServiceAccount for a Pod, it'll be associated with the ServiceAccount default, and the processes inside that Pod will not be able to requests almost anything from the API server.
The default ServiceAccount is created for every Namespace in the cluster. It is, in a way, similar to the default StorageClass. If a Pod does not have a ServiceAccount, it'll get the default. That ServiceAccount has insufficient privileges, and it cannot do almost anything. We can bind more permissive role to the default ServiceAccount, but that would be a very uncommon solution to the problem.
We need to associate Jenkins process with an entity that has more permissions. As a minimum, we should be able to list the Pods in the jenkins Namespace. To do that, we have to learn about ServiceAccounts first.
We'll delete jenkins Namespace and search for a simple way explore ServiceAccounts.
1 kubectl delete ns jenkins