Platform security starts with who may perform which action on which resource and under what conditions. IAM decides permissions for AWS APIs; KMS controls operations on keys and encrypted material under its policies. The application must still authorize business actions. Permission to read an object or decrypt bytes does not prove that those bytes should be delivered to a user.
The goal is to give each actor the access it needs, make usage observable, and preserve recovery compatible with those limits. Encrypting data without preserving secure access to its key can also block restoration.
Identities and roles
A human identity and a workload need different access paths. Federation and temporary credentials reduce dependence on long-lived keys, but their trust and permissions must be bounded. A role’s trust policy answers who may assume it and under which conditions; its permissions policy answers what that session may do. Authorizing AssumeRole does not automatically grant access to subsequent resources.
In a container service, the deployment role modifies the environment, the task execution role lets the service perform tasks such as obtaining an image or certain secrets, and the task role represents the application to APIs. Separate and verify their responsibilities. Sharing an administrator role across all three extends a code vulnerability to the whole platform.
OIDC in the pipeline provides temporary sessions with verified claims. Issuer, audience, and subject must match the actual system; a GitHub configuration does not transfer to Forgejo because its YAML looks similar.
How policies are evaluated
Identity-based policies attach to identities; resource-based policies attach to resources and may name principals. Evaluation depends on the principal, action, conditions, resource, and whether access crosses accounts. For common access within one account, identity and resource permissions may combine. Every case should not be reduced to a single union or intersection.
A permissions boundary limits the maximum that identity policies may grant; it grants no permissions itself. Session policies and applicable organization controls may restrict further. Direct resource-policy grants to users, roles, or sessions have different rules regarding implicit denies: verify the exact principal before claiming a boundary blocks every path.
An applicable explicit deny takes precedence over an allow. An absent Allow is an implicit deny, with evaluation depending on the path described. Least privilege requires specific actions, resources, and conditions, and reviewing APIs that do not support resource-level permissions. Adding * to make a test pass may open a different scope from the one intended.
KMS and envelope encryption
The key policy is a KMS key’s required regional resource policy and defines usage and administration. An isolated IAM Allow does not enable a key whose key policy disallows that path: the policy must grant suitable access or explicitly enable IAM policies. Grants and denies may also participate. Administering a key and using it to decrypt are different responsibilities; permission to change its policy may affect that separation.
--- config: look: handDrawn --- flowchart TD caller["Authorized workload identity"] --> auth["Application authorization"] auth --> kms["KMS<br/>Key policy, IAM and grants"] kms -->|"Plaintext data key<br/>for local use"| encrypt["Encrypt data locally"] kms -->|"Encrypted data key"| envelope["Stored envelope"] encrypt -->|"Ciphertext"| envelope context["Non-secret encryption context"] --> kms caller -->|"Decrypt permission + matching context"| kms kms --> audit["Audit trail"]
In envelope encryption, a data key encrypts content locally, and the KMS key protects that data key. Store encrypted content with the encrypted data key and required metadata; protect the plaintext data-key copy and discard it when no longer needed. This avoids sending all content to KMS for every operation and establishes a custody boundary that needs design.
The encryption context, available in cryptographic operations with symmetric encryption KMS keys, supplies key–value pairs as additional authenticated data. The same information must accompany decryption of the material it was bound to, and it may be used in policy conditions. It is not secret: it may appear in logs. Avoid PII and use trusted values; an identifier declared by a client does not prove its authorization.
Encryption, rotation, and revocation have different effects. Rotating a key does not automatically revoke plaintext copies or erase already delivered data. An application holding a plaintext data key in memory may continue using it without another KMS call; key caching needs explicit lifetime and scope. KMS or permission failures may prevent new decryptions while the encrypted object remains available.
Auditing and recovery
Auditing should bind principal and session to actions, resources, outcomes, and policy changes. CloudTrail helps observe APIs; configure event scope and retention for the services and operations being investigated. Do not assume every data read is logged by default. Logs also need limited access and protection against alteration.
RTO states how long service recovery may take; RPO states permissible data loss measured in time relative to the incident. Verify them with the application and its procedure, including identities, keys, backups, and dependencies. Encryption or redundancy alone does not set universal values. A copy without valid decrypt permissions may be unusable during an emergency.
What to verify
Test permitted access and several denied cases: another environment, an out-of-scope resource, incorrect context, and an explicit deny. Also evaluate a resource grant to the exact principal and review who may change policies. Simulators provide partial evidence; some integrations and conditions require checking the real path in an isolated environment.
A recovery exercise should restore an encrypted copy with authorized identities and measure time and recovered data. Signals include unexpected denied access, role usage, key operations, and policy changes. The result is a verifiable access contract and recovery that preserves it.