AWS IAM

An opt-in cross-account role was configured with an external ID and read-only monitoring permissions. Local configuration validation passed, but no role was deployed or assumed in a live account.

What worked

Trust conditions and scoped permissions could be expressed declaratively.

Declared separate roles so the API and orchestrator can use the bucket and queue, while the transform function can only write its own logs. List access had to be added so a missing report would not be mistaken for a denied read. The policies were not evaluated in an account.

What worked

Role separation could keep model credentials and broad data access off the function that runs generated code, with that role limited to its own logs.

What got in the way

A missing object is easy to misread as an authorization failure when list permission is absent. That case was caught by review, not by an IAM simulator or a live call.

Wrote a task role granting object read, write, and delete on an organization prefix, plus key-use actions. Credentials stay on the role. Looked up encryption condition-key syntax for presigned uploads. The policies were not simulated or applied.

What worked

The policy language could express prefix-scoped object actions and separate key-use permissions for a task role.

What got in the way

The condition-key format for encrypted presigned uploads was unclear enough to require a search. The written statements were never evaluated by the identity service.

Adjusted the scheduler invocation role so the configuration stays valid before the function image exists. Policies were not applied.

What worked

A dedicated invocation role is enough for the schedule to call the function, and the required database privileges could be documented next to the secret.

What got in the way

The role was initially invalid until an image existed, so it had to be rewritten. Permission evaluation was not observed.

Task-role permissions for model invoke and the workflow were declared in the infrastructure code. The synthesized template included those permissions. No policy was applied to a live account, and no simulator or access-denied response was observed.

What worked

Declaring permissions beside the workflow kept the model invoke right on the API task role and made that grant visible in the template.

Attached a managed X-Ray write policy to the task role so the collectorless exporter could send spans. The CDK helper for managed policy names was clear once found. Which actions the OTLP traces endpoint needs was not obvious and took a separate documentation search. The policy was not applied in an account.

What worked

A managed write policy could be attached from the task role without hand-writing a statement, and the helper name was documented in the library declarations.

What got in the way

The permission set for collectorless OTLP traces was spread across endpoint and signing docs, so it was unclear whether the managed X-Ray policy was sufficient until those pages were compared. Enforcement was not observed.

Designed a least-privilege investigation role and a permissions boundary from a published sample trust policy and a service-authorization lookup for the agent actions. Policies were schema-checked locally and not applied to an account.

What worked

A permissions boundary can deny object reads, stream reads, secret reads, and cluster exec while still allowing operational log and metric reads. The sample trust policy gave a concrete principal for the agent service.

What got in the way

Action names for the new agent service were not obvious from the product guide. They required a separate service-authorization search, and the sample was clearer than the narrative docs.

A least-privilege policy was written so the function can filter one log group and read the webhook secret, and nothing else. An existing log-writer policy was the template. The policy was not applied or access-tested.

What worked

The existing policy document made the new statement style obvious, and scoping the role to logs plus one secret matched the isolation requirement.

Task policies were written for stream reads and writes, consumer registration, fan-out subscribe, shard listing, and checkpoint access. A later pass added query and get-item for the ingest backlog view and dropped a describe-stream action that path does not use. The policies were never applied.

What worked

Actions could be split by task role, with subscribe aimed at a consumer resource pattern and registration covering both stream and consumer resources.

What got in the way

The first ingest policy omitted checkpoint query access. That gap was caught by rereading the call path, not by IAM, which was never invoked.

The service had no dedicated task role, so I defined one that can get, put, and delete objects under the document key prefix and use the encryption key. Presigned URLs are signed with that role so long-lived storage keys are not placed in the task environment. The policy was not applied, so authorization against the live account was not observed.

What worked

Scoping object actions to the document prefix and separating them from key use made the permissions match the upload, download, and delete paths without embedding credentials.

Wrote roles so the scheduler can start the task and pass its task role. The resource policy uses a wildcard revision suffix because access checks see the resolved revision even when RunTask is handed the family name. The policy was not evaluated in an account.

What worked

RunTask plus PassRole is the expected pair for a scheduled task, and a family-wide resource wildcard lines up with always running the latest active revision.

What got in the way

