Identity
Part of Cloud identity and access
Managing service identities separately from employee access
Give applications owned identities, choose supported authentication, limit runtime access and retire identities with their workloads.
Give an application or automated job an identity owned with its workload. Record its purpose, permissions and authentication method separately from employee access. A script tied to an employee login may lose access when that person leaves, while its continuing use can be hard to account for.
Keep a workload identity register
For each identity, record the application, environment, business and technical owners, where it runs, target resources and required actions. Include its authentication method and retirement path. Review shared identities carefully: combining applications with different owners or lifecycles can make access and activity harder to attribute.
Google Cloud describes service accounts as resources belonging to a project as well as principals that can be granted access, and advises limiting their privileges.
Choose authentication for the actual path
AWS recommends IAM roles with temporary credentials for workloads accessing AWS resources. Azure managed identities can obtain Microsoft Entra tokens without the application owner managing credentials when the source and target support that path. The target still authorises the identity's access. Microsoft describes managed identities as best for communications among services that support Microsoft Entra authentication.
For Google Cloud workloads, use a more secure authentication method than a service-account key where possible. Google recommends avoiding service-account keys whenever possible. Check support for the exact workload and target before choosing.
| Method | Question to answer | Continuing duty |
|---|---|---|
| Temporary role credentials | Can this workload obtain them from its provider or federation path? | Limit and review the role |
| Managed identity | Do the source and target support the identity path? | Limit target access and manage the identity lifecycle |
| Long-lived key or secret | What compatibility need rules out a shorter-lived method? | Protect, replace and retire the credential |
If a long-lived credential remains necessary, keep it in an approved protected store, restrict retrieval and record a replacement procedure.
Authentication Methods for Cloud Workloads
- Temporary Role CredentialsCan be obtained from provider or federation path; requires role limitation and regular review
- Managed IdentityRequires source and target support Microsoft Entra authentication; access must be limited and lifecycle managed
- Long-Lived Key or SecretOnly use if compatibility prevents shorter-lived options; must be stored securely, replaced regularly, and retired with a plan
Separate deployment from runtime access
A developer may need to deploy an application without personally holding its runtime credential. Grant the deployment process its required actions and the running application only its runtime actions. Review who can assign or impersonate the workload identity, since that route can confer its effective access.
When an employee leaves, remove their own access and inspect deployment and credential-management permissions they held. Keep a service identity while the application still needs it, with a current owner.
When the workload ends, disable its identity and retire its keys and grants through a controlled change. For Azure managed identities, Microsoft says identities are provided and deleted with Azure resources, so include the resource lifecycle in the retirement plan.
Check both normal and scheduled application work after an identity change.
