Service Account

Concept and Usage of Service Account

ℹ️

We can create a new user using service account mechanism in Kubernetes.

Service account is a non-human account that is used by processes/application running inside a pod to interact with the Kubernetes API server. It provides an identity for processes that run in a Pod. When you create a Pod, if you do not specify a service account, it is automatically assigned the default service account in the same namespace.

Description	ServiceAccount	User or group
Location	Kubernetes API (ServiceAccount object)	External
Access control	Kubernetes RBAC or other authorization mechanisms	Kubernetes RBAC or other identity and access management mechanisms
Intended use	Workloads, automation, Third-party application	People

For example, assuming you have an application that needs to pull data like pods, services, etc by making API calls to the Kubernetes API server and display it on the UI. When the application needs to make API calls to the Kubernetes API server, it needs to authenticate itself. This is where service accounts come into the picture.

Additional info:

Every namespace will auto create a default service account.
By default, when you create a pod, it will use the default service account of the namespace and mount the service account token as a volume in the pod at the path /var/run/secrets/kubernetes.io/serviceaccount.
- When you kubectl exec -it <pod-name> -- ls /var/run/secrets/kubernetes.io/serviceaccount you will see the token, ca.crt, and namespace files.
- If you don't want the Kubernetes auto mount the service account token, you can set automountServiceAccountToken to false in the pod spec.
  pod.yaml
```
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu
  automountServiceAccountToken: false
```
The default service account has limited permissions and it only use to run basic Kubernetes API queries.
When you want to change or edit the existing pod service account, you must delete the pod and recreate it, but for deployment case, you can just edit the deployment, as it will auto trigger a new rollout.

Step 1: Create Service Account

Imperative way

kubectl create serviceaccount <name-of-service-account>
kubectl create serviceaccount data-sa

Declarative way

data-sa.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: data-sa

Get the service account list

kubectl get serviceaccounts

Step 2: Generate Token for Service Account

This token is used by the application to authenticate itself with the Kubernetes API server. Now, when you create token, it is important to set the time to live (TTL) for the token. By default, the token will be valid for 1 hour.

kubectl create token <name-of-service-account>
kubectl create token data-sa
kubectl create token data-sa --duration=30m

Step 3: Use Service Account in Pod or make API calls

You can use curl and provide the token as a bearer token to make API calls. Besides, you can also mount the service account token as a volume in the pod if you want the make API calls from the pod.

curl https://<kube-apiserver>:6443/api --header "Authorization: Bearer <token>"

pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu
  serviceAccountName: data-sa

Let's say you want to make API calls from the pod, you need to provide the token in the header, but when you setup serviceAccountName in the pod spec, you don't need to provide the token in the header anymore as it will auto mount the token as a volume in the pod, which can auto authenticate the pod to the kube-apiserver.

Manually creating a long-lived API token for a service account

Reference (opens in a new tab)

If you want to create a long-lived (non-expiring) token for a service account, you have to create a secret and associate it with the service account.

Step 1: Create a service account

data-sa.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: data-sa

This method will not populate the secrets field in the service account object, as the secrets field is only populated with auto-generated secrets.

data-sa.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: data-sa
secrets:
  - name: data-sa-secret

This method will populate the secrets field in the service account object.

Step 2: Associate the secret with the service account

data-sa-secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: data-sa-secret
  annotations:
    kubernetes.io/service-account.name: data-sa # service account name
type: kubernetes.io/service-account-token

Step 3: View the secret

kubectl get secret/data-sa-secret -o jsonpath='{.data.token}' | base64 -d

Security Context Transport Layer Security (TLS)