Introduction

Imagine it’s 2:00 AM, and you’re the on-call Platform Engineer responsible for your organization’s production Azure Kubernetes Service (AKS) cluster.

Suddenly, your monitoring dashboard starts flashing critical alerts. Customer-facing applications are still responding, but unusual outbound traffic has been detected from one of your Kubernetes Pods. Within minutes, security teams discover that an attacker has gained access to a compromised container. Worse still, the compromised Pod is communicating with internal services it was never intended to reach.

As your team investigates the incident, the root cause becomes clear. It wasn’t caused by a sophisticated zero-day exploit or an advanced cyberattack. Instead, it was the result of a few simple Kubernetes security misconfigurations that could have been prevented with proper access controls, workload identities, and security policies.

Unfortunately, this scenario is far more common than many engineers realize.

As Kubernetes has become the standard platform for deploying modern cloud-native applications, it has also become one of the most attractive targets for attackers. Organizations are running hundreds or even thousands of workloads inside shared clusters, making security one of the most important responsibilities for every Platform Engineer, DevOps Engineer, Cloud Engineer, and Site Reliability Engineer (SRE).

While Kubernetes provides powerful orchestration capabilities, it does not automatically secure your workloads. By default, applications can often communicate freely, Pods may run with unnecessary permissions, and misconfigured identities can expose sensitive resources to unauthorized users.

Building a secure Kubernetes environment requires much more than simply deploying applications successfully. It requires understanding how Kubernetes authenticates users, authorizes requests, manages permissions, secures application identities, and protects workloads throughout their lifecycle.

In this article, we’ll begin building that foundation.

Rather than memorizing commands, you’ll learn how Kubernetes evaluates every request that reaches the API Server, how identities are verified, how permissions are enforced through Role-Based Access Control (RBAC), and how modern workloads securely access cloud resources using Service Accounts and Workload Identity.

This is Part 1 of the Kubernetes Security series, where we’ll focus on the core security concepts that every Kubernetes engineer should understand before operating production clusters.

Whether you’re preparing for the CKA, CKS, or KCNA certification, working with Azure Kubernetes Service (AKS), Amazon EKS, Google Kubernetes Engine (GKE), or managing your own Kubernetes clusters, the concepts covered in this guide form the security foundation used across every Kubernetes platform.

Let’s begin by understanding why Kubernetes security has become one of the most valuable skills in modern cloud engineering.

Following the Kubernetes Learning Roadmap?
This article is part of my comprehensive Kubernetes learning series designed to take you from Kubernetes fundamentals to advanced platform engineering concepts.

Start here: https://geekymukesh.com/kubernetes-in-2026-the-ultimate-8-week-learning-roadmap/

Roadmap Progress:

✅ Week 1: Core Kubernetes Objects

✅ Week 2: Controllers & Desired State

✅ Week 3: Kubernetes Architecture

✅ Week 4: Container Runtime & CRI (Current Article)

🚀 Week 5: Security & Policy

⏳ Week 6: Observability

⏳ Week 7: Extensibility & Platform Engineering

⏳ Week 8: Webhooks & Advanced Control

What You’ll Learn in This Guide

In this first part of the Kubernetes Security series, we’ll build a strong security foundation by exploring the core mechanisms that protect every Kubernetes cluster.

By the end of this guide, you’ll understand:

✔ Why Kubernetes Security Matters

✔ The Kubernetes Security Model

✔ Authentication and Identity Verification

✔ Authorization and Access Control

✔ Role-Based Access Control (RBAC)

✔ Service Accounts

✔ Workload Identity

Along the way, we’ll build practical examples, configure RBAC from scratch, create dedicated Service Accounts, and understand how enterprise Kubernetes platforms securely manage application identities without exposing sensitive credentials.

More importantly, you’ll learn why these security features exist, how they work internally, and when to use them in real-world production environments.

In Part 2, we’ll continue our journey by securing Kubernetes workloads using Secrets, Pod Security Standards, Security Contexts, Network Policies, Admission Controllers, and enterprise-grade security best practices.

By the end of this guide, readers should be able to answer:

• How does Kubernetes authenticate users?
• How does authorization work?
• What is RBAC?
• How do Service Accounts work?
• How do Pods securely access cloud resources?
• What are Pod Security Standards?
• How do Network Policies secure east-west traffic?
• How do Admission Controllers work?
• How do enterprises secure AKS, EKS, and GKE clusters?

Instead of just deploying applications, readers will learn how to protect production Kubernetes environments.

Chapter 1: Why Kubernetes Security Matters

The Reality of Modern Kubernetes Security

Imagine you’re working as a Platform Engineer for a fast-growing fintech company. Your organization runs hundreds of microservices on Azure Kubernetes Service (AKS). Every day, thousands of customers use your mobile application to transfer money, check balances, and perform online transactions.

