Cloud Identity, Service Principals, and Managed Identities
Summary
This note explains the difference between human identity, workload identity, and cloud-managed identity. The goal is to make access design in AWS or Azure easier to reason about before touching policy or deployment details.
Why this matters
- cloud access becomes confusing when people and workloads are treated like the same type of identity
- many deployment problems are really identity problems in disguise
- a cleaner model helps with least privilege, secrets handling, and troubleshooting
Environment / Scope
| Item | Value |
|---|---|
| Topic | cloud identity model |
| Best use for this note | understanding who or what is acting in cloud operations |
| Main focus | human identities, service identities, managed identities |
| Safe to practise? | yes |
Core distinction
| Identity type | What it represents | Typical use |
|---|---|---|
| Human identity | a real administrator, engineer, or support user | portal access, CLI work, approvals, troubleshooting |
| Service principal / application identity | an app or automation acting against cloud APIs | CI/CD, deployment tooling, automation workflows |
| Managed identity | a cloud-managed workload identity attached to a resource | app-to-resource authentication without storing secrets manually |
Mental model
Think about access like this:
person signs in -> operates manually
pipeline or app acts -> needs non-human identity
cloud resource needs API access -> managed identity is often the safer pathThe main question is always: who or what is actually making the request?
Everyday examples
| Situation | Better identity model |
|---|---|
| engineer runs Terraform locally | human identity with the right role or scoped credentials |
| GitHub Actions deploys infrastructure | service principal or equivalent workload identity |
| web app needs to read a secret or talk to storage | managed identity if the platform supports it |
| support engineer checks a failed deployment | human identity for investigation, not app credentials |
Common misunderstandings
| Misunderstanding | Better explanation |
|---|---|
| ”The app can just reuse my account” | workloads should not depend on human identities |
| ”A service principal is the same thing as a user” | it is a non-human identity used by automation or apps |
| ”Managed identity is just another secret” | its value is that secret handling is reduced or abstracted away |
| ”If access fails, the app must be broken” | identity scope or missing role assignment may be the real cause |
Decision test
Ask these questions:
- is the actor a person or a workload?
- does this access need to exist continuously or only during deployment?
- can the platform provide a managed identity instead of stored credentials?
- what is the narrowest role or permission path that still works?
Key takeaways
- human access and workload access should be modelled separately
- service principals and managed identities solve different but related problems
- identity design affects security, troubleshooting, and operational clarity