IAM Roles & Policies
What does zop.dev create for 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.
| Field | Value |
|---|---|
| Cloud | aws |
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
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.