One morning, your monitoring system reports unusual outbound traffic from one of your application Pods. Initially, the application appears healthy—there are no crashes, no failed deployments, and CPU usage remains normal. However, a deeper investigation reveals that an attacker gained access through a vulnerable container image. Because the Pod was running with excessive privileges and unrestricted network access, the attacker was able to move laterally across the cluster and access internal services that should never have been exposed.

What started as a single vulnerable container quickly became a cluster-wide security incident.

Unfortunately, scenarios like this are not hypothetical. They happen in production environments across organizations of every size.

This is why Kubernetes security is no longer optional—it is a fundamental responsibility for every DevOps Engineer, Platform Engineer, and Cloud Architect.

---

Why Traditional Security Is No Longer Enough

In traditional data centers, applications typically ran on dedicated virtual machines or physical servers. Security teams focused on protecting the network perimeter using firewalls, VPNs, and access control lists.

Modern cloud-native environments are very different.

A Kubernetes cluster may contain:

• Hundreds of worker nodes
• Thousands of Pods
• Multiple development teams
• Shared infrastructure
• Continuous deployments
• Applications distributed across several namespaces

Instead of protecting one large server, engineers must protect thousands of constantly changing workloads.

Security must therefore move closer to the workload itself.

This concept is commonly referred to as defense in depth, where multiple security layers work together to reduce risk.

---

Why Kubernetes Clusters Become Security Targets

Kubernetes has become the standard platform for running modern applications. As adoption has increased, attackers have also shifted their focus toward Kubernetes environments.

A compromised Kubernetes cluster can provide attackers with:

• Access to sensitive business data
• Customer information
• Cloud credentials
• Internal APIs
• Databases
• Storage accounts
• Compute resources

Some attackers even deploy cryptocurrency mining software inside compromised clusters, consuming CPU resources and dramatically increasing cloud costs.

Others attempt to steal secrets, API keys, or service account tokens that can be used to access additional cloud resources.

Because Kubernetes often sits at the center of an organization’s infrastructure, securing the cluster is critical to protecting the entire platform.

---

Common Kubernetes Security Risks

Several security issues appear repeatedly in production environments.

Privileged Containers

Running a container with privileged access effectively removes many of the isolation boundaries provided by Kubernetes.

A privileged container may gain direct access to the host operating system, increasing the risk of privilege escalation.

---

Overly Permissive RBAC

Many organizations grant developers the cluster-admin role because it is quick and convenient.

Although this simplifies development, it violates the principle of least privilege.

If a developer account is compromised, an attacker may gain complete control of the cluster.

---

Exposed Secrets

Application passwords, API keys, and certificates should never be stored inside application code or ConfigMaps.

Improper secret management can expose sensitive credentials to anyone with access to the cluster.

---

Unrestricted Network Communication

By default, most Kubernetes clusters allow every Pod to communicate with every other Pod.

Without Network Policies, a compromised application can move laterally throughout the cluster.

---

Vulnerable Container Images

Applications often inherit vulnerabilities from their base images.

Using outdated images or untrusted public repositories significantly increases security risk.

Regular image scanning and trusted registries are essential in production.

---

The Shared Responsibility Model

Securing Kubernetes is not the responsibility of a single person or team.

Instead, it is a shared responsibility across multiple roles.

Team	Responsibility
Cloud Provider	Physical infrastructure, managed control plane, networking foundation
Platform Engineering	Cluster configuration, RBAC, policies, upgrades
Security Team	Governance, compliance, monitoring, audits
Developers	Secure application code, image quality, dependency management
DevOps Engineers	CI/CD security, secret management, deployment pipelines

When these teams work together, Kubernetes becomes significantly more secure.

---

Security Is More Than Preventing Attacks

Many engineers think Kubernetes security is simply about stopping hackers.

In reality, security also improves:

• Platform reliability
• Regulatory compliance
• Operational stability
• Auditability
• Customer trust

A secure cluster is easier to manage, easier to troubleshoot, and far less likely to experience major production incidents.

---

Throughout this article, we will build a complete understanding of Kubernetes security.

By the end, you will learn how to:

• Authenticate users securely
• Authorize access using RBAC
• Protect workloads with Service Accounts
• Store sensitive information safely
• Restrict network communication
• Enforce Pod Security Standards
• Validate deployments using Admission Controllers
• Apply enterprise-grade security best practices

Rather than memorizing commands, you’ll understand how every security component fits into the overall Kubernetes architecture.

Let’s begin by understanding the complete Kubernetes security model.

---

Chapter 2: Understanding the Kubernetes Security Model

Security Starts Before a Request Reaches Kubernetes

Many engineers assume security begins when a Pod is deployed.

In reality, security begins much earlier.

Every request sent to a Kubernetes cluster follows a strict security pipeline before Kubernetes allows any action to occur.

Whether you create a Deployment, read a Secret, or delete a Pod, Kubernetes evaluates multiple security layers before processing the request.

If any one of these layers rejects the request, the operation immediately stops.

This layered design ensures that only authenticated and authorized users can perform actions inside the cluster.

---

The Kubernetes Security Pipeline

Every API request follows a predictable sequence.

