Cloud security basics · Lesson 5 of 5
Give applications their own identity
An application may need cloud access even when no person is signing in. A workload identity gives that application its own permissions instead of borrowing a developer’s credentials.
Give the job its own access
Fictional nightly reporting workload.
- Approved workload
Trust policy or equivalent identifies which job may use the role.
- Workload role
Issues scoped, temporary credentials where supported.
- Required resources
Read one input location and write one output.
Read the visualWhat if the credentials expire quickly but can administer everything?
The permissions are still too broad. Limit the workload’s allowed actions and resources.
Separate the actors
Use an identity for the service so its permissions and activity can be managed independently of a person’s account.
Prefer temporary credentials
Where supported, use roles or workload identity mechanisms that issue short-lived credentials. Avoid embedding a personal access key in a deployment.
Limit both trust and permissions
Specify which workload may use the identity, and what that identity may do. Temporary credentials can still be too powerful if their permissions are broad.
Put it in context
A fictional nightly report job needs to read one storage location and write one output. The team assigns a narrowly scoped role to the job. When a developer leaves, the job does not depend on that developer’s personal key. Its access can be reviewed separately.
Give the workload an identity, a limited job, and a limited permission set.
Read the sources
Make it stick.
Try one short question to check your understanding and save this lesson to your progress.