Security and Identity (IAM, Security Monitoring, Key Management)
Domain 5 - Security and Identity
Expect least-privilege policy design, key management, and detection/response controls.
Core rules
- IAM has a main account, sub accounts, groups and policies. Policies are documents granting actions on resources; managed policies cover common roles, user-defined policies cover the rest. Permission is deny-by-default.
- Sub accounts can have console access, API access keys, MFA and IP ACLs. Rotate access keys and never ship the main account key into CI.
- KMS stores customer master keys used for envelope encryption; Object Storage and Block Storage can encrypt with KMS keys. Key rotation and scheduled deletion are part of the lifecycle.
- Secret Manager stores credentials and API keys for applications; Certificate Manager and Private CA handle TLS certificates.
- Security Monitoring combines intrusion detection, WAF for web traffic and Anti-DDoS; File Saver scans uploaded files and App Saver hardens mobile apps.
Worked example
A CI pipeline must push images and deploy to NKS. Reasoning: create a sub account for CI, attach a policy limited to registry push/pull actions and to the specific cluster, store the access key in Secret Manager rather than pipeline YAML, and keep MFA on human accounts while the automation identity uses only its scoped key. A wildcard policy is rejected because one leaked key would then own the account.
Traps
- Granting Administrator to avoid policy debugging.
- Assuming Anti-DDoS removes the need for WAF rules.
- Deleting a KMS key that encrypted data still depends on - that data becomes unreadable.
- Hard-coding access keys in source, images or init scripts.