Skip to main content

Identity, access, and secrets

In modern cloud environments, identity serves as the primary security perimeter. Every interaction with a cloud platform—whether an engineer deploying infrastructure, a compute instance reading an object from a bucket, or a serverless function publishing an event to a queue—is an authenticated API call evaluated against granular authorization policies. Even the most robust private network topology cannot protect an infrastructure estate if identity policies grant excessive administrative privileges.

Structuring identity, access control, and secrets correctly guarantees that compromised components have a strictly confined blast radius.

Identities​

A cloud provider's (IAM) service oversees two distinct categories of principals:

  • Human identities: Represent individual engineers, operators, and administrators. Organizations should federate human access directly from enterprise identity providers using SAML 2.0 or OpenID Connect (OIDC). This guarantees that Multi-Factor Authentication (MFA) is enforced globally and that employee departure immediately revokes all cloud privileges across every environment.
  • Service identities: A (such as an IAM role or service account) belongs to an autonomous software workload—such as a virtual machine, a container pod, or a serverless function. Service identities do not possess passwords and authenticate using temporary cryptographic tokens issued directly by the cloud control plane.

Workloads should never execute using human credentials, and engineers should never perform interactive tasks using service account keys. Pledging credentials between human and machine contexts obscures audit trails and leads to orphaned access that persists indefinitely.

Policies and least privilege​

A is a declarative document defining which actions an identity is authorized to execute against specific resource targets. Cloud policy engines evaluate permissions on an implicit default-deny basis: any action not explicitly granted by an allow rule is forbidden, and an explicit deny always overrides any matching allow.

The foundational principle of cloud security is : granting an identity only the exact permissions necessary to accomplish its intended function, and nothing more. For instance, a background worker responsible for processing image uploads should receive read access exclusively to the incoming upload bucket and write access to the processed thumbnail bucket, rather than broad administrative rights across all storage resources.

While cloud providers provide broad, pre-packaged administrative roles to simplify initial setup, using these wildcard roles in production represents a severe security risk. A service identity configured with administrator privileges grants an attacker complete operational control if that specific service is ever compromised.

Granting access to a workload

Assign dedicated, tightly scoped service identities to each application component.

  1. Provision a unique service identity for the specific workload rather than sharing credentials across components.
  2. Draft an explicit policy defining only the exact API actions and resource identifiers the service requires.
  3. Attach the policy directly to the identity, avoiding wildcard permissions and broad administrator roles.
  4. Periodically audit access logs and revoke unused permissions as service responsibilities evolve.

Workload identity versus static access keys​

Historically, software running on servers authenticated to cloud APIs using long-lived pairs (a public key ID and a private secret). However, static keys represent a significant security risk: they are frequently committed to source code repositories, embedded in container image layers, or stored unencrypted on developer laptops where they remain unrotated for months or years.

Modern cloud architectures eliminate static credentials in favor of . Under this model, compute platforms leverage local metadata services or Kubernetes projected service account tokens to request short-lived, dynamically rotated authorization tokens from the cloud provider. The platform refreshes these credentials automatically before they expire. Because no static secrets are written to persistent storage, there are no credentials for attackers to exfiltrate.

When external workloads (such as third-party CI/CD runners) need to authenticate to cloud resources, configuring OIDC federation allows those external systems to exchange temporary identity tokens for short-lived cloud credentials, completely eliminating the need for static access keys.

Secrets management​

Applications inevitably require access to third-party API tokens, database passwords, and private signing keys that cannot be modeled as cloud IAM identities. These sensitive assets belong in a dedicated .

A secrets manager stores sensitive strings encrypted at rest, audits every read request, and orchestrates automated rotation schedules for database credentials. Workloads authenticate to the secrets manager at startup using their workload identity, retrieve required credentials into memory, and avoid writing plaintext secrets to disk or configuration files.

Encryption and key management​

Cloud providers encrypt data at rest by default using platform-managed keys. For sensitive or highly regulated datasets, organizations use a (KMS) to maintain Customer Managed Encryption Keys (CMEK).

KMS platforms utilize Hardware Security Modules (HSMs) and envelope encryption, where local data encryption keys are protected by root keys stored within the KMS. This architecture introduces a secondary authorization gate: accessing encrypted data requires explicit IAM permissions on both the storage resource and the underlying cryptographic key. Data in transit is protected using TLS 1.3, terminating on managed load balancers and private service endpoints.

Immutable audit logging​

Cloud control planes record every administrative and data-plane API call in centralized audit logs—capturing timestamps, calling identities, source IP addresses, and request parameters. These audit logs are vital for forensics during security incidents and for validating regulatory compliance. Audit trails should be routed to a dedicated, locked-down security account with write-once-read-many (WORM) storage to prevent compromised credentials from altering or deleting their own activity records.

Multi-account governance​

Hosting all environments within a single cloud account creates an unmanageable blast radius where a single mistake can impact the entire organization. Modern enterprises structure their cloud footprint across multiple isolated accounts or projects organized under a centralized parent organization.

Separating environments (such as development, staging, and production) into distinct accounts provides strong isolation boundaries: quotas are independent, networks are decoupled, and IAM policies cannot cross account boundaries without explicit trust relationships. Organizational guardrail policies enforced at the parent root establish non-bypassable constraints, preventing individual accounts from disabling audit logging or creating unencrypted storage buckets.