User / Application
        │
        ▼
Authentication
        │
        ▼
Authorization
        │
        ▼
Admission Controllers
        │
        ▼
API Server
        │
        ▼
etcd
        │
        ▼
Worker Nodes

Think of this pipeline as the security checkpoint at an international airport.

Before a passenger boards an aircraft, they must successfully pass multiple verification stages.

Similarly, every Kubernetes request must successfully pass each security checkpoint before it reaches the cluster.

---

Stage 1 – Authentication: Who Are You?

The first question Kubernetes asks is:

Who is making this request?

Authentication verifies the identity of the caller.

Kubernetes supports several authentication methods, including:

• Client Certificates
• Bearer Tokens
• Service Account Tokens
• OpenID Connect (OIDC)
• Cloud Identity Providers such as Microsoft Entra ID, AWS IAM, and Google Identity

If Kubernetes cannot verify the user’s identity, the request is rejected immediately.

Authentication answers only one question:

Who are you?

It does not determine what actions you are allowed to perform.

That responsibility belongs to the next stage.

---

Stage 2 – Authorization: What Are You Allowed to Do?

Once a user’s identity has been verified, Kubernetes evaluates their permissions.

This process is known as authorization.

Authorization determines whether the authenticated user has permission to perform the requested operation.

For example:

• Can this user create Pods?
• Can they read Secrets?
• Can they delete Deployments?
• Can they modify ClusterRoles?

If the answer is no, Kubernetes immediately blocks the request.

The most common authorization mechanism is Role-Based Access Control (RBAC), which we’ll explore in detail later in this guide.

---

Stage 3 – Admission Controllers: Should Kubernetes Accept This Object?

Even if a user is authenticated and authorized, Kubernetes still performs one final validation step.

Admission Controllers inspect the resource itself.

They can:

• Reject insecure configurations
• Automatically modify objects
• Enforce organizational policies

For example, an Admission Controller can prevent a Pod from running as the root user or block deployments using privileged containers.

This provides an additional layer of protection before workloads enter the cluster.

---

Why This Layered Model Matters

Imagine a developer accidentally deploys a privileged Pod.

The request might:

1. Pass authentication because the developer is a valid user.
2. Pass authorization because the developer has permission to create Pods.
3. Fail at the Admission Controller because privileged containers violate your organization’s security policy.

This layered approach prevents a single mistake from becoming a production security incident.

In the following chapters, we’ll explore each of these security mechanisms in depth and learn how to implement them in real Kubernetes environments.

Chapter 3: Kubernetes Authentication – Verifying Identity Before Access

What Is Authentication?

Every secure system must answer one fundamental question before granting access:

“Who are you?”

This process is known as authentication.

Authentication is the first security checkpoint in Kubernetes. Before the API Server processes any request, it must verify the identity of the caller. Whether the request comes from a developer using kubectl, a CI/CD pipeline, another application inside the cluster, or an automated controller, Kubernetes first validates the identity before doing anything else.

If authentication fails, Kubernetes immediately rejects the request with an Unauthorized (401) error.

Authentication only verifies identity. It does not determine what actions the user can perform. That responsibility belongs to the authorization layer, which we will discuss in the next chapter.

---

Why Authentication Is Important

Imagine your company runs a production Kubernetes cluster hosting online banking applications.

Without authentication:

• Anyone could create Pods.
• Anyone could delete Deployments.
• Anyone could access Secrets.
• Anyone could modify production workloads.

Clearly, this would be catastrophic.

Authentication ensures that every request entering the Kubernetes API Server has a verified identity.

It is the first line of defense that protects the cluster from unauthorized access.

---

How Authentication Works

Every request sent to Kubernetes follows a simple workflow.

User / Application
        │
        ▼
kubectl
        │
        ▼
API Server
        │
        ▼
Authentication
        │
 ┌──────┴──────┐
 │             │
Valid       Invalid
 │             │
 ▼             ▼
Continue     Reject (401 Unauthorized)

For example, when you execute:

kubectl get pods

the following happens internally:

1. kubectl sends the request to the API Server.
2. The API Server extracts the credentials.
3. Kubernetes validates the credentials.
4. If successful, the user identity is established.
5. The request moves to the authorization stage.

Only after authentication succeeds does Kubernetes check permissions.

---

Authentication Methods Supported by Kubernetes

Kubernetes supports multiple authentication mechanisms because different environments have different requirements.

Client Certificates

Client certificates are commonly used by cluster administrators.

Each user receives a certificate signed by the Kubernetes Certificate Authority (CA).

When a request reaches the API Server:

• The certificate is validated.
• The signature is checked.
• The user identity is extracted.

Advantages:

• Strong security
• Mutual TLS
• Common in self-managed clusters

Limitations:

• Difficult to manage at scale
• Certificate rotation required

---

Bearer Tokens

Bearer tokens are one of the most common authentication methods.

Instead of presenting a certificate, the client sends a token with each request.

Example:

Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

The API Server validates the token and identifies the user.

