Understanding Kubernetes Service Account— A Beginner’s Guide

How to work with Service Account ? From Authentication to Authorization

Find Complete mind map of A Beginner’s Guide to Kubernetes

Welcome back to our ongoing journey into Kubernetes!

In our previous articles, we explored the concepts of authentication, authorization, and RBAC. Building upon these foundations, we now turn our attention to another essential aspect of Kubernetes: service accounts.

In this guide, we will dive into service accounts, understanding what they are, how they relate to authentication, and how they enable authorization within the cluster.

So, let’s dive in !

Check out “Understanding Kubernetes — A Beginner’s Guide” for the comprehensive series🚀

What are Service Accounts?

Firstly, let’s explore the concept of service accounts in Kubernetes.

Service accounts are a type of user account specifically designed for applications and services running within the cluster.

What does it mean?

Unlike regular user accounts(as we created in this article), which are meant for human users, service accounts are created and used by Kubernetes itself to manage communication between various components/resources.

They play a crucial role in enabling secure communication and authenticating the identity of applications and services within the cluster.

Types of Users in Kubernetes

In a Kubernetes cluster, there are two main categories of users:

• Service Accounts: These are user accounts managed by Kubernetes itself and are primarily used by applications and services running within the cluster. They are specifically designed for automated processes, such as pods, to connect to the Kubernetes API server.
• Normal Users: Normal users are human users who interact with the Kubernetes cluster using tools like kubectl. These users authenticate themselves using various authentication mechanisms, such as username and password, client certificates, or external identity providers.(as we practiced in kubeconfig article)

The key difference between service accounts and normal users is their purpose and management.

Service accounts are created and managed by Kubernetes, while normal users are external entities granted access to the cluster.

Service accounts are used for internal communication and authentication between components, while normal users interact with the cluster for administrative or operational tasks.

Creating and Using Service Accounts

Let’s dive into the practical aspects of creating and using service accounts in Kubernetes.

In this section, we will walk through the process of creating a service account, associating it with a specific namespace, and granting appropriate permissions using Role-Based Access Control (RBAC).

By the end, you’ll have a solid understanding of how service accounts can be used to ensure secure communication within your Kubernetes environment.

Creating a Service Account

To create a service account, we can use the kubectl create serviceaccount command:

$ kubectl create serviceaccount my-serviceaccount -n my-namespace

This command will create a service account with the name my-serviceaccount in the my-namespace namespace.

Associating a Service Account with a Namespace using RBAC

To associate the service account with a specific namespace and grant it appropriate permissions, we will create a role and a role binding.

You can get a recap on RBAC in our previous article in case you need it!

First, let’s create a role that defines the permissions for the service account:

$ kubectl create role my-role --verb=get,list --resource=pods -n my-namespace

This command creates a role named my-role in the my-namespace namespace. It grants the get and list permissions for the pods resource.

Next, we can create a role binding to associate the role with the service account:

$ kubectl create rolebinding my-rolebinding --role=my-role --serviceaccount=my-namespace:my-serviceaccount -n my-namespace

In this example, we create a role binding named my-rolebinding that associates the my-serviceaccount service account with the my-namespace namespace. The role binding grants the my-role role to the service account, enabling it to access pods within the namespace.

Using Service Accounts for Authentication

One of the key benefits of service accounts in Kubernetes is their ability to provide authentication for applications running within the cluster.

Service accounts are associated with a specific namespace and come with a unique token that can be used for authentication.

To validate the usage of a service account, we can examine a few scenarios. Let’s take a closer look at how service accounts enable authentication within the cluster.

Checking Mount Path

When a pod is associated with a service account, the service account’s token is mounted as a volume within the pod.

This token can be used by the application running inside the pod to authenticate itself when making requests to the Kubernetes API server.

In the YAML output, you will find a section similar to the following:

...
spec:
  containers:
  - name: my-app
    ...
  serviceAccountName: my-serviceaccount
  automountServiceAccountToken: true
...

The serviceAccountName field specifies the name of the associated service account, and automountServiceAccountToken indicates whether the token should be automatically mounted.

Executing Commands in a Pod

To demonstrate the authentication capabilities of service accounts, we can enter a pod and execute commands using the service account’s token.

This allows us to interact with the Kubernetes cluster using the service account’s identity.

First, let's enter the pod using the following command:

$ kubectl exec -it <pod-name> - /bin/sh

Once inside the pod, we can run commands using the kubectl tool, leveraging the service account's token for authentication.

Verifying Service Account Authorization

To verify that the authorization is indeed based on the service account and its rolebinding, we can run the following command inside the pod:

$ kubectl auth can-i list pods --as=system:serviceaccount:<namespace>:<serviceaccount-name>

Replace <namespace> and <serviceaccount-name> with the appropriate values for your service account. If the output is "yes", it confirms that the service account has the necessary permissions to list pods.

These examples highlight how service accounts provide authentication capabilities within Kubernetes. By associating a service account with a pod and leveraging its token, applications and services can securely authenticate themselves when interacting with the cluster based on RBAC.

Key Takeaway

Here are the key takeaways from our discussion:

• Service accounts are one type of user accounts specifically designed for applications and services within the cluster.
• They are managed by Kubernetes and used for internal communication between cluster components.
• Service accounts have associated tokens for authentication, mounted as volumes within pods.
• Service accounts can be associated with specific namespaces for fine-grained access control.
• Verifying mount paths and executing commands with service account tokens validate authentication capabilities.

By far, we have covered the important topic of Kubernetes security, exploring concepts such as authentication, authorization, kubeconfig file, and service accounts. By understanding these concepts, you can strengthen the security of your Kubernetes clusters and protect your valuable resources.

This concludes our series on Kubernetes Security for now.

In our next topic, we will dive into the exciting realm of maintaining Kubernetes clusters, where we will explore cluster upgrades, backup, monitoring, and troubleshooting techniques.

Stay tuned for more valuable insights and practical tips to effectively manage and maintain your Kubernetes infrastructure!

🔔 Stay tuned or subscribe to my series: “Understanding Kubernetes — A Beginner’s Guide” to explore everything about Kubernetes. 🚀

➕Join the Medium Membership Program to support my work and connect with other writers.

📝 Have questions or suggestions? Leave a comment or message me through Medium. Let’s connect!

Thank you for your support! 🌟