Create a Kubernetes service account and assign permissions

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.