Warrior, now we're entering the Security phase of Kubernetes.
So far, we've focused on making applications:
Now we need to answer:
Who is allowed to do what inside the Kubernetes cluster?
For example:
Developer
↓
Can they delete production Pods?
Frontend Pod
↓
Can it access PostgreSQL?
Node.js API
↓
Can it read Kubernetes Secrets?
Monitoring system
↓
Can it inspect Pods?
Admin
↓
Can they modify everything?Kubernetes security is largely about controlling these permissions and reducing unnecessary access.
A useful simplified model is:
Kubernetes Security
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
Authentication Authorization Workload Security
│ │ │
▼ ▼ ▼
"Who are you?" "What can you do?" "How does workload run?"
│
▼
RBACThere are several layers:
Identity
↓
Authentication
↓
Authorization
↓
RBAC
↓
Pod / Container Security
↓
Network Security
↓
Secret ManagementWe'll study NetworkPolicy separately in Chapter 20.
This is one of the most important security concepts.
Authentication asks:
Who are you?
Examples:
User = Anubhav
ServiceAccount = node-apiAuthorization asks:
What are you allowed to do?
For example:
Anubhav
↓
Can read Pods? ✅
Can delete Pods? ❌So:
Authentication
= Who are you?
Authorization
= What can you do?Imagine your production cluster.
Developer:
developer@company.comThey should perhaps be able to:
get pods
get logs
describe deploymentsBut maybe not:
delete namespace
delete production database
modify cluster-wide configurationSo Kubernetes needs an authorization mechanism.
That's where:
comes in.
RBAC stands for:
Role-Based Access Control
Instead of giving permissions individually to every person, you define roles.
Example:
Developer Role
│
├── get Pods
├── list Pods
├── get Logs
└── describe DeploymentsThen assign the role to users or ServiceAccounts.
Think:
WHO
│
▼
RoleBinding
│
▼
Role
│
▼
PermissionsMore accurately:
User / Group / ServiceAccount
│
▼
RoleBinding
│
▼
Role
│
▼
API permissionsFor cluster-wide permissions:
User / Group / ServiceAccount
│
▼
ClusterRoleBinding
│
▼
ClusterRoleA Kubernetes Role defines permissions within a namespace.
Example:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pod-reader
namespace: development
rules:
- apiGroups: [""]
resources:
- pods
verbs:
- get
- list
- watchThis means:
In the
developmentnamespace, this Role allows reading Pods.
It does not automatically grant access to every namespace.
rules#This section:
rules:
- apiGroups: [""]
resources:
- pods
verbs:
- get
- list
- watchcontains three important pieces.
pods
deployments
services
secrets
configmapsget
list
watch
create
update
patch
deletePods belong to the core API group:
apiGroups: [""]Deployments belong to:
apps| Verb | Meaning |
|---|---|
get |
Read one resource |
list |
List resources |
watch |
Watch changes |
create |
Create resource |
update |
Replace/update resource |
patch |
Partially modify resource |
delete |
Delete resource |
Example:
get podsmeans:
Read a specific Pod.
list podsmeans:
List Pods.
Creating a Role isn't enough.
You need to connect that Role to an identity.
That's what:
RoleBinding
does.
Example:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: pod-reader-binding
namespace: development
subjects:
- kind: User
name: developer@example.com
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.ioArchitecture:
developer@example.com
│
▼
RoleBinding
│
▼
pod-reader Role
│
▼
get/list/watch PodsDon't confuse these.
Defines:
What permissions exist?
Defines:
Who gets those permissions?
Memory trick:
Role
= Rules
RoleBinding
= AssignmentLet's say:
Namespace = developmentWe want:
developer@example.comto read Pods.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pod-reader
namespace: development
rules:
- apiGroups: [""]
resources:
- pods
verbs:
- get
- list
- watchapiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: pod-reader-binding
namespace: development
subjects:
- kind: User
name: developer@example.com
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.ioNow:
developer
↓
RoleBinding
↓
pod-reader
↓
Pods
├── get ✅
├── list ✅
├── watch ✅
└── delete ❌You could give:
cluster-adminto everyone.
But that's dangerous.
Imagine:
Developer
↓
kubectl delete namespace productionIf they have unrestricted permissions:
💥 Production destroyedInstead:
Developer
↓
Only required permissionsThis is called:
The rule is:
Give an identity only the permissions it actually needs.
For example:
A monitoring service might need:
get pods
list pods
watch podsIt probably doesn't need:
delete pods
delete namespaces
create clusterrolesSo:
Required permissions
↓
onlynot:
Everything
↓
just in caseA Role is namespace-scoped.
A:
ClusterRole
can define permissions usable at cluster scope and can also be bound into namespaces depending on how it's referenced.
Example:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: node-reader
rules:
- apiGroups: [""]
resources:
- nodes
verbs:
- get
- list
- watchNodes aren't namespace-scoped resources.
So cluster-level access is appropriate here.
To give that ClusterRole to a user:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: node-reader-binding
subjects:
- kind: User
name: developer@example.com
roleRef:
kind: ClusterRole
name: node-reader
apiGroup: rbac.authorization.k8s.ioNow:
Developer
↓
ClusterRoleBinding
↓
ClusterRole
↓
Nodes| Feature | Role | ClusterRole |
|---|---|---|
| Namespace-scoped definition | ✅ | Can be used |
| Cluster-scoped resources | ❌ | ✅ |
| Nodes | ❌ | ✅ |
| Namespace-local Pods | ✅ | ✅ |
| Typical use | App/team permissions | Cluster-wide permissions |
A ClusterRole can be bound with a RoleBinding to grant its rules within a particular namespace, which is a useful pattern for reusable permission sets.
So far we've talked about humans.
But applications also need identities.
Suppose:
Node.js API Podneeds to communicate with the Kubernetes API.
What identity does it use?
A:
ServiceAccount
A ServiceAccount provides an identity for workloads running inside Kubernetes.
Think:
Human
↓
User identity
Pod
↓
ServiceAccount identityExample:
apiVersion: v1
kind: ServiceAccount
metadata:
name: node-api
namespace: productionThen:
spec:
serviceAccountName: node-apiNow the Pod runs using that ServiceAccount identity.
Imagine an internal operator or controller.
It may need to:
List Pods
Watch Deployments
Read ConfigMapsInstead of giving it an administrator identity:
Pod
↓
ServiceAccount
↓
Minimal RoleExample:
apiVersion: v1
kind: Role
metadata:
name: pod-reader
namespace: production
rules:
- apiGroups: [""]
resources:
- pods
verbs:
- get
- list
- watchServiceAccount:
apiVersion: v1
kind: ServiceAccount
metadata:
name: monitoring-app
namespace: productionRoleBinding:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: monitoring-binding
namespace: production
subjects:
- kind: ServiceAccount
name: monitoring-app
namespace: production
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.ioArchitecture:
Monitoring Pod
│
▼
ServiceAccount
│
▼
RoleBinding
│
▼
Role
│
▼
get/list/watch PodsDon't give every Pod:
cluster-adminInstead:
Pod
↓
Dedicated ServiceAccount
↓
Minimal RBAC permissionsThis dramatically reduces blast radius.
Pods can use a namespace's default ServiceAccount if you don't specify one.
For example:
kubectl get serviceaccountsYou may see:
NAME SECRETS
default ...However, production workloads should generally use an explicitly chosen ServiceAccount when they need permissions.
If your application doesn't need to communicate with the Kubernetes API, consider:
automountServiceAccountToken: falseExample:
apiVersion: apps/v1
kind: Deployment
metadata:
name: frontend
spec:
replicas: 3
template:
metadata:
labels:
app: frontend
spec:
automountServiceAccountToken: false
containers:
- name: frontend
image: my-frontend:1.0This reduces unnecessary credentials exposure to the application.
We covered Secrets in Chapter 9.
A Kubernetes Secret is useful for sensitive configuration, but don't assume:
Secret
=
Automatically encrypted everywhereImportant considerations include:
Remember:
data:
password: bXlQYXNzd29yZA==That is Base64 encoding.
Someone can decode it.
Conceptually:
Base64
↓
Encoding
❌
EncryptionNever treat Base64 as a security mechanism.
Production environments often integrate with secret-management systems such as:
AWS Secrets Manager
Google Secret Manager
Azure Key Vault
HashiCorp VaultArchitecture:
External Secret Manager
│
▼
Kubernetes integration
│
▼
Secret
│
▼
PodThis can reduce the need to store long-lived plaintext credentials directly in application manifests.
Now let's move from API authorization to container security.
Kubernetes supports:
securityContext
It controls security-related settings for Pods and containers.
For example:
securityContext:
runAsNonRoot: trueThis means:
The container should not run as root.
Suppose your application is compromised.
If it runs as root:
Attacker
↓
Compromised application
↓
Root privileges
↓
Potentially greater impactIf it runs as a non-root user:
Attacker
↓
Compromised application
↓
Limited privilegesThis is an example of reducing blast radius.
runAsUser#You can specify a user ID:
securityContext:
runAsUser: 10001
runAsNonRoot: trueNow the container process should run as UID:
10001Your Docker image must be compatible with this user.
readOnlyRootFilesystem#You can make the container's root filesystem read-only:
securityContext:
readOnlyRootFilesystem: trueThen:
Application
↓
Cannot normally write to root filesystemIf the application needs temporary writable storage, you can mount a writable volume such as emptyDir at a specific path.
Linux capabilities provide subsets of privileged operations.
You can drop capabilities:
securityContext:
capabilities:
drop:
- ALLThen selectively add only what is genuinely required.
This follows the same principle:
Least privilege.
apiVersion: v1
kind: Pod
metadata:
name: secure-app
spec:
securityContext:
runAsNonRoot: true
containers:
- name: app
image: my-node-api:1.0
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop:
- ALLThis is a good starting pattern, but your application must actually be compatible with these restrictions.
allowPrivilegeEscalation#Consider:
allowPrivilegeEscalation: falseThis helps prevent a process from gaining more privileges than its parent process allows through supported Linux privilege mechanisms.
Again:
Security settings should be tested against your application rather than copied blindly.
Avoid:
securityContext:
privileged: trueunless there is a well-understood infrastructure requirement.
A privileged container has substantially elevated access to the host.
For ordinary:
Node.js
Python
Next.js
Nginxapplications, privileged mode is generally unnecessary.
Kubernetes provides Pod Security Standards with profiles commonly described as:
Privileged
Baseline
RestrictedConceptually:
Privileged
↓
More permissions
Baseline
↓
Common restrictions
Restricted
↓
Stronger hardeningFor production workloads, stronger restrictions are generally desirable when the application supports them.
Pod security controls can be applied through namespace labels.
For example, a namespace can be configured to enforce a Pod Security Standard level.
Conceptually:
Namespace: production
│
▼
Pod Security policy level
│
▼
Pods must satisfy restrictionsThis helps prevent developers from accidentally deploying overly privileged workloads.
Now let's combine everything:
Kubernetes Security
│
┌────────────────┼─────────────────┐
▼ ▼ ▼
Identity RBAC Workload
│ │ Security
▼ ▼ ▼
User/ServiceAccount Role SecurityContext
│
RoleBinding
│
▼
PermissionsThen networking:
NetworkPolicy
│
▼
Pod-to-Pod trafficWe'll study this in Chapter 20.
Imagine:
production
│
├── frontend
├── backend
├── redis
└── workerYou might design identities like:
frontend-sa
backend-sa
worker-saAnd permissions:
frontend-sa
→ almost no Kubernetes API permissions
backend-sa
→ only required API permissions
worker-sa
→ only required API permissionsArchitecture:
Frontend Pod
│
▼
frontend-sa
│
▼
Minimal permissions
Backend Pod
│
▼
backend-sa
│
▼
Required permissions only
Worker Pod
│
▼
worker-sa
│
▼
Required permissions onlySuppose your Node.js backend needs to watch a ConfigMap.
Create:
apiVersion: v1
kind: ServiceAccount
metadata:
name: backend-sa
namespace: productionRole:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: backend-config-reader
namespace: production
rules:
- apiGroups: [""]
resources:
- configmaps
verbs:
- get
- list
- watchRoleBinding:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: backend-config-reader-binding
namespace: production
subjects:
- kind: ServiceAccount
name: backend-sa
namespace: production
roleRef:
kind: Role
name: backend-config-reader
apiGroup: rbac.authorization.k8s.ioDeployment:
spec:
template:
spec:
serviceAccountName: backend-saNow:
Backend
↓
backend-sa
↓
RoleBinding
↓
Role
↓
ConfigMapOne extremely useful command:
kubectl auth can-i get podsThis asks:
Can the current identity get Pods?
You can test:
kubectl auth can-i delete podsMaybe:
noExcellent.
You can also check as a specific user or ServiceAccount:
kubectl auth can-i get pods \
--as=system:serviceaccount:production:backend-saAnd:
kubectl auth can-i delete pods \
--as=system:serviceaccount:production:backend-saThis is very useful for debugging RBAC.
Giving every application:
cluster-admin❌ Extremely broad permissions.
Using one ServiceAccount for everything.
All Pods
↓
same identity❌ Large blast radius.
Storing secrets in Git.
DATABASE_PASSWORD=myPassword123❌ Dangerous.
Thinking Base64 is encryption.
Base64 ≠ encryptionRunning everything as root.
root❌ Unnecessary privilege.
Using:
privileged: truewithout a strong reason.
Giving applications Kubernetes API permissions they don't need.
A production-oriented application could look like:
Kubernetes Cluster
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
Frontend Backend Worker
│ │ │
▼ ▼ ▼
frontend-sa backend-sa worker-sa
│ │ │
▼ ▼ ▼
Minimal RBAC Required RBAC Required RBAC
│
▼
Kubernetes API
Secrets
│
▼
External Secret Manager
│
▼
Kubernetes
Secrets
NetworkPolicy
│
▼
Pod-to-Pod restrictionsFor a human:
Developer
│
▼
Identity Provider / Cluster Auth
│
▼
Authenticated identity
│
▼
RBAC
│
▼
Kubernetes APIFor a Pod:
Pod
│
▼
ServiceAccount
│
▼
RBAC
│
▼
Kubernetes APIAlmost every Kubernetes security decision can be simplified to:
Give the smallest amount of access required for the shortest reasonable scope.
That means:
Namespace scope
over
Cluster scopewhen possible.
Specific resource
over
All resourcesRead-only
over
WriteNon-root
over
RootDedicated ServiceAccount
over
Shared powerful identityRole-Based Access Control is Kubernetes' authorization mechanism for controlling what users, groups, and ServiceAccounts can do with Kubernetes resources.
Role
→ permissions
RoleBinding
→ assigns permissionsRole
→ namespace-oriented
ClusterRole
→ cluster-wide resource permissions and reusable permission definitionsAn identity used by workloads running inside Kubernetes.
User
→ typically human/external identity
ServiceAccount
→ workload identityAuthentication
→ Who are you?
Authorization
→ What can you do?Grant only the permissions required to perform the intended task.
To reduce the potential impact if the application or container is compromised.
Not automatically merely because it is a Secret object. Security depends on configuration such as encryption at rest, access controls, and how secrets are handled.
No.
Tolerations are about Pod scheduling onto tainted nodes, not RBAC.
Authentication
↓
"Who are you?"
Authorization
↓
"What can you do?"
RBAC
↓
PermissionsRole
↓
Permissions
RoleBinding
↓
Who gets Role?
ClusterRole
↓
Cluster-level/reusable permissions
ClusterRoleBinding
↓
Who gets ClusterRole?Pod
↓
ServiceAccount
↓
RBACsecurityContext
├── runAsNonRoot
├── runAsUser
├── readOnlyRootFilesystem
├── allowPrivilegeEscalation
└── capabilitiesLeast privilege everywhere.
For the Node.js/Next.js platform we've been building:
USER
│
▼
Ingress
│
▼
Service
│
▼
┌──────────────┐
│ Node.js API │
│ Pod │
└──────┬───────┘
│
ServiceAccount
│
▼
RBAC
│
Only required
Kubernetes API
permissions
┌──────────────────────────┐
│ │
▼ ▼
Secrets SecurityContext
│ │
▼ ▼
External Secret Manager Non-root
Read-only FS
No privilege escalation
│
▼
NetworkPolicy
│
▼
Allowed Pod trafficYou now have the foundation for securing a production Kubernetes application.
This is the natural next step.
We'll answer:
"If every Pod can potentially communicate over the cluster network, how do I control who can talk to whom?"
We'll build rules like:
Internet
│
▼
Ingress
│
▼
Frontend
│
▼
Backend ✅
│
├── PostgreSQL ✅
├── Redis ✅
└── Other Pods ❌We'll cover Ingress/Egress policies, default-deny, labels, namespaces, DNS access, PostgreSQL/Redis isolation, and real production NetworkPolicy YAML.
Mark it as complete to track your mastery.