KCSA — Cloud Provider & Infrastructure Security
The Cloud Layer — Your Foundation
In the 4Cs model, the Cloud layer is the outermost ring. It’s the infrastructure everything else sits on — whether that’s a public cloud provider (AWS, Azure, GCP), a private data center, or a bare-metal setup.
Here’s the uncomfortable truth: if your infrastructure is compromised, nothing else matters. RBAC, network policies, image scanning — all of it becomes irrelevant if an attacker has root access to your cloud account.
That’s why the Cloud layer is where security must begin.
The Shared Responsibility Model
Every major cloud provider uses a shared responsibility model. The basic idea:
- The cloud provider secures the infrastructure of the cloud (hardware, networking, hypervisors, physical facilities)
- You secure what you put in the cloud (data, applications, configurations, access)
Shared Responsibility Breakdown
| Responsibility | Cloud Provider | You (Customer) |
|---|---|---|
| Physical security (data centers) | ✅ | ❌ |
| Hardware and hypervisor | ✅ | ❌ |
| Network backbone | ✅ | ❌ |
| Managed service uptime (e.g., EKS control plane) | ✅ | ❌ |
| IAM policies and users | ❌ | ✅ |
| VPC / network configuration | ❌ | ✅ |
| Worker node OS patching | ❌* | ✅ |
| Kubernetes RBAC | ❌ | ✅ |
| Application security | ❌ | ✅ |
| Data encryption configuration | ❌ | ✅ |
| Container image security | ❌ | ✅ |
| Network policies | ❌ | ✅ |
*Some managed services like GKE Autopilot or EKS on Fargate handle node patching for you — but most standard managed Kubernetes offerings leave node management to the customer.
Think of it like renting an apartment: the landlord is responsible for the building’s structure, plumbing, and electrical. But you’re responsible for locking your own door, not leaving the stove on, and maintaining what’s inside your unit.
Managed vs Self-Managed Kubernetes
How much of the Cluster layer the cloud provider handles depends on whether you use managed Kubernetes or self-managed clusters.
Comparison Table
| Aspect | Managed (EKS, AKS, GKE) | Self-Managed (kubeadm, k3s) |
|---|---|---|
| Control plane management | Provider manages and patches | You manage and patch |
| etcd management | Provider manages, encrypts | You manage, configure encryption |
| API server availability | Provider ensures HA | You configure HA |
| Worker node management | You manage (usually) | You manage |
| RBAC configuration | You configure | You configure |
| Network policies | You configure | You configure |
| Certificate rotation | Provider handles for control plane | You handle everything |
| Upgrade process | Guided by provider | Fully manual |
| Cost | Higher (managed service fee) | Lower (just compute) |
| Security burden | Shared | Almost entirely on you |
For the KCSA exam, understand that managed Kubernetes shifts some responsibility to the provider, but you’re still responsible for worker nodes, workloads, and configurations.
Managed Kubernetes — What the Provider Handles
With a managed service like EKS, AKS, or GKE:
- The control plane (API server, controller manager, scheduler) is managed and patched by the provider
- etcd is managed by the provider and often encrypted by default
- API server endpoint can be made private (no public access)
- Upgrades are simplified — but you still need to trigger them and test compatibility
What You Still Own
Even with managed Kubernetes, you’re responsible for:
- Worker node patches — the OS on your nodes needs regular updates
- RBAC policies — the provider doesn’t configure who can access what
- Network policies — by default, there are none
- Pod security — security contexts, resource limits, non-root enforcement
- Application and container security — everything from image scanning to secrets management
IAM Integration with Kubernetes
Cloud IAM (Identity and Access Management) and Kubernetes RBAC are separate but connected systems. Understanding how they integrate is key.
How Cloud IAM Maps to Kubernetes
| Cloud Provider | IAM → K8s Integration |
|---|---|
| AWS (EKS) | IAM roles/users mapped to K8s groups via aws-auth ConfigMap; IRSA for Pod-level IAM |
| Azure (AKS) | Azure AD integrated with K8s RBAC; managed identities for Pods |
| GCP (GKE) | Google IAM roles grant K8s access; Workload Identity for Pod-level IAM |
Key IAM Concepts for the Exam
- IAM Roles for Service Accounts (IRSA) — EKS feature that lets individual Pods assume specific IAM roles instead of inheriting the node’s role
- Workload Identity — GKE equivalent of IRSA
- Pod Identity — AKS equivalent for Azure managed identities
- Principle of Least Privilege — every IAM entity should have the minimum permissions needed
Never assign broad IAM roles (like AdministratorAccess on AWS) to Kubernetes worker nodes. If one Pod on that node is compromised, the attacker inherits those permissions.
IAM Best Practices
- ✅ Use Pod-level IAM (IRSA, Workload Identity) instead of node-level IAM roles
- ✅ Apply least-privilege to all IAM roles and policies
- ✅ Audit IAM usage regularly — remove unused roles and permissions
- ✅ Enable MFA for all human users who access the cloud console
- ✅ Use short-lived credentials (STS tokens) instead of long-lived access keys
- ✅ Separate IAM roles for different environments (dev, staging, production)
Network Isolation
Network security at the cloud layer is your first line of defense against unauthorized access.
Key Network Constructs
| Construct | Purpose | Example |
|---|---|---|
| VPC (Virtual Private Cloud) | Isolated network environment | All cluster resources in a dedicated VPC |
| Subnets | Segment the VPC into public and private zones | Worker nodes in private subnets, load balancers in public subnets |
| Security Groups | Stateful firewall rules for instances | Allow port 443 to API server only from corporate CIDR |
| NACLs | Stateless network ACLs at the subnet level | Additional layer of defense at the subnet boundary |
| Private Endpoints | Keep traffic off the public internet | API server reachable only through VPC private endpoint |
| NAT Gateway | Outbound internet access for private subnets | Nodes can pull images but aren’t directly exposed |
Network Isolation Best Practices
- ✅ Keep the API server private — don’t expose it to the public internet
- ✅ Place worker nodes in private subnets — they don’t need public IPs
- ✅ Use security groups to restrict traffic to only necessary ports and sources
- ✅ Separate environments (dev, staging, prod) into different VPCs or accounts
- ✅ Use VPC peering or Transit Gateway carefully — don’t create a flat network across all environments
- ✅ Enable VPC Flow Logs for network traffic visibility
Encryption at Rest and in Transit
Encryption is non-negotiable for any production Kubernetes environment.
Encryption in Transit (TLS)
| Communication Path | Encryption |
|---|---|
| kubectl → API server | TLS (HTTPS) |
| API server → etcd | TLS (mutual TLS recommended) |
| API server → kubelet | TLS |
| Pod → Pod (by default) | ❌ Unencrypted |
| Pod → Pod (with service mesh) | ✅ mTLS |
| Application → external services | TLS (you configure) |
By default, Pod-to-Pod traffic is not encrypted. You need a service mesh (like Istio or Linkerd) or application-level TLS to secure it.
Encryption at Rest
| Data | Encryption Method |
|---|---|
| etcd data | Kubernetes encryption provider (aescbc, aesgcm, kms) |
| Persistent volumes (EBS, Azure Disk) | Cloud KMS (customer-managed or provider-managed keys) |
| S3 / blob storage | Server-side encryption (SSE) |
| Secrets in etcd | Not encrypted by default — must enable explicitly |
The fact that Kubernetes Secrets are stored in plaintext in etcd by default is a commonly tested point on the KCSA exam. You must explicitly configure encryption at rest.
Control Plane Security in Managed Clusters
Even though the cloud provider manages the control plane, you can still configure some security settings:
| Setting | What You Can Configure |
|---|---|
| API server access | Restrict to private endpoint only; allowlist specific CIDRs |
| Audit logging | Enable control plane logging (API server, authenticator, scheduler) |
| Encryption | Enable envelope encryption for Secrets using your own KMS key |
| Authentication | Integrate with your identity provider (OIDC, cloud IAM) |
| Authorized networks | Restrict which IP ranges can reach the API server |
Control Plane Hardening Checklist
- ✅ Make the API server private or restrict to specific CIDRs
- ✅ Enable audit logging to a centralized logging system
- ✅ Enable encryption at rest for Secrets using KMS
- ✅ Rotate credentials regularly (kubeconfig, service account tokens)
- ✅ Disable public endpoint if all access is through a VPN or bastion
Node Security
Worker nodes are the machines that actually run your workloads. They need hardening too.
Node Hardening Practices
| Practice | Description |
|---|---|
| Minimal OS | Use container-optimized OS images (Bottlerocket, COS, Flatcar) |
| CIS Benchmarks | Apply CIS Kubernetes Benchmark for node configuration |
| Restrict SSH | Disable SSH access to nodes or restrict to bastion hosts |
| Auto-patching | Enable automatic OS security patches |
| IMDSv2 | On AWS, enforce IMDSv2 to protect instance metadata |
| kubelet configuration | Disable anonymous auth, enable certificate rotation |
| Limit node IAM | Minimal IAM role — only what the node needs (ECR pull, logging) |
CIS Benchmarks for Kubernetes Nodes
The Center for Internet Security (CIS) publishes benchmarks that are widely recognized as best practices. For Kubernetes, the CIS Benchmark covers:
- API server configuration
- etcd configuration
- Controller manager and scheduler settings
- Worker node configuration (kubelet, file permissions)
- Policies (RBAC, network policies, Pod security)
Tools like kube-bench automate CIS Benchmark checks against your cluster. This is a useful tool to mention in the exam context.
Key Takeaways for the Exam
- The shared responsibility model is fundamental — know what the provider handles vs. what you handle, especially for managed Kubernetes
- Managed Kubernetes (EKS, AKS, GKE) shifts control plane responsibility to the provider, but worker nodes, RBAC, and workloads are yours
- IAM integration varies by cloud provider — know the key mechanisms (IRSA on EKS, Workload Identity on GKE, Pod Identity on AKS)
- Pod-level IAM is always preferred over node-level IAM
- Network isolation = VPCs, private subnets, security groups, private API server endpoints
- Kubernetes Secrets are not encrypted at rest by default — you must configure encryption
- Pod-to-Pod traffic is unencrypted by default — use a service mesh for mTLS
- CIS Benchmarks are the gold standard for node and cluster hardening; kube-bench is the tool to check compliance
- Always apply the principle of least privilege to IAM roles, RBAC, and network access
Next up: Container Image Security — how to build, scan, and trust the images that run in your cluster.
