Cloud Security

Identity and Access Management (IAM)

IAM is the foundational security service in every cloud provider, controlling who can do what on which resources.

Core Concepts

Principal ──► Authentication ──► Authorization ──► Action on Resource
(who)         (prove identity)   (check policy)    (allowed or denied)

| Entity | Description | Use Case | |--------|-------------|----------| | User | Persistent identity with credentials | Human operators (minimize use) | | Group | Collection of users sharing policies | Team-based access (Developers, Admins) | | Role | Assumed identity with temporary credentials | Services, cross-account, federation | | Service Account | Identity for applications (GCP/K8s) | Workload identity |

IAM Policies

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowS3ReadOnly",
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:ListBucket"
    ],
    "Resource": [
      "arn:aws:s3:::data-bucket",
      "arn:aws:s3:::data-bucket/*"
    ],
    "Condition": {
      "StringEquals": { "aws:PrincipalTag/Department": "analytics" },
      "IpAddress": { "aws:SourceIp": "10.0.0.0/8" }
    }
  }]
}

Policy Evaluation Logic

                   Explicit Deny?
                   ├── Yes → DENY
                   └── No
                        │
                   SCP allows?  (Organization level)
                   ├── No  → DENY
                   └── Yes
                        │
                   Permission boundary allows?
                   ├── No  → DENY
                   └── Yes
                        │
                   Identity policy allows?
                   ├── No  → DENY (implicit)
                   └── Yes → ALLOW

Federation

| Method | Protocol | Use Case | |--------|----------|----------| | SAML 2.0 | XML-based SSO | Enterprise IdP (Okta, Azure AD) | | OIDC | JWT tokens | Web identity (Google, GitHub) | | AWS SSO / IAM Identity Center | Multi-account | Centralized access to AWS accounts | | Workload Identity Federation | Token exchange | GCP: K8s pods, GitHub Actions, AWS |

Least Privilege Best Practices

Start with zero permissions and grant only what is needed
Use IAM Access Analyzer to identify unused permissions
Scope to specific resources rather than wildcards (*)
Use conditions (source IP, MFA, tags) to narrow access
Prefer roles over long-lived credentials (no access keys when possible)
Set permission boundaries to limit maximum permissions delegatable

Secrets Management

AWS KMS (Key Management Service)

Envelope Encryption:
┌──────────────────────────────────────────────┐
│  KMS Master Key (never leaves KMS HSM)       │
│       │                                       │
│       ▼  GenerateDataKey                     │
│  ┌──────────┐    ┌──────────────────────┐    │
│  │ Data Key │───►│ Encrypt your data    │    │
│  │(plaintext)│   │ with the data key    │    │
│  └──────────┘    └──────────────────────┘    │
│       │                                       │
│  ┌──────────┐    ┌──────────────────────┐    │
│  │ Data Key │    │ Store encrypted data │    │
│  │(encrypted)│──►│ + encrypted data key │    │
│  └──────────┘    └──────────────────────┘    │
└──────────────────────────────────────────────┘

Customer-managed keys (CMK): Full control over rotation, policies, grants
AWS-managed keys: Automatic rotation, simpler management
Automatic rotation: Every year for symmetric keys
Key policies: Resource-based policies controlling key usage

HashiCorp Vault

App ──► Vault API ──► Auth Backend ──► Policy Check ──► Secret Engine
                      (AppRole,         (path-based      (KV, AWS, DB,
                       K8s, OIDC)       ACL)              PKI)

Dynamic secrets: Generate short-lived credentials on demand
Secret engines: KV store, AWS/GCP/Azure credential generation, PKI, databases
Lease management: Automatic revocation after TTL expiry
Transit engine: Encryption as a service without exposing keys

Cloud-Native Secrets

| Service | Provider | Integration | |---------|----------|-------------| | Secrets Manager | AWS | RDS rotation, Lambda integration | | Secret Manager | GCP | Versioning, IAM-based access | | Key Vault | Azure | Certificate management, HSM-backed | | Parameter Store | AWS | Free tier, hierarchical, less features |

Kubernetes Secrets

# External Secrets Operator - syncs cloud secrets to K8s
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: db-credentials
  data:
    - secretKey: password
      remoteRef:
        key: production/database
        property: password

Encryption

At Rest

| Layer | Mechanism | Control | |-------|-----------|---------| | Storage-level | Provider-managed encryption | Transparent, always on | | Server-side (SSE) | KMS-managed or customer keys | Key policy control | | Client-side | Application encrypts before upload | Full control, provider never sees plaintext |

In Transit

TLS 1.2/1.3 for all API calls and data transfer
Certificate management: ACM (AWS), Certificate Manager (GCP), managed certs
mTLS: Mutual authentication between services (service mesh)
VPN/Direct Connect: Encrypted tunnels for hybrid connectivity

