Kubernetes 101 : Pods and service accounts
Kubernetes uses service accounts to give the applications running inside the pods credentials.
A service account is a kubernetes resource - living in a namespace -that application running inside pods could use as identifier or credentials to be able to communicate with the API-server for example.
Pods and the applications running inside them have access to this "identity" through a kubernetes object named secret.
The volume holding the secret file is mounted onto the pod.
Below is a diagram that briefly describes the process:
We create a pod using the command line, then we check if there is a corresponding secret that kubernetes might have created for it:
The token file in the "servicceaccount" directory that lives inside the container holds the information about the token of the default service account.
Remark:
If no service account is mentioned in the pod's configuration file, none is created.
The pod will use the generic default service account to communicate with the other components of the cluster.
Below is the default service account:
We create a new service account using the below command:
We then check if it was created:
We could look deeper into the newly created service account by using the below command:
To check the secrets created for the new service account, we could use the below command:
We notice that there is a secret for each of the service account. A secret is generated when a service account is created.
As opposed to the pod created above, we are going to assign to our new pod the service account "serviceaccount1":
We then create our pod using the following command:
We check if our pod is using the service account we have assigned to it:
The "serviceaccount_pod" pod makes use of the its service account instead of the default service account.
The token is made available to the pod by mounting it in the "/var/run/secrets/kubernetes.io/serviceaccount" mountpoint in the pod.
Remark:
To give permissions to a service account that go beyond its default abilities, we need to associate it with a ClusterRole object - defines what a service account can do - through another kubernetes resource named ClusterRoleBinding.
Comments