Kubernetes 101: Service Account

Introduction

Service accounts in Kubernetes are meant to provide an identity for processes that run in a Pod. While user accounts are designed for humans, service accounts cater to processes, like those inside your Pods.

In essence, service accounts authenticate the application or service running in a Pod instead of a user. They are automatically assigned with a secret, which contains the credentials needed to authenticate with the Kubernetes API. This secret is automatically created and attached to the service account upon its creation.

The Role of Service Account

Service accounts play pivotal roles in real-world Kubernetes scenarios. For instance, suppose a Pod needs to interact with the Kubernetes API to fetch details about other resources in the same namespace or cluster. In that case, it needs an identity—this is where a service account comes in.

To illustrate, let's consider a Deployment running multiple Pods that interact with the Kubernetes API. Here, instead of granting permissions to each Pod, you can create a service account with the necessary permissions and attach it to the Deployment. Then all the Pods under this Deployment will inherit this service account, effectively having the permissions to interact with the Kubernetes API.

A service account in Kubernetes provides an identity for processes that run in a pod. Its primary role is to authenticate and authorize processes running in pods to interact with the Kubernetes API, and it forms an integral part of the Kubernetes RBAC (Role-Based Access Control) system.

Below are some of the key roles of a service account in Kubernetes:

1. Authentication of Processes in Pods: Service accounts are used to authenticate the processes running in pods to the Kubernetes API server. When a service account is created, Kubernetes automatically creates a secret containing a token that can be used to authenticate requests to the Kubernetes API server. This token is automatically mounted on the pods that are associated with the service account.
2. Authorization for Access to Resources: Service accounts are used to authorize actions on Kubernetes resources. By using RoleBinding or ClusterRoleBinding, you can bind a service account to a Role or a ClusterRole, which defines a set of permissions. The service account can then be used by processes running in pods to perform authorized actions on the Kubernetes API server.
3. Isolation Between Namespaces: Service accounts reside in namespaces, providing a scope for permissions and a way to segregate access to resources in different namespaces. A service account in one namespace cannot access resources in another namespace unless appropriate ClusterRoles and ClusterRoleBindings are set up.
4. Automating Processes Within Pods: Many automated processes within Kubernetes, such as accessing the Kubernetes API from within a pod, reading ConfigMaps, or controlling other pods, are done using service accounts. Kubernetes system processes like the kube-controller-manager and the kube-scheduler run under service accounts.
5. Integration with Cloud IAMs: Some cloud providers offer the ability to link Kubernetes service accounts with cloud IAM (Identity and Access Management) roles. This allows Kubernetes pods to use the associated IAM role to authenticate and interact with cloud services.

Service Account and RBAC

RBAC is a method of regulating access to computer or network resources based on the roles of individual users within your organization. In Kubernetes, RBAC is used to control who (which users or service accounts) can perform actions (like: get, list, create, update, delete) on which resources (like: pods, services, nodes).

RBAC uses the rbac.authorization.k8s.io API group to drive authorization decisions, allowing admins to dynamically configure policies through the Kubernetes API.

Here's how service accounts relate to RBAC:

1. Roles and ClusterRoles
   These are a set of permissions that represent a logical group of API operations on a set of resources. A Role is a set of permissions within a namespace, while a ClusterRole is a cluster-wide version that can also grant access to cluster-scoped resources (like nodes) and non-resource endpoints (like /healthz).
2. RoleBindings and ClusterRoleBindings
   These are used to grant the permissions defined in a role to a user or a set of users. They can also be used to grant permissions to service accounts. A RoleBinding grants the permissions defined in a role to a user or a set of users within a specific namespace. A ClusterRoleBinding is a cluster-wide version of a RoleBinding. It grants global permissions across all namespaces.

When a service account is created, it doesn't have any permissions by default. You must explicitly bind the service account to a Role or ClusterRole using a RoleBinding or ClusterRoleBinding.

For example, if you have a service account named my-service-account in a namespace called my-namespace, and you want to grant it permissions to get, watch, and list pods in the same namespace, you would first create a Role with these permissions and then create a RoleBinding that assigns this Role to my-service-account.

This system allows for fine-grained access control, ensuring that service accounts have just enough permissions to perform their intended tasks, but no more. This aligns with the principle of least privilege, an important security best practice. By using RBAC with service accounts, you can limit the potential damage done if a service account's credentials are ever exposed.

Example of Service Account Manifest

Here's an example manifest that includes a ServiceAccount, Role, and a RoleBinding in Kubernetes. We will create a ServiceAccount called example-serviceaccount, a Role that can read Pods in the namespace default, and a RoleBinding that binds the two together.

Breakdown of the manifest:

1. ServiceAccount: This defines a new service account named example-serviceaccount in the default namespace. The kind: ServiceAccount and apiVersion: v1 denote that we're creating a service account object.
2. Role: Next, we define a Role named pod-reader in the default namespace. This Role has permissions to "get", "watch", and "list" Pods (resources: ["pods"]) within the default namespace. The apiGroups: [""] section refers to the apiGroup that the Pods resource belongs to, which is the core API group.
3. RoleBinding: Finally, we create a RoleBinding called read-pods that assigns our example-serviceaccount to the pod-reader Role we just created. The roleRef field refers to the Role that we're binding to, and the subjects field lists the users, groups, or service accounts that the RoleBinding should apply to. In our case, the subject is the example-serviceaccount.

When you apply this manifest using kubectl apply -f filename.yaml, the example-serviceaccount will have the ability to read Pods (i.e., get, watch, and list) within the default namespace.

This example shows how RBAC and ServiceAccounts are connected in Kubernetes. Through the use of a RoleBinding, a ServiceAccount is assigned a Role, which defines the permissions the ServiceAccount has when interacting with the Kubernetes API server.

About 8grams

We are a small DevOps Consulting Firm that has a mission to empower businesses with modern DevOps practices and technologies, enabling them to achieve digital transformation, improve efficiency, and drive growth.

Ready to transform your IT Operations and Software Development processes? Let's join forces and create innovative solutions that drive your business forward.

Subscribe to our newsletter for cutting-edge DevOps practices, tips, and insights delivered straight to your inbox!