Security, cost and GPUs
IAM and least privilege
How cloud identity works, why least privilege is a habit rather than a checkbox, and where the org-level guardrails sit. Start here for the map of IAM pages.
Every cloud API call asks one question: who is asking, and are they allowed to do this? Identity and Access Management (IAM) is the system that answers it. Many well-known cloud breaches were not clever attacks. They came from roles that could do far more than they needed, or from keys that lived far longer than anyone meant them to.
Authentication (proving who you are) and authorization (what you may do) are covered in authn and authz. This topic shows how those ideas appear in AWS and GCP.
The core idea
Every cloud decision has three parts:
- Who is asking (the principal).
- What they want to do (the action).
- On what (the resource).
Conditions such as source network, MFA or tags narrow the answer. Everything else is detail on top of those three.
Read in order
| Step | Concept | What it answers |
|---|---|---|
| 1 | How IAM decides allow or deny | Why does a call fail even when a policy says allow? |
| 2 | Least privilege in practice | How do you shrink a role without breaking the job? |
| 3 | Workload identity | How does a running app get cloud access without a stored key? |
| 4 | Org guardrails and human access | How do people log in, and how do org policies cap every admin? |
Common mistakes across the topic
- Pasting
*to clear a ticket. A wildcard is easy to write and hard to revoke once something depends on it. - Long-lived keys in CI or on laptops. Keys leak through logs, forks and phishing. Use federation instead.
- Public storage. Treat any
Principal: "*"on a storage resource as an incident until someone proves it was intended. - Shared admin for "just this once." No one can be traced, and the privilege never goes away.
- Trusting the network. Being inside the VPC is not authorization.
Zero trust in one paragraph
Classic security trusted anything inside the VPN. Zero trust assumes the network is hostile. Every request authenticates the user and device, is checked against policy, and is encrypted. Google's BeyondCorp model works this way: employees reach internal apps without a VPN, and a proxy checks identity and device health first. You do not need a rewrite on day one. You do need to stop treating network location as permission.
Key takeaways
- IAM answers who, what and on which resource for every cloud call.
- An explicit deny always wins, and a request still needs an allow.
- Least privilege is iterative: start narrow, use real usage data, then prune.
- Workloads should get short-lived credentials. Humans should log in through SSO.
- The famous breaches are mostly boring: over-privileged roles, public storage and leaked static keys.
Further learning
Start with the policy evaluation page, then work down the table. The AWS guide is the reference for principals, policies and evaluation logic.
AWS IAM User GuideLearn about AWS Identity and Access Management (IAM), its features, and basic concepts.docs.aws.amazon.com BeyondCorp (Google)BeyondCorp is an enterprise security model that allows employees to work more securely from any location without the need for a traditional VPN.Google Cloud
A talk on temporary credentials, least privilege as a journey, and Access Analyzer in practice:
Related
Authentication and authorization
Authentication proves who you are, authorization decides what you can do, and service-to-service calls need their own identity. The map for the rest of this topic.
Secrets management and encryption
Keeping credentials out of code and data safe at rest and in transit with KMS, Vault and envelope encryption — plus how to catch leaks before they become incidents.
Cloud networking and VPCs
VPCs, subnets, routing, NAT, security groups and private connectivity in AWS and GCP, plus a three-AZ reference architecture and how to debug when A cannot reach B.