# A report worker does not need the application's master key

Give each workload the authority required for its job and no unrelated administration path. Separate who may assume the identity from what that identity may do.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Start with the business operation

A scheduled worker reads approved order data and writes a daily report to a designated location. It does not need to delete customer records, modify network policy or deploy a new application version.

Describe those operations before choosing a role or managed policy. Map each operation to the provider's actions, resources and supported conditions. Include less frequent work such as retries, cleanup and recovery so the eventual policy reflects the whole supported lifecycle.

Avoid sharing one broad identity across unrelated workers. If a report job and an import job have different authority, separate identities make their permissions and activity easier to explain. They also let the team change one job's access without disrupting the other.

## Separate trust from permission

A workload identity has at least two important questions: which workload can obtain it, and what requests it can make once obtained. Narrow resource permissions do not help if an unintended caller can assume the role and exercise them.

Use the platform's supported temporary workload credentials where possible. AWS recommends roles for workloads so applications do not need distributed long-lived user keys. Other platforms have their own managed or federated identity mechanisms that require equivalent review.

### Workload access has distinct trust and resource boundaries

The platform establishes the calling workload, then evaluates the requested action under the applicable resource and policy context.

1. **Workload identity**: Identify the deployed job or service
2. **Trust decision**: Permit only the intended workload to obtain credentials
3. **Resource request**: Name the required action and target
4. **Policy decision**: Evaluate all applicable policies and conditions

## Do not infer the whole policy from yesterday's traffic

Observed activity is useful for discovering permissions, and tools can generate candidate policies from supported audit data. But a quiet observation window may omit month-end work, restoration or rare failure handling.

Combine activity with the application's operation inventory and tests. A policy based only on normal reads might break the cleanup required after a partial upload. The answer is to identify that specific permission, not restore a wildcard whenever an error appears.

Keep exceptions narrow and documented where a provider action does not support resource-level scope. Least privilege follows the service's actual authorisation model rather than an imagined uniform syntax.

## Evaluate effective access, not one policy file

Identity policies, resource policies, organisation controls and session-related constraints can interact. Use the provider's documented evaluation rules and supported analysis tools. An apparently narrow role file does not describe every possible grant or denial in the environment.

Test prohibited operations as well as required ones. The report worker should successfully read its approved source and write its output, while attempts to delete the source or access another environment fail.

## Keep deployment authority separate from runtime authority

A deployment job may need to update the worker's code and configuration. The running worker usually does not need that ability. Combining them gives application code a route to change its own future execution or permissions.

Record ownership, purpose and retirement conditions for each identity. When the workload disappears, review its role, trust relationships and credentials. A small permission set with no current owner can still become an unexplained access path over time.

## Sources

- [AWS: IAM security best practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
- [AWS: policy generation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)
- [AWS: policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)