Bearer tokens are widely used by:

• Applications
• CI/CD pipelines
• Service Accounts
• Automation tools

---

Service Account Tokens

Pods also need to communicate with the Kubernetes API.

For example:

• Operators
• Controllers
• Monitoring tools
• GitOps agents

Instead of using user credentials, Kubernetes provides Service Accounts.

Every Pod can automatically receive a Service Account token that allows it to authenticate securely.

Later in this guide, we’ll learn how to create custom Service Accounts and assign least-privilege permissions.

---

OpenID Connect (OIDC)

Large enterprises rarely manage Kubernetes users manually.

Instead, they integrate Kubernetes with an enterprise identity provider using OpenID Connect.

Examples include:

• Microsoft Entra ID (formerly Azure AD)
• Okta
• Keycloak
• Google Identity Platform

The workflow looks like this:

Developer
      │
      ▼
Identity Provider (OIDC)
      │
      ▼
JWT Token
      │
      ▼
API Server
      │
      ▼
Authenticated User

Benefits include:

• Single Sign-On (SSO)
• Multi-Factor Authentication (MFA)
• Centralized identity management
• Simplified user lifecycle management

---

Cloud Provider Authentication

Managed Kubernetes services integrate directly with cloud identity services.

Kubernetes Service	Identity Provider
AKS	Microsoft Entra ID
EKS	AWS IAM
GKE	Google Cloud IAM

This allows organizations to manage Kubernetes access using existing cloud identities rather than creating separate Kubernetes users.

---

Practical Lab – Discover Your Current User

Let’s see who Kubernetes thinks you are.

Run:

kubectl config current-context

View your current configuration:

kubectl config view

View cluster information:

kubectl cluster-info

If your Kubernetes version supports it, you can also run:

kubectl auth whoami

Example output:

ATTRIBUTE         VALUE
Username          mukesh@example.com
Groups            system:authenticated

This confirms that authentication has already succeeded before any authorization checks are performed.

---

Authentication Best Practices

• Production environments should follow these recommendations:
• Integrate with an enterprise identity provider.
• Enable Multi-Factor Authentication (MFA).
• Avoid sharing administrator credentials.
• Rotate certificates and tokens regularly.
• Audit authentication logs.
• Disable anonymous access to the API Server.

Authentication is the foundation of Kubernetes security. However, simply proving your identity is not enough. Kubernetes must still determine what actions you are allowed to perform.

That brings us to the next critical security layer—Authorization.

---

Chapter 4: Kubernetes Authorization – Controlling What Users Can Do

What Is Authorization?

After Kubernetes verifies who you are, it asks a second question:

“What are you allowed to do?”

This process is called authorization.

Authorization determines whether an authenticated user has permission to perform a requested action.

For example:

• Can this user create Pods?
• Can they delete Deployments?
• Can they read Secrets?
• Can they modify Network Policies?

If the answer is yes, Kubernetes continues processing the request.

If the answer is no, the request is rejected with a 403 Forbidden error.

---

Authentication vs Authorization

Many beginners confuse these two concepts.

Think of entering a secure office building.

Authentication is like showing your employee ID card at the entrance.

The security guard verifies:

“Yes, you are an employee.”

However, entering the building does not automatically grant access to every room.

Authorization determines:

“Which rooms are you allowed to enter?”

The same principle applies to Kubernetes.

Authentication proves your identity.

Authorization determines your permissions.

---

Authorization Workflow

Once authentication succeeds, the API Server checks permissions.

User
   │
   ▼
Authentication
   │
   ▼
Authorization
   │
 ┌─┴─────────┐
 │           │
Allowed    Denied
 │           │
 ▼           ▼
API Server 403 Forbidden

This happens for every single API request.

---

Authorization Modes in Kubernetes

Kubernetes supports several authorization mechanisms.

RBAC (Role-Based Access Control)

RBAC is the most commonly used authorization model.

Permissions are assigned through:

• Roles
• ClusterRoles
• RoleBindings
• ClusterRoleBindings

We’ll explore RBAC in detail in the next chapter.

---

ABAC (Attribute-Based Access Control)

ABAC grants permissions based on policies and user attributes.

Although still supported, it is rarely used in modern Kubernetes clusters because RBAC provides greater flexibility and is easier to manage.

---

Node Authorization

Worker nodes also communicate with the API Server.

Node Authorization ensures that each node can only access the resources it genuinely needs.

For example, a worker node should only retrieve Pods scheduled on itself.

This minimizes the impact of a compromised node.

---

Webhook Authorization

Organizations with complex security requirements can integrate Kubernetes with external authorization systems using webhooks.

This enables centralized access control across multiple platforms.

---

Practical Lab – Check Your Permissions

Kubernetes provides a simple way to test permissions.

Check if you can create Pods:

kubectl auth can-i create pods

Example output:

yes

Check if you can delete namespaces:

kubectl auth can-i delete namespaces

Example output:

no

You can also test permissions for another user:

kubectl auth can-i create deployments \
  --as developer@example.com

