In my last article, I showed how to develop the KubeLogExporter, a tool that collects log data from a set of pods. So far the exporter relies on full access to the Cluster by using the local .kubeconfig file. If we want the exporter to run as a cron job inside the cluster, it needs to have suitable access rights. Originally I wanted to just write about the cron job implementation, but found that investigating how Kubernetes access rights work to be very educational. That’s why it became the article that you are reading now.
This article originally appeared at my blog.
Essential Kubernetes Concepts
When you run a Pod inside a Kubernetes cluster, several default configurations and security aspects are already made by default. To determine the access right to the rich Kubernetes API, the essential resources are ServiceAccount, Role and RoleBindings.
Let’s understand these concepts by considering how the cron job to read pod logs works. When the job runs, it needs read access to namespaces and pods. This access is defined in a Role or ClusterRole. The Role is limited to one namespace only, so we will use the ClusterRole. When a pod is created, it is given the default system account and the default system account token to access the K8S API. However, this account does not have the required access rights, so we need to define a custom ServiceAccount. The final piece is the RoleBinding or ClusterRoleBinding: It connects the ClusterRole with the ServiceAccount.
K8S API: Direct Access
To see how those concepts are applied when working with Kubernetes, I followed this excellent article in which the API is accessed directly with curl.
Let’s start simple by creating the api-explorer pod that by writing the api-explorer-pod.yaml file with the following content.
apiVersion: v1
kind: Pod
metadata:
name: api-explorer
spec:
containers:
- name: alpine
image: alpine
args: ['sleep', '3600']Then we create the container and wait until it is started.
> kubectl create -f api-explorer-pod.yamlpod/api-explorer created
