Repository files navigation

AService Account in Kubernetes is a special type of account that is used by processes or applications running insidePods to authenticate and interact with the Kubernetes API. UnlikeUser Accounts, which are typically associated with human users,Service Accounts are designed for non-human access. They are used to grant specific permissions to applications, allowing them to interact with the Kubernetes cluster in a controlled and secure way.

Service accounts provide a mechanism for grantingRBAC (Role-Based Access Control) permissions to Pods and workloads. Each service account has a set ofcredentials (a token) that is automatically generated by Kubernetes. This token is mounted into the container running inside a Pod, which allows the application to authenticate itself against the Kubernetes API.

Through the service account, Kubernetes manages theaccess control for specific resources (such as Pods, Services, ConfigMaps, etc.), based on theRole orClusterRole associated with the account. These roles define what actions the service account can perform on different resources within the cluster.

In essence, aService Account acts as an identity for the applications or workloads running inside your Kubernetes Pods. By linking it with roles and permissions, Kubernetes enables fine-grained access control, ensuring that each service only has access to the resources it needs.

Before starting this tutorial, you should have:

• AKubernetes cluster (either local or on a cloud provider).
• kubectl installed and configured to access the cluster.
• Basic knowledge ofKubernetes Pods andRBAC.

AService Account is an identity for processes running inside Pods. It allows Pods to authenticate and interact with the Kubernetes API.

First, create a file namedservice-account.yaml to define the Service Account:

apiVersion:v1kind:ServiceAccountmetadata:name:print-read-service-accountnamespace:service-account-test

This file defines a service account namedprint-read-service-account in theservice-account-test namespace.

To apply the Service Account to your Kubernetes cluster, run:

kubectl apply -f service-account.yaml

In Kubernetes, aRole defines what resources can be accessed within a specific namespace and what actions can be performed. Here, we'll create a Role that grantsread-only access topods.

Create a file namedrole.yaml with the following content:

apiVersion:rbac.authorization.k8s.io/v1kind:Rolemetadata:name:read-rolenamespace:service-account-testrules: -apiGroups:[""]resources:["pods"]verbs:["get", "list"]

This Role grants permission toget andlistpods in theservice-account-test namespace.

To apply the Role, run:

kubectl apply -f role.yaml

ARoleBinding is used to bind a Role to a specificService Account. This allows the service account to use the permissions defined in the Role.

Create a file namedrole-binding.yaml:

apiVersion:rbac.authorization.k8s.io/v1kind:RoleBindingmetadata:name:read-role-bindingnamespace:service-account-testsubjects:-kind:ServiceAccountname:print-read-service-accountnamespace:service-account-testroleRef:kind:Rolename:read-roleapiGroup:rbac.authorization.k8s.io

This RoleBinding binds theread-role to theprint-read-service-account service account.

To apply the RoleBinding, run:

kubectl apply -f role-binding.yaml

Now, create aPod that uses theprint-read-service-account service account to access Kubernetes resources. This Pod will use thekubectl command to listpods andservices in the cluster.

Create a file namedpod-with-service-account.yaml:

apiVersion:v1kind:Podmetadata:name:pod-with-service-accountnamespace:service-account-testspec:serviceAccountName:print-read-service-accountcontainers:  -name:print-reader-containerimage:bitnami/kubectl:latestcommand:['sh', '-c', 'kubectl get pods && kubectl get services']

This Pod runs a container with thekubectl image. The container executes the commandkubectl get pods && kubectl get services, which will attempt to retrieve both Pods and Services in the cluster.

To apply the Pod, run:

kubectl apply -f pod-with-service-account.yaml

Once the Pod is created, you can check the logs of the Pod to verify that it can readpods andservices.

Run the following command:

kubectl logs pod-with-service-account -n service-account-test

NAME                       READY   STATUS    RESTARTS        AGEpod-with-service-account   1/1     Running   6 (2m48s ago)   5m47sError from server (Forbidden): services is forbidden: User"system:serviceaccount:service-account-test:print-read-service-account" cannot list resource"services"in API group""in the namespace"service-account-test"

In the log above, thekubectl command successfully lists thepods, but it encounters an error when trying to list theservices. The error message indicates that the service accountprint-read-service-account does not have permission to access theservices resource. This is because the Role only grants access topods and notservices.

To fix this, you need to update the Role to grant read access to bothpods andservices.

Edit therole.yaml file to include access toservices:

apiVersion:rbac.authorization.k8s.io/v1kind:Rolemetadata:name:read-rolenamespace:service-account-testrules: -apiGroups:[""]resources:["pods", "services"]verbs:["get", "list"]

Reapply the updated Role:

kubectl apply -f role.yaml

Now, when you check the Pod logs again, you should see bothpods andservices listed.

By default, a KubernetesService Account has access only to resources within the namespace it is created in. This means that theprint-read-service-account in our example can only interact with resources like Pods and Services within theservice-account-test namespace. If you want the service account to have access to resources in other namespaces, you need to use aClusterRole andClusterRoleBinding instead of aRole andRoleBinding. AClusterRole grants access to resources across the entire cluster, and aClusterRoleBinding allows you to bind the ClusterRole to a service account across multiple namespaces or cluster-wide.

In this tutorial, you learned how to:

1. Create aService Account for use by a Kubernetes Pod.
2. Create aRole that grants read-only access to Pods.
3. Bind the Role to the Service Account using aRoleBinding.
4. Deploy a Pod that uses the Service Account to interact with Kubernetes resources.

By following these steps, you can control access to Kubernetes resources securely usingRBAC andService Accounts, ensuring that applications only have access to the resources they need.

• Kubernetes RBAC Documentation
• Kubernetes Service Accounts Documentation