This is extremely useful when validating RBAC policies before granting access.

---

Enterprise Best Practices

Production Kubernetes environments should follow the Principle of Least Privilege.

Users should receive only the permissions required to perform their specific tasks.

Avoid granting broad permissions such as:

cluster-admin

unless absolutely necessary.

Instead:

• Create namespace-specific Roles.
• Assign permissions through RoleBindings.
• Review access regularly.
• Remove unused accounts promptly.

Proper authorization significantly reduces the risk of accidental changes and limits the impact of compromised credentials.

In the next chapter, we’ll build a complete RBAC implementation from scratch, create Roles and RoleBindings, and secure a real Kubernetes environment using least-privilege access control.

Chapter 5: Kubernetes RBAC – Controlling Access with Least Privilege

What is RBAC?

Once Kubernetes has successfully authenticated a user and verified their identity, it must determine what that user is allowed to do within the cluster. This is where Role-Based Access Control (RBAC) comes into play.

RBAC is the default authorization mechanism in modern Kubernetes clusters and is widely used in managed services such as Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS), and Google Kubernetes Engine (GKE).

Instead of assigning permissions directly to users, Kubernetes assigns permissions to roles, and then binds those roles to users, groups, or Service Accounts.

This approach simplifies permission management and follows the Principle of Least Privilege, ensuring users receive only the permissions they need to perform their tasks.

For example:

• A developer may only need permission to deploy applications.
• A QA engineer may only need permission to view logs.
• A Platform Engineer may manage cluster resources.
• A Security Administrator may audit permissions but not deploy applications.

Rather than granting everyone full administrative access, RBAC allows each user to receive a tailored set of permissions.

---

Why RBAC Is Critical

Imagine a company with 50 engineers working on the same Kubernetes cluster.

Without RBAC:

• Every engineer could delete production deployments.
• Anyone could read Secrets containing passwords.
• Developers could accidentally modify cluster networking.
• Junior engineers could remove critical namespaces.

A single mistake could bring down the entire platform.

RBAC prevents this by enforcing fine-grained access control.

Every API request is evaluated against RBAC rules before Kubernetes performs the requested action.

---

How RBAC Works

Whenever a request reaches the API Server, Kubernetes performs the following checks:

User
   │
   ▼
Authentication
   │
   ▼
RBAC Authorization
   │
   ▼
Role Lookup
   │
   ▼
Permission Match
   │
 ┌─┴────────┐
 │          │
Allow     Deny

If a matching permission exists, Kubernetes allows the request.

Otherwise, it immediately returns:

403 Forbidden

---

Understanding the Four Core RBAC Objects

RBAC consists of four primary Kubernetes resources.

Understanding the relationship between these objects is essential.

User / Group / Service Account
              │
              ▼
        RoleBinding
              │
              ▼
            Role
              │
              ▼
       Permissions

For cluster-wide permissions:

User
   │
   ▼
ClusterRoleBinding
   │
   ▼
ClusterRole

Let’s examine each component.

---

Role

A Role defines a set of permissions within a single namespace.

Think of a Role as a job description.

Example:

A developer working in the development namespace may require permission to:

• Create Pods
• Delete Pods
• View Services

But they should not manage resources in the production namespace.

Example Role:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: developer-role

rules:
- apiGroups: [""]
  resources:
  - pods
  - services
  verbs:
  - get
  - list
  - create
  - update
  - delete

This Role only applies within the development namespace.

---

ClusterRole

Unlike a Role, a ClusterRole provides permissions across the entire cluster.

ClusterRoles are commonly used for:

• Cluster administrators
• Monitoring systems
• Storage controllers
• Networking components

Example:

kind: ClusterRole

ClusterRoles can manage resources such as:

• Nodes
• Namespaces
• PersistentVolumes
• ClusterRoles

Because these resources exist outside individual namespaces.

---

RoleBinding

A Role alone does nothing.

It simply defines permissions.

A RoleBinding connects a Role to a user, group, or Service Account.

Example:

Developer
      │
      ▼
RoleBinding
      │
      ▼
Developer Role

Example YAML:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: development

subjects:
- kind: User
  name: alice@example.com

roleRef:
  kind: Role
  name: developer-role
  apiGroup: rbac.authorization.k8s.io

Now Alice receives the permissions defined inside developer-role.

---

ClusterRoleBinding

A ClusterRoleBinding works similarly but grants cluster-wide permissions.

Example:

Platform Engineer
         │
         ▼
ClusterRoleBinding
         │
         ▼
ClusterRole

Be extremely careful when assigning ClusterRoleBindings because they often provide powerful permissions.

---

Practical Lab 1 – Create a Namespace

Let’s build RBAC from scratch.

Create a namespace:

kubectl create namespace development

Verify:

kubectl get namespaces

Expected output:

development

---

Practical Lab 2 – Create a Role

Create:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: pod-manager

rules:
- apiGroups: [""]
  resources:
  - pods
  verbs:
  - get
  - list
  - create
  - delete

