Tips for kubernetes by using a ServiceAccount

A ServiceAccount is used by containers running in a Pod, to communicate with the API server of the Kubernetes cluster. In this post we will see how this is done and the Kubernetes resources involved in the process.

API Server — HTTP REST API

If you work with a Kubernetes cluster, chances are that you use the kubectl binary, or the web interface, to call the API server. Under the hood, all the calls are made through the HTTP endpoints exposed by the API.

This API is well documented; all the endpoints are described in the .

A simple example: here is the . Of course the request needs to be authenticated and authorized to perform this action. learn  Kubernetes online training from industrial experts.

Accessing the API Server From a Pod

A lot of applications that run in the cluster (read: running in Pods), need to communicate with the API server. Among them are the processes running within the Control Plane (scheduler, controller manager, proxy, etc.), as well as all the applications that need to perform some form of administration for the cluster.

For example, some applications might need to know:

The status of the cluster's nodes.The namespaces available.The Pods running in the cluster, or in a specific namespace.And other things like that.

To communicate with the API server, a Pod uses a ServiceAccount containing an authentication token. Roles (e.g: the right to list all the Pods within a given namespace), or ClusterRole (eg: the right to read all the Secrets within the entire cluster), can then be bound to this ServiceAccount. Respectively with a RoleBinding or a ClusterRoleBinding, so the ServiceAccount is authorized to perform those actions.

From the outside of the cluster: the API server can be accessed using the end point specified in the kube config file ($HOME/.kube/config by default). As an example, if you use a DigitalOcean Managed KubernetesFrom the inside of the cluster (read: from a Pod): the API server can be accessed using the dedicated service of type ClusterIP named kubernetes. This service is there by default and automatically recreated if it is deleted by error (it happens).$ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 23h

With the correct rights (more on that later), listing the Pods in the default namespace can be done from a Pod with this simple .

Using the Namespace Default ServiceAccount

Each namespace has a default ServiceAccount, named default. We can verify this with the following command:

$ kubectl get sa --all-namespaces | grep default
default default 1 6m19s
kube-public default 1 6m19s
kube-system default 1 6m19s

Let's inspect the ServiceAccount named default of the default namespace (this will be pretty much the same for the default ServiceAccount of another namespace).

$ kubectl get sa default -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: default
namespace: default
...
secrets:
- name: default-token-dffkj

We can see here that a Secret is provided to this ServiceAccount. Let's have a closer look at this one:

$ kubectl get secret default-token-dffkj -o yaml
apiVersion: v1
data:
ca.crt: LS0tLS1CRU...0tLS0tCg==
namespace: ZGVmYXVsdA==
token: ZXlKaGJHY2...RGMUlIX2c=
kind: Secret
metadata:
name: default-token-dffkj
namespace: default
...
type: kubernetes.io/service-account-token