DEV Community: prokshita nagarajan

Create a Kubernetes service account and assign permissions

prokshita nagarajan — Mon, 13 Jul 2026 07:26:50 +0000

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.

What is a ServiceAccount?

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:

Read Pods
Create Jobs
Access ConfigMaps and Secrets
Watch Deployments
Integrate with cloud identity providers (Azure Workload Identity, AWS IAM Roles for Service Accounts, OCI Workload Identity)

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

Default ServiceAccount

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.

Creating a 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

Using a ServiceAccount in a Pod or Deployment

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.

A ServiceAccount Has No Permissions by Default

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

Permissions are assigned using RBAC:

Role + RoleBinding → Namespace-scoped permissions
ClusterRole + ClusterRoleBinding → Cluster-wide permissions

Creating a Role

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

Binding the Role to the ServiceAccount

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:

Get Pods
List Pods
Watch Pods
Get Services
List Services
Watch Services
Get Endpoints
List Endpoints
Watch Endpoints

Nothing more.

Verifying the Role

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

Why This Matters

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

Using ServiceAccounts together with RBAC enables you to:

Grant only the permissions an application requires
Reduce the impact of compromised workloads
Improve Kubernetes security
Follow the Principle of Least Privilege
Support secure authentication for tools such as the Agentic CLI running in AKS cluster mode

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

Deploying a Single-Node Kubernetes Cluster on AWS EC2 with K3s

prokshita nagarajan — Sun, 21 Jun 2026 13:38:52 +0000

Running a full Kubernetes cluster doesn't always mean spinning up multiple nodes. If you're prototyping, running a small production workload, or just want a lightweight environment to learn on, a single EC2 instance running Kubernetes is more than enough — and a lot cheaper.

In this post, I'll walk through the options for running Kubernetes on a single EC2 instance, why I went with K3s, and exactly how to get a working single-node cluster up in under five minutes.

Options for Running Kubernetes on EC2

Before picking a tool, it's worth knowing what's out there:

1] k3s : Single node, lightweight.
2] MicroK8s : Ubuntu-native, addons built-in.
3] Kubeadm : Full control, standard k8s.
4] Kind/Minikube : Local dev only, not for EC2 prod.

Each has a place. kubeadm gives you the full vanilla Kubernetes experience and is the right call if you're planning to scale to multiple nodes later. MicroK8s is a solid choice if you're already in the Ubuntu/Canonical ecosystem and want snap-based add-ons. Kind and Minikube are built for local development and aren't meant for EC2 production use at all.

Why K3s

Since the goal here was a single EC2 instance running a working cluster, K3s was the clear choice:

Single command install — literally one line, no multi-step bootstrap process
Half the memory footprint of full Kubernetes, so it runs comfortably on smaller instances
Production-grade — it's not a toy; K3s is used widely in real-world deployments, including edge and IoT environments
Batteries included — containerd, Flannel (CNI), Traefik (ingress), and CoreDNS all ship built-in, so there's nothing extra to install
100% kubectl compatible — every kubectl command, every manifest, every Helm chart works exactly the same as it would on a "real" cluster

Prerequisites

An AWS account
An EC2 instance with:
- AMI: Ubuntu 22.04 LTS
- Instance type: t3.medium (2 vCPU, 4GB RAM)
- Storage: 20GB gp3

Step 1: Install K3s

SSH into your EC2 instance and run:

curl -sfL https://get.k3s.io | sh -

That's the entire installation. Behind the scenes, this single command:

Installs containerd as the container runtime
Installs the control plane components (API server, controller manager, scheduler)
Installs Flannel for pod networking
Installs Traefik as the ingress controller
Installs CoreDNS for cluster DNS
Configures the node to act as both control plane and worker, since this is a single-node setup
Registers itself as a systemd service, so it survives reboots

Step 2: Verify the Cluster

Check that the node is up and ready:

sudo kubectl get nodes

You should see a single node in Ready state:

NAME              STATUS   ROLES                  AGE   VERSION
ip-172-31-x-x     Ready    control-plane,master   1m    v1.29.x+k3s1

That's it — you now have a fully functional, kubectl-compatible Kubernetes cluster running on a single EC2 instance, ready to take workloads.

What's Next

From here, the cluster behaves like any other Kubernetes cluster: deploy with manifests, expose services via Traefik ingress, install Helm charts, or wire it into a CI/CD pipeline to pull and run container images from a registry like ECR.

K3s strips away the operational overhead of running Kubernetes without compromising on compatibility — making it the simplest way to get a real cluster running on a single EC2 instance.