Apply:

kubectl apply -f role.yaml

Verify:

kubectl get roles -n development

---

Practical Lab 3 – Create a Service Account

Instead of using real users, we’ll create a Service Account.

kubectl create serviceaccount developer \
-n development

Verify:

kubectl get serviceaccounts -n development

---

Practical Lab 4 – Create a RoleBinding

Create:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: development
  name: developer-binding

subjects:
- kind: ServiceAccount
  name: developer
  namespace: development

roleRef:
  kind: Role
  name: pod-manager
  apiGroup: rbac.authorization.k8s.io

Apply:

kubectl apply -f rolebinding.yaml

---

Practical Lab 5 – Verify Permissions

Test permissions.

Can create Pods?

kubectl auth can-i create pods \
--as=system:serviceaccount:development:developer \
-n development

Expected:

yes

Can delete Deployments?

kubectl auth can-i delete deployments \
--as=system:serviceaccount:development:developer \
-n development

Expected:

no

This confirms RBAC is working correctly.

---

Real-World Enterprise Scenario

Imagine you’re managing an AKS cluster for an e-commerce platform.

Your organization has three teams:

Team	Responsibilities
Developers	Deploy applications
QA Engineers	View logs and troubleshoot
Platform Engineers	Manage infrastructure

Using RBAC, you configure:

• Developers can deploy workloads only in the development namespace.
• QA engineers have read-only access to Pods and logs.
• Platform Engineers manage Nodes, Namespaces, and Storage.
• Security Administrators audit permissions but cannot modify applications.

Now imagine a developer accidentally executes:

kubectl delete namespace production

RBAC immediately blocks the request with:

Error from server (Forbidden)

The production environment remains protected because the developer simply does not have permission.

This is the Principle of Least Privilege in action.

---

Common RBAC Mistakes

• Avoid these common mistakes:
• Granting cluster-admin to every developer.
• Using ClusterRoles when a namespace-scoped Role is sufficient.
• Forgetting to remove permissions for former employees.
• Sharing Service Account credentials across applications.
• Never reviewing RoleBindings.

RBAC should be reviewed regularly as part of your organization’s security governance.

---

Enterprise Best Practices

Production Kubernetes environments should follow these recommendations:

• Grant only the minimum permissions required.
• Prefer namespace-scoped Roles over ClusterRoles whenever possible.
• Use Groups instead of assigning permissions to individual users.
• Review RoleBindings periodically.
• Audit RBAC configurations using tools such as kubectl auth can-i.
• Integrate RBAC with Microsoft Entra ID, AWS IAM, or Google Cloud IAM.
• Avoid using the cluster-admin role except for a small number of trusted administrators.

RBAC is the foundation of Kubernetes authorization. When implemented correctly, it protects production clusters from accidental changes, limits the impact of compromised credentials, and ensures every user has only the access they genuinely need.

Chapter 6: Kubernetes Service Accounts & Workload Identity

Why Applications Need Their Own Identity

So far, we’ve focused on securing access for human users such as developers, administrators, and DevOps engineers. However, humans are not the only entities that communicate with the Kubernetes API.

Many applications running inside the cluster also need to interact with Kubernetes or other cloud services.

For example:

• A monitoring agent may need to read Pod information.
• An Ingress Controller may need to watch Services and Endpoints.
• Argo CD needs to deploy applications.
• External Secrets Operator needs to retrieve secrets from Azure Key Vault.
• A backup application may need to create VolumeSnapshots.

Unlike humans, these workloads cannot log in using usernames and passwords.

Instead, Kubernetes provides Service Accounts, which act as identities for applications running inside the cluster.

Think of a Service Account as a digital identity assigned to a Pod. Just as every employee in an organization has an identity card, every application should have its own identity with only the permissions it needs.

---

What Is a Service Account?

A Service Account is a Kubernetes object that provides an identity for Pods and applications.

Whenever a Pod communicates with the Kubernetes API Server, it does so using the credentials of its assigned Service Account.

By default, Kubernetes automatically creates a Service Account named:

default

in every namespace.

If you do not specify a Service Account in your Pod specification, Kubernetes automatically assigns the default Service Account.

You can verify this by running:

kubectl get serviceaccounts

Example output:

NAME      SECRETS   AGE
default   1         45d

Although convenient, using the default Service Account in production is considered a poor security practice because it often has broader permissions than necessary.

---

How Service Accounts Work

Let’s understand what happens when a Pod starts.

Suppose you deploy the following Pod:

apiVersion: v1
kind: Pod
metadata:
  name: web-app
spec:
  containers:
  - name: nginx
    image: nginx

Since no Service Account is specified, Kubernetes automatically assigns:

default

The workflow looks like this:

Pod Created
      │
      ▼
Default Service Account Assigned
      │
      ▼
Token Mounted Inside Pod
      │
      ▼
Pod Authenticates to API Server

The Service Account token is mounted automatically inside the container, allowing the application to authenticate with the Kubernetes API.

---

