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
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 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
ClusterRoleBinding: It connects the
ClusterRole with the
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
Let’s start simple by creating the
api-explorer pod that by writing the
api-explorer-pod.yaml file with the following content.
- name: 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