# Create a Kubernetes service account and assign permissions

> Source: <https://dev.to/prokshita_nagarajan_16a4d/create-a-kubernetes-service-account-and-assign-permissions-69p>
> Published: 2026-07-13 07:26:50+00:00

When deploying applications to Kubernetes, it's important to ensure they have only the permissions they actually need. This is where **ServiceAccounts** and **RBAC (Role-Based Access Control)** come into play.

In our case, the **ServiceAccount is required for the Agentic CLI to authenticate with the AKS cluster when running in cluster mode.**

A **ServiceAccount** is an identity used by applications running inside a Kubernetes cluster. Unlike user accounts, which are intended for administrators and developers, ServiceAccounts allow pods to securely authenticate with the Kubernetes API.

Applications commonly use a ServiceAccount to:

Rather than granting broad cluster-wide permissions, Kubernetes lets you assign only the permissions an application requires, following the **Principle of Least Privilege**.

Every Kubernetes namespace includes a default ServiceAccount.

```
kubectl get sa
```

Example output:

```
NAME      SECRETS   AGE
default   0         10d
```

If no ServiceAccount is specified in a Pod or Deployment, Kubernetes automatically uses the `default`

ServiceAccount.

Create a file named `serviceaccount.yaml`

:

```
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: alpha
```

Apply it:

```
kubectl apply -f serviceaccount.yaml
```

Verify it exists:

```
kubectl get sa -n alpha
```

Reference the ServiceAccount using the `serviceAccountName`

field.

```
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  serviceAccountName: my-app-sa
  containers:
    - name: nginx
      image: nginx
```

Any pod using this ServiceAccount will authenticate to the Kubernetes API as `my-app-sa`

.

Creating a ServiceAccount **does not automatically grant access** to Kubernetes resources.

Permissions are assigned using **RBAC**:

The following Role allows read-only access to Pods, Services, and Endpoints.

```
kind: Role
apiVersion: rbac.authorization.k8s.io/v1

metadata:
  namespace: dev
  name: endpoints-reader

rules:
- apiGroups: [""]
  resources:
    - pods
    - services
    - endpoints
  verbs:
    - get
    - list
    - watch
```

Next, bind the Role to the ServiceAccount.

```
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1

metadata:
  name: read-access
  namespace: dev

subjects:
- kind: ServiceAccount
  name: my-app-sa
  namespace: dev

roleRef:
  kind: Role
  name: endpoints-reader
  apiGroup: rbac.authorization.k8s.io
```

After applying the Role and RoleBinding, the ServiceAccount can:

Nothing more.

Describe the Role to verify its permissions.

```
kubectl describe role endpoints-reader -n test-magik
```

Example output:

```
Name:         endpoints-reader
PolicyRule:
  Resources   Verbs
  ---------   ----------------
  endpoints   get, list, watch
  pods        get, list, watch
  services    get, list, watch
```

You can also verify what a ServiceAccount is allowed to do:

```
kubectl auth can-i list pods \
  --as=system:serviceaccount:dev:my-app-sa \
  -n dev
```

If configured correctly, Kubernetes will return:

```
yes
```

Giving every application cluster-admin privileges is a significant security risk.

Using **ServiceAccounts** together with **RBAC** enables you to:

Properly configured ServiceAccounts are a foundational security practice for any production Kubernetes environment.