How the API Server Authenticates a Pod

Whenever an application inside a Pod sends a request to the API Server, the following process occurs:

Application
      │
      ▼
Service Account Token
      │
      ▼
API Server
      │
      ▼
Authentication Successful
      │
      ▼
RBAC Authorization

The API Server validates the Service Account token and determines which Service Account is making the request.

It then checks RBAC permissions before allowing the operation.

---

Why Not Use the Default Service Account?

Many beginners simply deploy workloads without specifying a Service Account.

While this works, it is not recommended for production environments.

Problems with the default Service Account include:

• Shared across multiple Pods
• Difficult to audit
• May receive unnecessary permissions
• Violates the Principle of Least Privilege

Instead, each application should have its own dedicated Service Account with only the permissions it requires.

---

Practical Lab 1 – View Existing Service Accounts

List all Service Accounts in the current namespace:

kubectl get serviceaccounts

View Service Accounts in all namespaces:

kubectl get serviceaccounts --all-namespaces

Observe that every namespace contains its own default Service Account.

---

Practical Lab 2 – Create a Custom Service Account

Create a dedicated Service Account for an application:

kubectl create serviceaccount payment-api

Verify:

kubectl get serviceaccounts

Example output:

NAME           SECRETS   AGE
default        1         45d
payment-api    1         5s

---

Practical Lab 3 – Assign the Service Account to a Deployment

Modify your Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: payment-api
  template:
    metadata:
      labels:
        app: payment-api
    spec:
      serviceAccountName: payment-api
      containers:
      - name: app
        image: nginx

Apply:

kubectl apply -f deployment.yaml

Every Pod created by this Deployment now uses the payment-api Service Account instead of the default one.

---

Practical Lab 4 – Verify the Assigned Service Account

View the Pod:

kubectl get pods

Describe it:

kubectl describe pod <pod-name>

Look for:

Service Account: payment-api

This confirms that the Pod is using the custom identity.

---

Understanding Service Account Tokens

Historically, Kubernetes created long-lived Secret objects that stored Service Account tokens.

These tokens were automatically mounted into Pods.

Modern Kubernetes versions use Bound Service Account Tokens, which are:

• Short-lived
• Automatically rotated
• More secure
• Bound to a specific Pod

This significantly reduces the risk of token theft and misuse.

---

Introducing Workload Identity

Service Accounts solve authentication inside the Kubernetes cluster.

However, modern applications also need to access cloud services such as:

• Azure Key Vault
• Azure Storage
• AWS S3
• AWS Secrets Manager
• Google Cloud Storage

Many older deployments stored cloud credentials as Kubernetes Secrets.

Example:

data:
  storage-key: xxxxxxxxxxxxx

This approach has several drawbacks:

• Long-lived credentials
• Difficult rotation
• Increased risk of credential leakage
• Manual management

Modern Kubernetes environments use Workload Identity instead.

---

What Is Workload Identity?

Workload Identity allows a Kubernetes Service Account to securely impersonate a cloud identity.

Instead of storing passwords or access keys, the application requests a temporary identity token.

The cloud provider validates the token and grants access only to the requested resources.

The architecture looks like this:

Application
      │
      ▼
Service Account
      │
      ▼
OIDC Token
      │
      ▼
Cloud Identity Provider
      │
      ▼
Temporary Access Token
      │
      ▼
Azure Key Vault / AWS / GCP

No secrets are stored inside the Pod.

---

Example – Azure Kubernetes Service (AKS)

Suppose your application needs to retrieve database credentials from Azure Key Vault.

With Workload Identity:

1. The Pod uses its Kubernetes Service Account.
2. AKS issues an OIDC token.
3. Microsoft Entra ID validates the token.
4. Azure Key Vault grants temporary access.
5. The application retrieves the secret securely.

At no point are static credentials stored inside the container.

This significantly improves security.

---

Practical Lab 5 – View Service Account Information

Run:

kubectl describe serviceaccount payment-api

Example output:

Name: payment-api
Namespace: default
Mountable secrets:
Tokens:
Events:

This displays information about the Service Account and its associated tokens.

---

Enterprise Secure Banking Application

Imagine an online banking platform running on AKS.

The platform consists of three microservices:

• Customer API
• Payment API
• Notification Service

Each application requires different cloud permissions.

Using Workload Identity:

Application	Cloud Permission
Customer API	Read customer data from Azure SQL
Payment API	Access Azure Key Vault secrets
Notification Service	Send messages through Azure Service Bus

Each application receives only the permissions it needs.

Even if one Pod is compromised, the attacker cannot access resources belonging to other applications.

This is a practical implementation of the Principle of Least Privilege.

---

Common Mistakes

Avoid these common mistakes:

• Using the default Service Account for every workload.
• Granting cluster-admin permissions to application Service Accounts.
• Storing cloud credentials inside Kubernetes Secrets.
• Sharing a single Service Account across multiple applications.
• Forgetting to rotate legacy credentials.

---

Enterprise Best Practices

