# IAM Roles & Policies

> zop.dev exposes IAM as 2 standalone provisioner resource types (role, taking a trust_policy document, and policy, taking a policy_document) for access needs outside the pre-built EKS cluster tiers. IAM is global and free: nothing here bills, but every grant widens what some credential can do, account-wide.

Source: https://zop.dev/integrations/provision/aws/iam-roles-policies
Updated: 2026-08-19

---

IAM roles and policies define what every workload and user may do in AWS. zop.dev manages them directly through its provisioner API for cases outside the pre-built cluster access tiers.

## IAM roles and policies as standalone resources

IAM roles and policies as standalone resources (resource types role and policy).

## trust_policy and policy_document inputs

```text
trust_policy document for roles; policy_document for policies.
```

## Complementing the Terraform-managed cluster tiers

Available through the cloud-resource-provisioner API, complementing the Terraform-managed EKS access-tier IAM.

## Two documents doing two jobs

A role is created from a `trust_policy` document; a policy from a `policy_document`. They
answer different questions. The trust policy says who may assume the role: a service, another
account, an OIDC identity. The policy document says what the bearer may do once inside. Most
real-world IAM mistakes are a confusion of the two: a perfectly scoped permission set attached
to a role that half the organization is trusted to assume.

## The gap these resource types fill

The Terraform layer already builds IAM. The EKS access tiers arrive as role-and-policy sets
with the cluster. These standalone `role` and `policy` resource types exist for everything that
does not fit that mold: a role for an external CI system, a narrow S3 policy for one workload,
cross-account trust for a partner integration.

The boundary matters in the other direction too. The tier roles are owned by the cluster
module; reshaping them through this API creates two writers for one object, and the module's
next run wins. Standalone needs get standalone roles.

## Global, free, and prone to accumulation

IAM is not regional, and none of it bills. A role created here exists account-wide,
everywhere at once. That combination makes IAM the layer where clutter accumulates fastest: no cost
pressure to delete anything, no region boundary to contain it. An unused role with a broad
trust policy is not neutral clutter, though; it is a door nobody watches. Deleting roles when
their reason ends is the discipline the price tag never enforces.

## Deletion order is the operational catch

A role deleted while workloads still assume it fails closed. The moment it is gone, everything
relying on it loses permissions with 0 grace period. Detach and re-point consumers first,
delete second, and treat a delete that "cannot possibly be in use" as a claim to verify.