Encryption Decision Matrix

Who manages the key?
  └─ Provider → SSE-S3, Google-managed, Azure-managed
  └─ You (cloud KMS) → SSE-KMS, CMEK
  └─ You (on-prem) → SSE-C, CSEK, client-side encryption

Where does encryption happen?
  └─ Provider-side → Server-side encryption (SSE)
  └─ Client-side → Client-side encryption (CSE)
       → Provider never sees plaintext data

Compliance Frameworks

Common Standards

| Standard | Scope | Key Requirements | |----------|-------|-----------------| | SOC 2 | Service organizations | Security, availability, confidentiality, privacy | | HIPAA | Healthcare data (US) | PHI protection, BAA required, audit trails | | PCI-DSS | Payment card data | Network segmentation, encryption, access control | | GDPR | EU personal data | Consent, right to erasure, data portability | | FedRAMP | US government cloud | NIST 800-53 controls, continuous monitoring | | ISO 27001 | Information security | ISMS framework, risk management |

Shared Compliance Responsibility

Provider certifies: Physical security, infrastructure, managed service security
Customer implements: Application security, data classification, access controls
AWS Artifact / GCP Compliance Reports: Download provider compliance documentation

Compliance Tools

AWS Config: Evaluate resource configurations against rules
Azure Policy: Enforce organizational standards
GCP Organization Policy: Constraints on resource configurations
AWS Audit Manager: Automate evidence collection for audits

Cloud Security Posture Management (CSPM)

CSPM tools continuously assess cloud environments for misconfigurations and compliance violations.

Common Misconfigurations Detected

Critical findings:
  ✗ S3 bucket with public access
  ✗ Security group allowing 0.0.0.0/0 on SSH (port 22)
  ✗ Unencrypted EBS volumes or RDS instances
  ✗ IAM users with unused access keys > 90 days
  ✗ Root account without MFA
  ✗ CloudTrail logging disabled

CSPM Tools

| Tool | Type | Coverage | |------|------|----------| | AWS Security Hub | Native | AWS resources, integrates CIS benchmarks | | GCP Security Command Center | Native | GCP resources, threat detection | | Microsoft Defender for Cloud | Native | Azure + multi-cloud | | Prowler | Open source | AWS, GCP, Azure CIS benchmarks | | Wiz | Commercial | Agentless, multi-cloud, graph-based | | Orca Security | Commercial | Agentless, side-scanning |

Container Security

Supply Chain Security

Build Phase                    Deploy Phase               Runtime
├── Base image scanning        ├── Admission control      ├── Runtime detection
│   (Trivy, Grype)            │   (OPA/Kyverno)          │   (Falco)
├── Dependency scanning        ├── Image signing           ├── Network policies
│   (Snyk, Dependabot)       │   (Cosign/Sigstore)      │   (Calico, Cilium)
├── SAST in Dockerfile        ├── Pod security standards  ├── Read-only rootfs
└── SBOM generation           └── Registry allowlisting   └── Seccomp/AppArmor
    (Syft)

Container Best Practices

Use minimal base images (distroless, Alpine, scratch)
Run as non-root user inside containers
Scan images in CI/CD before pushing to registry
Sign images with Cosign and verify at admission
Drop all capabilities and add only what is needed
Use read-only root filesystem where possible
Set resource limits to prevent resource abuse

Audit Logging

AWS CloudTrail

Records all API calls across AWS services
Management events: Control plane operations (create, delete, modify)
Data events: Data plane operations (S3 GetObject, Lambda Invoke)
Insights events: Detect unusual API activity patterns
Store in S3 with integrity validation; query with Athena

Multi-Cloud Logging

| Provider | Service | Scope | |----------|---------|-------| | AWS | CloudTrail | API audit log | | AWS | VPC Flow Logs | Network traffic metadata | | GCP | Cloud Audit Logs | Admin, data, system events | | Azure | Activity Log / Diagnostic Logs | Management + data plane |

Security Event Pipeline

CloudTrail ──► S3 ──► EventBridge ──► Lambda ──► SIEM
    │                                              │
    └── CloudWatch Logs ──► Metric Filters ──► Alarm
                                                   │
                                               SNS/PagerDuty

Key Takeaways

IAM is the most critical security control; enforce least privilege with roles, not users
Secrets belong in dedicated management services, never in code or environment variables
Encryption at rest and in transit should be enabled by default for all resources
Compliance is a shared responsibility; automate evidence collection and continuous monitoring
CSPM tools catch misconfigurations before attackers exploit them
Container security spans the entire lifecycle: build, deploy, and runtime
CloudTrail and equivalent audit logs are essential for incident investigation