Production clusters should follow these recommendations:

• Create a dedicated Service Account for each application.
• Grant only the minimum RBAC permissions required.
• Use Workload Identity instead of long-lived cloud credentials.
• Regularly audit Service Account permissions.
• Avoid mounting Service Account tokens unless the application requires Kubernetes API access.
• Integrate with cloud-native identity services such as Microsoft Entra ID, AWS IAM Roles for Service Accounts (IRSA), or Google Workload Identity.

By following these practices, you significantly reduce the attack surface of your Kubernetes workloads and align with modern cloud-native security principles.

Congratulations! You’ve completed the first part of the Kubernetes Security series and built a solid understanding of the security mechanisms that form the foundation of every production Kubernetes cluster.

Throughout this guide, we’ve explored how Kubernetes verifies identities, authorizes requests, assigns permissions, and securely enables applications to interact with both the Kubernetes API and external cloud services.

Let’s quickly recap what we’ve covered:

• Why Kubernetes Security Matters
• Understanding the Kubernetes Security Model
• Kubernetes Authentication
• Kubernetes Authorization
• Role-Based Access Control (RBAC)
• Service Accounts
• Workload Identity

These concepts are the building blocks of Kubernetes security. Whether you’re managing a small development cluster or a large enterprise platform hosting thousands of workloads, every secure Kubernetes environment relies on these foundational principles.

However, securing identities and permissions is only the first step.

Applications still need to store sensitive information securely. Pods must be isolated from one another. Network traffic must be carefully controlled. Every deployment should comply with organizational security policies, and workloads should follow security best practices from the moment they are deployed.

These advanced topics are essential for building truly production-ready Kubernetes platforms, and that’s exactly what we’ll cover next.

Further Reading

Include these official resources:

• Kubernetes RBAC Documentation
• Kubernetes Authentication Documentation
• Kubernetes Service Accounts Documentation
• Azure Workload Identity Documentation

---

Coming Up in Part 2

In the next article, we’ll move beyond identities and permissions to focus on securing Kubernetes workloads themselves.

We’ll explore:

🔒 Kubernetes Secrets and Secret Management

🔒 Integrating Azure Key Vault with Workload Identity

🔒 Security Contexts and Linux Capabilities

🔒 Pod Security Standards (Restricted, Baseline, and Privileged)

🔒 Network Policies and Micro-Segmentation

🔒 Admission Controllers and Policy Enforcement

🔒 Real-World Enterprise Security Labs

🔒 Production Security Best Practices

By the end of Part 2, you’ll understand how organizations implement defense-in-depth to protect applications, infrastructure, sensitive data, and network communication within production Kubernetes clusters.

---

Continue Your Kubernetes Learning Journey

This article is part of my Kubernetes Learning Roadmap, where we progress step by step from Kubernetes fundamentals to advanced production engineering concepts through practical, enterprise-focused examples and hands-on labs.

If you’re joining this series for the first time, I highly recommend starting with the complete roadmap and following each article in sequence, as every topic builds upon the concepts introduced in previous weeks.

🔹 Week 1: Core Kubernetes Objects – Your Building Blocks

🔹 Week 2: Kubernetes Controllers & Desired State

🔹 Week 3: Kubernetes Architecture – The Backbone

🔹 Week 4: Container Runtime & CRI – How Kubernetes Actually Runs Containers

🔹 Week 5 (Part 1): Kubernetes Security Foundations (Current Article)

🔹 Complete Kubernetes Learning Roadmap:
https://geekymukesh.com/kubernetes-in-2026-the-ultimate-8-week-learning-roadmap/

Coming Up Next: Week 5 – Part 2

In the next part of this Kubernetes Security series, we’ll move beyond identities and permissions to focus on securing workloads and enforcing security policies in production Kubernetes clusters.

You’ll learn about:

• 🔐 Kubernetes Secrets & Secure Secret Management
• 🔐 Azure Key Vault Integration with Workload Identity
• 🔐 Security Contexts & Linux Capabilities
• 🔐 Pod Security Standards (Privileged, Baseline & Restricted)
• 🔐 Network Policies & Micro-Segmentation
• 🔐 Admission Controllers & Policy Enforcement
• 🔐 Real-World Enterprise Security Implementation
• 🔐 Kubernetes Security Best Practices for Production

By the end of Week 5 – Part 2, you’ll have a comprehensive understanding of how enterprise organizations secure Kubernetes clusters using a layered, defense-in-depth approach—from user authentication to workload isolation and policy enforcement.

Complete Kubernetes Learning Roadmap:
https://geekymukesh.com/kubernetes-in-2026-the-ultimate-8-week-learning-roadmap/

If you found this guide helpful, consider sharing it with your colleagues and fellow Kubernetes enthusiasts. If you have questions, suggestions, or would like to share how your organization secures Kubernetes clusters, feel free to leave a comment below. I’d love to hear about your experiences and continue the discussion.

Stay tuned as we continue building production-ready Kubernetes expertise, one practical topic at a time.