Create a Kubernetes service account and assign permissions

A developer explains how to create a Kubernetes ServiceAccount and assign permissions using RBAC to follow the principle of least privilege. The guide covers creating a ServiceAccount, defining a Role for read-only access, and binding it via a RoleBinding. Properly configured ServiceAccounts are essential for security in production Kubernetes environments.

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.