IAM Roles & Policies
What does zop.dev create for IAM Roles & Policies?
zop.dev exposes IAM as 2 standalone 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 as standalone resources 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 cluster’s built-in access tiers
Available as standalone resources, complementing the IAM that the EKS cluster build creates for its access tiers.
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
Cluster provisioning 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 build; reshaping them as standalone resources creates two writers for one object, and the cluster’s next provisioning 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.