Turning up Security on Compute Services Part 4

​

Pod-level identity: IRSA + OIDC (recommended pattern)

1. An OIDC provider registered in IAM that represents the EKS cluster issuer.
2. A Kubernetes ServiceAccount annotated with the IAM role ARN for pods that need permissions.
3. The pod (or AWS SDK inside it) calls STS with the service-account JWT and role ARN; STS validates the JWT against the IAM-registered OIDC provider and returns temporary credentials.

1. Register the cluster OIDC issuer URL as an IAM OIDC identity provider (establishes trust).
2. Create an IAM role with a trust policy that allows sts:AssumeRoleWithWebIdentity for tokens issued by that provider and restricted by sub/aud conditions.
3. Annotate the Kubernetes service account with the IAM role ARN.
4. Pod presents its service-account JWT to STS; STS validates the OIDC token and returns temporary credentials for AWS APIs (S3, DynamoDB, etc.).

• IAM Roles for Service Accounts (IRSA): https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html
• Enable IAM roles for service accounts (OIDC): https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html

​

Quiz: essential step to integrate OIDC with IAM

• The essential step is enabling and using the cluster’s OIDC issuer URL to create the IAM OIDC identity provider in IAM. This establishes the trust relationship STS uses to validate service-account JWTs. Manually creating a generic OIDC provider without the cluster issuer URL is error-prone, and AWS Identity Center (SSO) is unrelated to IRSA.

​

EKS IAM integration — correct summary

• Use IRSA: associate IAM roles with Kubernetes service accounts so pods assume AWS roles and directly access services. Pod-level identity provides finer-grained least-privilege access than node-level IAM role attachment.

​

Cluster, node, and pod IAM roles — responsibilities

• Cluster role: EKS control plane needs rights to create/manage AWS resources (EC2, ELB).
• Node role: Needed to pull container images and send logs (ECR, CloudWatch).
• Pod execution (IRSA): Preferred to let individual pods assume roles and access services.

​

Node types: responsibility tradeoffs

​

Large architecture walkthrough

• Network segmentation (subnets, NACLs, Security Groups)
• IAM least privilege (IRSA, node roles)
• Data protection (KMS, encrypted volumes)
• Observability (control plane logs, node/app logs)

​

EKS advantages

• AWS manages the EKS control plane (high availability, automated patching).
• EKS integrates with core AWS services (IAM, CloudWatch, VPC), improving observability and operational security.

​

Data protection: encryption at rest and in transit

• Kubernetes Secrets are Base64-encoded by default — not strongly encrypted. Enable KMS-integrated envelope encryption for Kubernetes secrets and use customer-managed KMS keys (CMKs) when you require strong encryption.
• Ensure underlying volumes (EBS, EFS, FSx) are encrypted. Use the CSI drivers and StorageClass parameters to request encrypted storage dynamically.

​

Detection and logging (control plane & nodes)

• Enable EKS control plane logs in the cluster settings (API, audit, authenticator, controllerManager, scheduler) and stream them to CloudWatch Logs for audit and incident investigations.
• Collect node and application logs with Fluentd/Fluent Bit and forward to CloudWatch or your logging pipeline.
• Control plane logs are configured via the EKS cluster logging settings; node/app logs are collected by agents running on the nodes or as DaemonSets.

​

Multi-tenancy considerations

• Single cluster for cost efficiency + namespaces + RBAC + network policies + quotas for team isolation.
• Use dedicated clusters for tenants with strict compliance or blast-radius isolation requirements.

​

Network security and NetworkPolicy

• By default pod-to-pod traffic is allowed. To restrict east-west traffic, use Kubernetes NetworkPolicy objects together with the AWS VPC CNI plugin (which gives pods VPC IP addresses).
• Security Groups for Pods can also provide AWS-level filtering, but NetworkPolicy is the Kubernetes-native enforcement mechanism.
• Example configuration toggle (as JSON):

{
  "enableNetworkPolicy": "true"
}

​

Service mesh and mTLS

• If you need end-to-end encryption and mutual authentication between services, deploy a service mesh that supports mutual TLS (mTLS). AWS App Mesh, Istio, and Linkerd are common choices.
• Use mTLS where regulatory or security requirements demand encryption-in-transit and strong service identity.

​

Load balancing: ALB vs. NLB and the AWS Load Balancer Controller

• ALB (Application Load Balancer): Use for HTTP/HTTPS Layer 7 features such as path-based routing, host-based routing, and WAF integration. Use the AWS Load Balancer Controller (previously ALB Ingress Controller) to provision ALBs for Ingress resources.
• NLB (Network Load Balancer): Use when you need ultra-low latency, extreme performance, or TCP/UDP passthrough. The AWS Load Balancer Controller can provision NLBs for Service resources or annotated Ingress/Service manifests.

• AWS Load Balancer Controller: https://kubernetes-sigs.github.io/aws-load-balancer-controller/

​

CSI drivers and storage encryption

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-encrypted
provisioner: ebs.csi.aws.com
parameters:
  encrypted: "true"
  # Optional KMS key:
  # kmsKeyId: arn:aws:kms:region:account-id:key/key-id
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

• For EFS and FSx CSI drivers: set encryption parameters in the StorageClass or provision volumes with encryption enabled and use KMS CMKs if required.

​

Final notes and recommended controls

• Use the cluster OIDC provider + IRSA for least-privilege pod access to AWS services.
• Enable KMS-backed encryption for Kubernetes secrets and ensure CSI-backed volumes are created encrypted.
• Export EKS control plane logs to CloudWatch and collect node/app logs with Fluent Bit/Fluentd.
• Apply Kubernetes NetworkPolicy and use the VPC CNI + Security Groups for Pods to control east-west traffic.
• Choose node type (self-managed vs managed node group vs Fargate) according to compliance and operational capability.
• Use the AWS Load Balancer Controller for ALB/NLB provisioning and pick ALB for L7 routing and NLB for extremely high-performance needs.
• Consider a service mesh with mTLS for strong inter-service encryption/identity when needed.

• IAM Roles for Service Accounts (IRSA): https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html
• EKS control plane logging: https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html
• AWS Load Balancer Controller: https://kubernetes-sigs.github.io/aws-load-balancer-controller/
• EBS CSI driver (EKS docs): https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html
• EFS CSI driver (EKS docs): https://docs.aws.amazon.com/eks/latest/userguide/efs-csi.html