Service Accounts

There are two types of accounts in Kubernetes:
1. User accounts → used by humans (admins, developers).
2. Service accounts → used by applications/machines.
When an application talks to the Kubernetes API, it needs to be authenticated. This is done by using a service account.

Kubernetes automatically creates a token (used for authentication) and stores it as a secret object. (Deprecated)
Every namespace has a default service account.
If you don’t specify a service account in the pod spec, the default one is used.
To avoid automatic token mount in spec section, use below field:
```
automountServiceAccountToken: false
```
Kubernetes mounts the token (default serviceaccount) into the pod
The token is in /var/run/secrets/kubernetes.io/serviceaccount

Limitations of Default Account

It has very limited permissions.
To use a custom service account specify it in the pod spec
```
serviceAccountName: <name>
```

Older tokens:
- Had no expiry and and were not audience-bound and were stored in a secret per service account.
- Posed security and scalability issues.
Kubernetes added a TokenRequest API:
- Generates time-bound, audience-bound, object-bound tokens
- Token is created on-the-fly and mounted as a projected volume, not stored in a secret.

You can manually create a secret like this:

kind: Secret
type: kubernetes.io/service-account-token
metadata:
  annotations:
    kubernetes.io/service-account.name: <name>

But it’s not recommended unless absolutely necessary as these tokens are non-expiring, which poses a security risk.

kubectl create sa <name>

kubectl get sa

kubectl describe secret <name>

kubectl create token <service-account-name>