Terms introduced​

  • Identity and access management: the provider's service holding identities and the policies that bind them to actions on resources.
  • Service identity: an identity belonging to a piece of software rather than a person.
  • Policy: a statement of which identity may do which actions on which resources.
  • Least privilege: giving an identity the permissions its job needs and nothing more.
  • Workload identity: short-lived credentials issued to a workload automatically, with nothing to store.
  • Access key: a long-lived static credential that must be stored, and so can leak.
  • Secrets manager: a store that keeps secrets encrypted, logs reads, and hands values only to allowed identities.
  • Key management service: a service that holds encryption keys and controls which identities may use them.

How providers do it

Identity and access management systems enforce access control across all three clouds through three core components: an authenticated principal, a defined set of permissions, and an architectural scope where those permissions take effect.

ConceptAWSAzureGoogle Cloud
Identity and access managementAWS IAMMicrosoft Entra ID with Azure RBACGoogle Cloud IAM
Human administrative identityIAM Identity Center permission setEntra ID tenant userCloud Identity or Google Workspace account
Machine service identityIAM roleManaged identity, App registration service principalService account
Access policy definitionJSON policy statement (Actions, Resources, Conditions)Role definition assigned at a management scopeIAM policy binding roles to members on a resource
Dynamic workload identityEC2 instance profile, EKS Pod IdentityAzure Managed Identity, Entra Workload IDAttached service account, Workload Identity Federation
Static access credentialLong-lived IAM user access keysApp registration client secrets, storage access keysService account JSON private key files
Encrypted secrets vaultAWS Secrets Manager, SSM Parameter StoreAzure Key VaultGoogle Cloud Secret Manager
Cryptographic key managementAWS Key Management Service (KMS)Azure Key Vault Keys, Azure Managed HSMGoogle Cloud KMS
Control plane audit trailAWS CloudTrailAzure Activity Log, Entra audit logsGoogle Cloud Audit Logs
Organizational governance guardrailsService Control Policies (SCPs)Azure PolicyGoogle Cloud Organization Policies
Resource boundary containerAWS Account (organized under AWS Organizations)Azure Subscription (organized under Management Groups)Google Cloud Project (organized in Folders and Organizations)
Least-privilege policy analyzerAWS IAM Access AnalyzerEntra Access ReviewsGoogle Cloud IAM Recommender

Every product name and technical mapping above is confirmed against official documentation. Automated privilege analysis capabilities and external credential federation limits are detailed in the provider tabs below.

Two policy evaluation and auditing nuances require careful operational attention:

  1. Explicit Deny Precedence: In AWS IAM, an explicit Deny statement in any applicable policy immediately overrides all Allow statements across all evaluation layers. In Google Cloud IAM, standard role bindings only grant permissions (allows); enforcing explicit denials requires configuring specialized Deny Policies, which operate as an independent control plane layer.
  2. Data-Plane Audit Logging: While control plane administrative actions are logged automatically across all platforms, data-plane access (such as reading individual objects from a bucket or querying a database table) is not enabled by default in Google Cloud Audit Logs due to volume considerations. Organizations subject to compliance audits must explicitly enable Data Access audit logs for sensitive services.

What this maps to: AWS IAM holds identities and policies. People signing in from a directory go through IAM Identity Center. Secrets live in Secrets Manager or Systems Manager Parameter Store, keys in AWS KMS, and the audit log is CloudTrail.

ConceptOn AWSStatus
Human identityPreferably a permission set in IAM Identity Center, backed by your directory. IAM users exist but are discouraged for peopleconfirmed
Service identityAn IAM role. Roles are assumed, not logged into, and hand out short-lived credentialsconfirmed
PolicyA JSON document of Allow and Deny statements over actions and resource ARNs. Explicit deny winsconfirmed
Workload identityAn instance profile on EC2, an execution role on Lambda, EKS Pod Identity or IRSA on Kubernetes, a task role on ECSconfirmed
Access keyAn access key ID and secret access key on an IAM user. Rotate, or better, replace with a roleconfirmed
Secrets managerSecrets Manager, with built-in rotation for RDS and a few others. Parameter Store SecureString for cheaper, simpler secretsconfirmed
Key managementKMS. Customer managed keys carry their own key policy, which gates use separately from the resource's policyconfirmed
AuditCloudTrail, per region or as an organisation trail, delivered to S3 with log file validationconfirmed
Organisation-wide guardrailsService control policies (SCPs) in AWS Organizations set the maximum permissions for every identity in an accountconfirmed
Finding over-broad accessIAM Access Analyzer reports resources shared outside the account and unused permissionsconfirmed

Their vocabulary

Standard termTheir term
Service identityRole
Attach an identity to a machineInstance profile
Least privilege reviewAccess Analyzer, unused access findings
Resource nameARN

Where to look

The IAM console's credential report lists every user and how old each key is. When someone asks "who did that", start with CloudTrail Event history.

Last verified: never.

Check your understanding

0 of 4 answered

  1. A function reads one queue. What permission should its identity have?
  2. Why is a workload identity safer than an access key stored on the machine?
  3. A bucket is encrypted with a key you manage rather than the provider's default key. What does that add?
  4. Where should a service get its database password from?