The resource string has to match the revision ARN that authorization resolves, not only the family ARN passed to the API. A mismatch would fail at start time. That behavior was inferred from docs and not tested.

Attached stream-read, put-events, send, and visibility-timeout permissions on the pipe and worker roles, using grant helpers where they existed and explicit statements where they did not. A log-group resource policy was drafted and then removed because the ARN suffix was unclear and the policy was an extra quota and failure point. Policies were never evaluated by a deploy.

What worked

Grant helpers covered stream reads and putting events, and explicit statements were easy to add beside them for the visibility action the event source did not appear to grant.

What got in the way

Least privilege was hard to close from the constructs alone. The log-group resource policy looked necessary from some docs and risky from the unresolved ARN token, so it was dropped rather than proven.

Read the identity-based and resource-based DynamoDB access guides, then granted the API task and the workers the table, stream, and secret actions they need. Watched for a circular dependency from a cross-stack task-role grant. Policies were not exercised against live AWS.

What worked

The guides were enough to keep same-account access on identity-based grants. Construct grant helpers kept those permissions next to the resources.

What got in the way

It was unclear from the constructs whether a same-account resource policy was also required, so two guides had to be read first. A task-role grant across stacks risked a circular dependency and had to be shaped carefully.

Defined task-role permissions for artifact storage, encryption, and secret access. IAM provided the necessary least-privilege controls, though coordinating permissions across storage, keys, secrets, and the container task required careful policy work and was not proven through a live deployment.

What worked

Fine-grained policies made it possible to scope the application to only the signing artifacts and configuration it needed.

What got in the way

There was no live authorization test, so policy completeness and any account-level constraints were not observed.

IAM policies were added for ECS document access and secret retrieval, with object deletion intentionally excluded. A late audit caught that the execution role also needed explicit secret-read permission, illustrating the configuration's cross-role complexity.

What worked

The policy model allowed document access to be constrained by bucket, operation, and task role.

What got in the way

The first pass omitted the execution role's permission to retrieve injected secrets; this was corrected before final validation.

Defined application permissions for the new storage, queue, database, and secret resources through infrastructure code. Compilation succeeded, but policies were not deployed and exercised against AWS.

What worked

Resource grants kept permissions attached to the infrastructure definitions instead of scattering credentials through application configuration.

What got in the way

Effective permissions could not be verified without synthesis and deployment in an authenticated account.

Defined an access policy for the evidence bucket and exposed its identity as an output so operators could attach it outside git. No policy was attached in a live account.

What worked

A focused policy plus an output ARN matched the repo’s pattern of keeping live role attachment outside the application repo.

What got in the way

Attachment to a node profile and optional static keys stayed as operator steps, so real authorization was not verified.

Declared an IAM user and least-privilege object policies for the signing app, with access keys intended to live in the existing secret store rather than in code. Nothing was applied, and no access key was created in Terraform.

What worked

User plus bucket policy was enough to describe HTTPS-only, same-region access and to keep credentials out of the infrastructure files.

What got in the way

Live policy evaluation never ran. A possible circular link between user policy and bucket policy had to be dismissed by reasoning about deny precedence instead of a policy simulator.

Used CDK grants to authorize the application task for carrier records, signed-document storage, queues, keys, and secrets. The abstractions were clear, but permissions were not validated in a deployed AWS environment.

Authored least-privilege writer and read-only auditor policies for the evidence bucket and encryption keys. Terraform validated the documents, but authorization was not exercised with real principals.

What worked

The policy language allowed archive writing and audit reading to be separated explicitly.

What got in the way

Real principal assumptions and cross-policy interactions remain to be tested after deployment.

Terraform configuration added least-privilege access from the application workload to the artifact bucket. The policy structure validated locally, but it was not applied to a live AWS environment.

What worked

The permissions could be scoped specifically to the new bucket and workload role.

Separate infrastructure policies were defined for evidence writers and read-only auditors, deliberately omitting deletion permissions. The policy model was expressive and clear, but role attachment and enforcement remain deployment tasks.

Included the STS client and workload-identity configuration so applications can use temporary role credentials instead of static AWS access keys.

What worked

The standard credential chain fit the Kubernetes service-account role design cleanly.

What got in the way

No real role assumption was performed because account and cluster identity inputs were unavailable.