IAM & Security

An IAM policy statement combines Effect (Allow or Deny), Action, Resource ARNs and an optional Condition. Principal appears only in resource-based policies, because an identity-based policy is already attached to the principal it applies to.

Identity-based policies are the default and scale per principal. A resource-based policy is required when the caller is outside the account, when an AWS service principal must be granted access, or when a rule must apply to every caller of that one resource.

Managed policies are standalone objects with an ARN that attach to many principals and keep prior versions; AWS managed ones are maintained by AWS and usually too broad. Inline policies are embedded in a single principal, have no ARN, and are deleted with it.

IAM condition keys exist only if the request actually carries them. A condition on a key absent from the request context evaluates false, so the statement does not match — harmless for an Allow, but a Deny that never fires. IfExists and the Null operator test presence explicitly.

An AWS service principal is the same identity for every customer, so granting it alone lets the service act on your resource on anyone's behalf. Narrow the grant with aws:SourceArn for the specific calling resource and aws:SourceAccount for the account that owns it.

Every AWS request starts denied. An implicit deny is simply the absence of any matching Allow, and adding an Allow fixes it. An explicit Deny is a statement with Effect Deny, and no Allow anywhere can override it.

AWS gathers every applicable policy, then denies if any of them contains a matching explicit Deny. Otherwise the request must survive each guardrail that applies — SCP, permissions boundary, session policy — and be allowed by an identity-based or resource-based policy; anything else is an implicit deny.

Cross-account access needs an allow on both sides: the caller's identity policy in account A and the resource's own policy in account B. Within a single account the two are a union, so one allow suffices — which is why the same policy works locally and fails across accounts.

Something is restricting rather than failing to grant: an explicit Deny in any applicable policy, or a guardrail that the action falls outside of — a service control policy, a permissions boundary, or a session policy. All of these subtract from what identity policies grant, so more Allows change nothing.

Point simulate-principal-policy at the caller's ARN with the exact action, resource ARN and any request conditions; the result reports allowed, implicitDeny or explicitDeny plus the statements that matched. It reasons over the policies you give it, not over the live request, so treat an allow as a hypothesis.

Effective permissions are the intersection of the two, so the role can call only S3 and CloudWatch actions. A permissions boundary never grants anything, so with the boundary alone and no identity policy the role could do nothing.

All three are caps and none grants anything. A permissions boundary attaches to one IAM user or role, an SCP attaches to an organization root, OU or account, and a session policy is passed at AssumeRole time and lives only for that session.

Grant the IAM write actions only with a StringEquals condition on the iam:PermissionsBoundary key naming your boundary policy, so every role they create carries the cap. Then explicitly deny removing or replacing that boundary, editing the boundary policy itself, and passing roles they should not.

Separate accounts give hard isolation of blast radius, quotas and billing with guardrails teams cannot lift, at the cost of account sprawl and cross-account plumbing. Permissions boundaries are cheaper and finer-grained but sit inside one account, so they cap identities without isolating resources.

An IAM user's access keys are permanent static secrets belonging to one identity. A role owns no credentials: an allowed principal calls STS AssumeRole and receives a temporary access key, secret and session token that expire on their own.

The trust policy is the role's resource policy: it names the principals allowed to call sts:AssumeRole on it. The permissions policies say what the resulting session may do. A denial on sts:AssumeRole points at the trust policy; any later denial points at the permissions policies.

It returns the Account, UserId and Arn that AWS attributes to the credentials just used. For a role session the Arn has the form arn:aws:sts::<account>:assumed-role/<RoleName>/<SessionName>, naming the role and the session rather than any user.

It stops one of the vendor's other customers from making the vendor use your role on their behalf. The vendor generates a unique ExternalId per customer and passes it on AssumeRole; your trust policy accepts only that value, so a role ARN alone is not enough to be acted on.

Check whether the job requested a longer DurationSeconds at all, whether it is role chaining — assuming a second role from the first role's credentials caps the session at one hour — and whether the credentials were captured once into environment variables so nothing can refresh them.

Attach an IAM role to the instance through an instance profile — a container object that holds exactly one role. EC2 then publishes temporary credentials for that role on the Instance Metadata Service, and the AWS SDK fetches and refreshes them automatically.

The task execution role belongs to the ECS agent and Fargate infrastructure: pulling the image, writing logs, injecting secrets before the container starts. The task role is the application's own identity for AWS API calls at runtime. Missing execution-role permissions fail the start; missing task-role permissions cause AccessDenied inside the app.

The chain walks from most explicit to most ambient: credentials passed in code, then environment variables, then the shared config and credentials files, then container or instance metadata last. Anything left in the environment or a baked profile therefore silently outranks the workload's attached role.

