MONEY MITRA NETWORK ACADEMY
CKS Security Certification Path
Cluster Hardening & RBAC Security
Implement defense-in-depth strategies by hardening cluster configurations and enforcing role-based access control across all resources.
$ kubectl get rbac --all-namespaces
Least privilege role bindings verified
✓ Cluster hardened
Cluster Hardening Principles
Secure by Default
Start with restrictive configurations and explicitly allow necessary access rather than starting permissive:
- ✓ Network Policies: Default deny all, explicitly permit required traffic
- ✓ RBAC: No permissions by default, grant only what's needed
- ✓ Pod Security: Restrict privileged containers and capabilities
- ✓ API Server: Disable anonymous auth, enforce TLS
$ kubectl api-resources --verbs=get
Check what's available
Grant only when needed
Least Privilege Access
Each principal (user, service account, application) should have only the minimum permissions required to function:
- → Specific Resources: Grant access to specific pods, not all pods in namespace
- → Limited Verbs: Grant only "get", "list" rather than "*" for read operations
- → Namespace Boundaries: Limit service account access to specific namespaces
- → Resource Quotas: Limit compute resources to prevent resource exhaustion
verbs: ["get", "list"]
resources: ["pods"]
✓ Minimal necessary access
RBAC Security Concepts
Role-Based Access Control (RBAC)
RBAC is Kubernetes' native authorization mechanism controlling what authenticated users can do:
Key RBAC Components:
- 1. Subjects: Users, service accounts, or groups
- 2. Roles: Define permissions (verbs on resources)
- 3. RoleBindings: Connect subjects to roles
Scope Levels:
- • Role/RoleBinding: Limited to single namespace
- • ClusterRole/ClusterRoleBinding: Cluster-wide access
Avoiding Over-Permissioned Accounts
Common security mistakes that give service accounts excessive privileges:
- ❌ Cluster-Admin Binding: Granting cluster-admin to application service accounts
- ❌ Wildcard Permissions: Using "*" for verbs or resources instead of specific values
- ❌ Cross-Namespace Access: Allowing pods to access resources outside their namespace
- ❌ Token Reuse: Using the same token for multiple applications or long periods
⚠ Anti-Pattern:
verbs: ["*"]
resources: ["*"]
→ Excessive permissions!
Permission Matrix Example
How different service accounts should have scoped permissions:
Network Policy & Segmentation
Segmentation Mindset
Divide your cluster into logical security zones, limiting communication between them:
- ✓ Namespace Boundaries: Use namespaces to organize workloads and apply policies
- ✓ Default Deny: Implement "deny all" network policies, then permit specific traffic
- ✓ Label-Based Rules: Use pod labels and selectors for flexible policy definitions
- ✓ Ingress/Egress Control: Explicitly define inbound and outbound traffic rules
East-West Traffic Control
Control traffic between pods and services (lateral movement prevention):
- → Pod-to-Pod: Restrict which pods can communicate with each other
- → Prevent Pivoting: Stop compromised pods from accessing sensitive services
- → Database Isolation: Only app pods can reach database pods, not general traffic
- → Zero Trust: Assume no pod is trustworthy, require explicit allow rules
Network Policy Pattern
kind: NetworkPolicy
metadata:
name: deny-all-default
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
✓ Default deny all traffic
Secure Configuration Strategy
Version Updates & Patching
Keep all cluster components and dependencies current with security patches:
- → Kubernetes Version: Upgrade control plane and nodes regularly (at least +2 minor versions supported)
- → Container Runtime: Keep containerd, CRI-O, Docker updated with latest security patches
- → CNI/Network: Update network plugins (Calico, Weave, Cilium) for bug fixes
- → System Libraries: Patch OS packages on all cluster nodes
$ kubectl version
Client: 1.28.0
Server: 1.28.0
✓ Aligned versions
Security Review Practices
Regularly audit and validate your cluster's security posture:
- ✓ RBAC Audit: Review all ClusterRoles, Roles, and RoleBindings regularly
- ✓ CIS Benchmark: Compare configuration against CIS Kubernetes Benchmark v1.x
- ✓ Security Policies: Enforce with admission controllers (Kyverno, OPA/Gatekeeper)
- ✓ Vulnerability Scans: Regularly scan images and running containers
$ kubectl auth can-i create pods
✓ Verify permissions
Audit trails enabled
External Learning References
Deepen your knowledge of RBAC, hardening, and network policies:
Network Policies
NetworkPolicy specification and use cases
Pod Security Standards
Security standards for pod configurations
CIS Kubernetes Benchmark
Security hardening benchmarks and controls