Working with Service Account In Kubernetes
How to configure a service account in Kubernetes and manage it?
What Is Service Account in Kubernetes?
There are two types of account in Kubernetes
- User Account: It is used to allow us, humans, to access the given Kubernetes cluster. Any user needs to get authenticated by the API server to do so. A user account can be an admin or a developer who is trying to access the cluster level resources.
- Service Account: It is used to authenticate machine level processes to get access to our Kubernetes cluster. The API server is responsible for such authentication to the processes running in the pod
Service Account :
In the Kubernetes cluster, any processes or applications in the container which resides within the pod can access the cluster by getting authenticated by the API server, using a service account.
For Example:
An application like Prometheus accessing the cluster to monitor it is a type of service account
So,
A service account is an identity that is attached to the processes running within a pod.
Note!
When you create a pod, if you do not specify a service account, it is automatically assigned the
defaultservice account in the same namespace.
How Does Kubernetes Service Account Works?
Case 1: When you have an external application trying to access Kubernetes cluster API servers.
Suppose there is a web page: My Web Page which has a list of items to be displayed, this data needs to be fetched from an API server hosted in the Kubernetes cluster as shown above in the figure. To do so, we need to a service account that will be enabled by cluster API servers to authenticate and access the data from the cluster servers.
Install minikube and kubectl CLI : If not done yet
Before you begin: You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not have minikube installed visit here: Minikube,
or you can use one of these Kubernetes playgrounds by clicking the given link below:
Creating a service account:
Now to access the kubernetes cluster as discussed above we need to create a service account, which we can do by using the following command :
This command will generate a service account with the name: my-webpage-sa
When you are done creating a service account, a service account token also gets generated, this token is what will be required by our My Web Page application to access the data via apis.
Let’s see how you can view the token and other attached details with the created service account.
Describing the service account:
you have to type the following kubectl command:
Output of the above describe command:
So if you carefully watch the output you will see that the Tokens attribute is created with the value: my-webpage-sa-token-zngkh. This token is stored as a secret object, this secret object is attached to the service account:my-webpage-sa.
To view the secret object :
If you want to view whats the content of the secrte object we can type the following command
$ kubectl describe secret <token-value>
as shown below :
output:
when you execute the above command, you can view the encoded hash-key value of the token as highlighted in the image above.
This is the key that can be exchanged as an authentication bearer token in your REST API call, to fetch the required data from the Kubernetes cluster API server.
Summary:
To summarize :
- We need to first create a service account
- Then based on RBAC:(Role-based authentication control) we need to extract and export the token hash key be passed in our REST API header. This will allow access to the cluster API server as an authenticated service account.
But what if our application is an integral part of the cluster itself and lies into one of the PODs
Case 2: When the application is hosted and running within the Cluster POD
In this scenario, when any pod is created in the Kubernetes cluster with any given namespace, these pods by default creates a service account with the name default. The default service account automatically creates the service token along with the required secret object.
So our application will be able to access the API server lying within the same namespace, by using this default service account mounted in the pod.
For instance, type the below-given command on your terminal:
-$ kubectl get serviceaccount
you will see the default secret as highlighted above, and if you go further to type the below set of commands to access the default secret attached with the default token
you will be able to get the name of default token value, default-token-7k7zj(note this will vary in your case ), this automatically gets created when any pod is created in the given node namespace,
To view the secret object detail against the default token,default-token-7k7z:
Type the following command:
- $ kubectl describe secret default-token-7k7zj
So for our application hosted in the pod with the same namespace, this default secret object can be used to give access to the API servers lying in the same cluster namespace.
What’s Next?
We will get into the depth of service account and default tokens more in the next piece where we will discuss
- Limitation of the default service account
- How to modify this default service account and make it more tailor-made for custom use
- What is a user account in Kubernetes and how it works?