iam:PassRole authorises handing an existing IAM role to an AWS service so that service can assume it. It is separate because creating a resource and choosing its identity are different powers: without it, anyone able to launch compute could attach an admin role and inherit its permissions.

IRSA registers the cluster's OIDC issuer as an IAM identity provider and each role trusts that provider with a condition on the service account subject. Pod Identity instead trusts the pods.eks.amazonaws.com service principal and maps roles through an association, so roles need no per-cluster trust edits.

IAM Identity Center centralises workforce sign-in: each engineer exists once in one identity source, is assigned permission sets per account, and receives short-lived credentials at login instead of access keys that live on a laptop forever.

A permission set is a reusable policy template — managed policies, customer managed policy references, an inline policy, an optional boundary and a session duration. Assigning it provisions an IAM role named AWSReservedSSO_<name>_<suffix> in the target account.

Register token.actions.githubusercontent.com as an IAM OIDC identity provider, create a role that trusts it for sts:AssumeRoleWithWebIdentity, and condition the trust policy on both the aud claim and the sub claim so only your repository and branch can assume it.

Set the external provider as the identity source: SAML 2.0 carries authentication at sign-in, SCIM 2.0 provisions and deprovisions users and groups. Assign permission sets to synced groups, and keep session durations short because existing sessions survive deprovisioning.

aws configure sso writes an sso-session block plus a profile naming an account and permission set. aws sso login opens a browser sign-in and caches a short-lived SSO token locally; the CLI exchanges that token for temporary role credentials per command.

A Cognito user pool sign-in returns an ID token, an access token and a refresh token. Your API should accept the access token, which carries scopes and group claims; the ID token describes the user to the client, and the refresh token only obtains new tokens.

A Cognito user pool is the user directory: it authenticates people and returns JWTs. An identity pool is a credential broker: it takes a token you already have and exchanges it for temporary AWS credentials tied to an IAM role. Many apps use both, and some use only one.

Check that iss names your pool, that token_use matches the token type you expect, and that the audience claim — aud on an ID token, client_id on an access token — is your app client. Offline verification cannot see revocation, disabled users or changed groups until the token expires.

Decide on how much you need to enforce per request. Identity pool credentials remove a hop and scale for free, but every rule must be expressible in an IAM policy — so the role must confine each user to their own key prefix using the identity's subject as a policy variable. Anything beyond that argues for your own API.

Cognito created a second, separate user in the pool for the Google identity, with its own sub, so your application saw a new customer. Fix it by linking the federated identity to the existing native user with the AdminLinkProviderForUser API, and only after proving the two really are the same person.

In AWS Organizations one management account creates the organization, pays every bill and cannot be restricted by service control policies; the rest are member accounts holding workloads. OUs group accounts so one attached policy applies to all beneath.

A service control policy only sets a ceiling on what an account may be allowed to do; it never grants anything. Allowing s3:* merely leaves S3 inside the ceiling — some IAM policy still has to actually grant the S3 permission.

A deny list keeps the default FullAWSAccess policy and adds targeted Deny statements for a few forbidden things. An allow list detaches FullAWSAccess and enumerates every permitted service — tighter, but it blocks any service nobody remembered to list.

Service control policies never restrict principals in the management account, no matter where the policy is attached. Because the organization's own guardrails do not apply there, the management account should hold no workloads and very few principals.

Split by blast radius and governance rather than by team: an empty management account, a Security OU with log archive and audit accounts, shared infrastructure, and separate production and non-production workload accounts under OUs that carry the guardrail SCPs. Control Tower assembles and maintains that baseline for you.

Call kms:GenerateDataKey. KMS returns one data key twice, as plaintext and encrypted under your KMS key. Encrypt the file locally with the plaintext copy, wipe it from memory, and store the encrypted copy beside the ciphertext.

Every KMS key has a mandatory key policy, and it is the root of authority for that key. An IAM policy grants nothing unless the key policy also allows the principal, either directly or through its default statement that delegates to IAM.

They differ in who controls the key policy. AWS owned keys are invisible and shared across customers. AWS managed keys appear in your account under aws/ aliases but their policy is fixed. Only customer managed keys let you set policy, rotation and deletion.

KMS generates new backing key material and uses it for new encrypt operations. The key ID, ARN and alias are unchanged, old backing keys are retained so existing ciphertext still decrypts, and nothing is re-encrypted. Manual rotation means a new key plus an alias repoint.

Granularity follows the blast radius and erasure requirements, then is checked against cost and quota. Per-tenant keys buy isolation and cryptographic erasure; a shared key with per-tenant encryption context and grants buys the same authorization boundary far more cheaply.

