Identity and Access Management Controls — Cloud Infrastructure and Container Security

Hook: You survived the DDoS, now stop handing out the torches

Remember how we just dug into DoS and botnet orchestration — devices turning into screaming, packet-spitting toddlers because credentials or misconfigurations let an attacker order them around? Good. IAM is the control plane that prevents those instructions from being issued in the first place. If DoS is the fire, IAM is the locksmith who should have taken the matches away from the arsonist.

Compromise a key identity and you gain a kingdom. Harden identities and you shrink the blast radius of almost every attack.

What we mean by IAM here (quick refresher)

• Identity: who or what is acting — human users, service accounts, machine identities.
• Authentication: how the identity proves it is who it says it is — passwords, MFA, certificates, OIDC tokens.
• Authorization: what that identity is allowed to do — roles, policies, ACLs, RBAC.

Contrast cloud-wide IAM (AWS IAM, Azure AD, GCP IAM) with container-native access controls (Kubernetes RBAC, service accounts, Pod Security). Both matter. One manages the keys to the cloud kingdom, the other manages who can shout commands into the cluster's ears.

Core primitives across environments

Practical controls that actually stop bad things

1. Least privilege first, always

   • Create narrow roles. Deny by default, allow only needed actions.
   • Avoid broad permissions like star resources or wildcards on sensitive actions.

2. Use short-lived, federated, or managed identities

   • Replace long-lived keys with STS tokens, workload identity federation, or cloud-managed identities.
   • Short-lived tokens reduce the value of any leaked credential.

3. Enforce multi-factor and conditional access

   • Enforce MFA for console/API use where appropriate and block risky login contexts.
   • Implement conditional access: require company network, trusted device, or step-up auth for higher privilege calls.

4. Separate machine and human identity paths

   • Humans use interactive login flows and MFA. Machines use managed identities, vaulted keys, or service accounts with scoped permissions.

5. Move secrets off the floor

   • Use a secrets manager / vault and KMS for encryption. No more credentials in code or container images.

6. Harden container identity

   • Use projected service account tokens with audience restriction.
   • Bind pod identities to specific service accounts and restrict mountable tokens.

7. Continuous audit and anomaly detection

   • Use cloud IAM analyzers, access logs, and alerting for unusual API calls or privilege escalations.

Short attack playbook and how IAM breaks each step

Scenario: an attacker finds a leaked API key, uses it to spin up compute, and launches a botnet or stress test against a target.

Attack steps and mitigations:

1. Credential theft
   • Mitigate: rotate keys, short-lived tokens, vaults, avoid embedding credentials in images.
2. Resource provisioning
   • Mitigate: require policy that prevents unchecked machine creation, use quota limits and service control policies, require specific role that is not widely granted.
3. Abuse of networking/APIs
   • Mitigate: conditional access, VPC/Security Group restrictions, private endpoints, rate limiting, WAF.
4. Persistence and lateral movement
   • Mitigate: separate roles, least privilege, deny privilege escalation, monitor iam:CreateAccessKey and iam:AttachRolePolicy events.

Small checklist for defenders:

• Ensure no unlimited-privilege service principal exists.
• Verify no unused keys older than N days.
• Check which identities can create compute or modify network controls.
• Validate that compute instances have only the permissions they require.

Concrete examples (pseudocode for clarity)

AWS style policy snippet (pseudocode, keep it narrow):

{
  'Version': '2012-10-17',
  'Statement': [
    {
      'Effect': 'Allow',
      'Action': ['ec2:DescribeInstances'],
      'Resource': '*'
    },
    {
      'Effect': 'Deny',
      'Action': ['ec2:RunInstances'],
      'Resource': '*'
    }
  ]
}

Kubernetes: bind a pod to a low-privilege service account

apiVersion: v1
kind: ServiceAccount
metadata:
  name: read-only-sa
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
rules:
  - apiGroups: ['']
    resources: ['pods']
    verbs: ['get', 'list']
---
# bind only the service account used by target pods

Note: use OIDC + projected tokens to avoid auto-refreshing secrets in files.

Tools and automation that scale IAM hygiene

• Cloud-native: AWS IAM Access Analyzer, Azure AD Conditional Access, GCP IAM Recommender
• K8s: OPA/Gatekeeper or Kyverno to enforce policies, kube-audit, Falco for runtime alerts
• Secret vaults: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault
• CI/CD checks: policy-as-code, terraform-validate, checkov, tflint for IAM misconfigurations

Automation example: deny deploys with wide policies in CI using policy-as-code. If a PR adds a role with wildcard actions, fail the pipeline.

People, process, and the glorious human factor

• Periodic access reviews: remove stale memberships and orphaned service accounts.
• Break-glass playbook: clearly documented emergency escalation for when real urgent access is required.
• Shift-left security: teach developers how to request least-privilege roles and how to use workload identities.

Ask yourself: who approves a role that allows network changes? Who owns the break-glass account? If you cannot answer quickly, fix it.

Closing: quick takeaways and next moves

• IAM is your blast-radius reducer. Good identity design makes incidents smaller, easier to detect, and faster to remediate.
• Short-lived, scoped credentials + vaulting = fewer nightmares. Don't babysit long-lived keys.
• Kubernetes and cloud have different knobs — turn both. Lock down cluster RBAC and cloud IAM independently, then make them play nicely via workload identity.
• Automate detection and prevention. Policy-as-code, analyzers, and runtime monitors catch what humans miss.

Final dramatic but useful thought:

Treat identity like a firewall you cannot see. One misconfigured rule and the attacker walks through your perimeter wearing the password you handed them. Harden identities, and you make their job miserable.

Next time, we tie this into incident response: how to accelerate containment when an identity is compromised, and how to use trace logs to rebuild the infection timeline — practical playbooks that directly build on the DDoS and resilience lessons we covered earlier.