AWS at-rest encryption protects bytes on the storage media — decommissioned drives and raw copies taken outside the service API. It stops nothing at the API layer: the service decrypts transparently for any caller whose IAM and key permissions allow the read.

Attach a resource policy statement that denies every action when the global condition key aws:SecureTransport is false. It is a boolean AWS sets per request, true only when the request reached the AWS endpoint over TLS, so the deny turns plain-HTTP access into an error rather than a lapse.

Reading KMS-encrypted data needs a second authorization — kms:Decrypt on the key — and a KMS key policy is evaluated independently of S3's policies. Account A's key policy does not name the role in account B, so the decrypt is denied and S3 surfaces AccessDenied.

A customer managed key gives you an editable key policy, so you can grant, condition and revoke use independently of the service's own permissions, share with other accounts, and audit every use. The cost is a monthly key charge, per-request charges, and a hard availability dependency on that policy staying correct.

Stack three layers: service defaults so the encrypted path is the easy one, preventive organization policies that deny creation when an encryption condition key is false, and detective scanning for the gaps and the backlog. Only the preventive layer, which binds account admins too, supports a guarantee.

Secrets Manager buys managed rotation, a resource policy on the secret for cross-account reads, and cross-Region replication, and charges per secret per month. SSM Parameter Store is free at standard tier and fits plain config, with SecureString when a value must be encrypted.

A SecureString parameter is encrypted with a KMS key instead of being stored in the clear. Reading the plaintext needs two things: the GetParameter call must ask for decryption via WithDecryption, and the caller's IAM policy must allow kms:Decrypt on the key as well as ssm:GetParameter.

Every invocation pays a network round trip and a KMS decrypt, the API calls are billed per request, and at high concurrency the account starts getting throttled. Cache the value per execution environment with a bounded lifetime, and refetch on an authentication failure so rotation still lands.

Secrets Manager versions a secret and moves staging labels between versions. AWSCURRENT is what readers get by default, AWSPENDING is the candidate being rotated in, AWSPREVIOUS is the last good one. The rotation function runs createSecret, setSecret, testSecret and finishSecret.

An environment entry stores the literal value in the task definition, visible to anyone who can describe it. A secrets entry stores only an ARN, and the agent resolves it at task start using the task execution role. Rotation does not reach running tasks; they keep the value injected at launch.

CloudTrail records management events (control-plane calls such as PutBucketPolicy) by default, but data events — S3 object-level GetObject and PutObject, Lambda Invoke, DynamoDB item operations — are off unless you explicitly enable them, and they are billed per event.

The IAM credential report is an account-wide CSV listing every IAM user and the root user, with password state, access-key rotation and last-used dates, and MFA status. One download answers stale-credential and root-MFA questions.

Use three evidence sources: IAM service last-accessed data (Access Advisor) for which services the role touched and when, IAM Access Analyzer to generate a policy from CloudTrail history and to flag unused access, and the CloudTrail record itself for individual calls.

Create a multi-region organization trail from the management or delegated administrator account: member accounts cannot stop or delete it. Deliver to an S3 bucket in a separate log-archive account whose write path the workload administrators do not control, with integrity validation on.

With log file integrity validation on, CloudTrail delivers hourly digest files that hash each delivered log file and chain to the previous digest, signed by AWS. Validation detects modified, deleted or inserted files — it does not prove every API call was logged.

GuardDuty detects active threats from AWS logs, AWS Config records resource state and flags drift from rules, Amazon Inspector scans workloads for known CVEs, and Macie finds sensitive data in S3. Security Hub aggregates all of their findings.

GuardDuty reads AWS-side telemetry directly from the service plane: CloudTrail management and S3 data events, VPC Flow Logs, and Route 53 Resolver DNS query logs. It gets its own independent copy, so you neither enable nor pay for those logs.

AWS Config records a configuration item whenever a resource changes, then evaluates rules against it — triggered by the change or on a schedule — marking resources COMPLIANT or NON_COMPLIANT. Attaching a remediation action runs an SSM Automation runbook to fix them.

Security Hub uses an Organizations delegated administrator with member accounts auto-enabled, plus a designated aggregation Region that collects findings from linked Regions. Its standards controls are largely evaluated through AWS Config, so Config recording must be on.

Enable through Organizations with a delegated security account and auto-enable for new accounts, cover every allowed Region, and treat AWS Config's recorder scope and Macie's scan targets as the main cost dials. Suppress known exceptions at ingestion, not by ignoring dashboards.

AWS IAM users are identities with long-lived credentials, groups are policy-carrying containers of users, and roles are identities that anything trusted can take on to get expiring credentials. Roles are preferred because nothing permanent is left lying around to leak.