Roles and Policies
define who can do what to which resources in Dodil.
Dodil’s IAM follows a role-based access control (RBAC) model, with optional resource-level scoping that enables ABAC-style (attribute-based) decisions when you need fine-grained control.
Core concepts
Principals
A principal is the identity making a request:
- User: a human identity that signs in and operates through the console or API.
- Service account: a non-human identity used by services, automation, or CI/CD.
Roles
A role is a named bundle of permissions that can be assigned to principals.
Roles are designed to be reusable, easy to audit, and simple to reason about (e.g., Viewer, Operator, Admin).
Permissions / scopes
A permission (sometimes called a scope) represents an allowed capability, such as:
- Listing resources (read-only)
- Creating or modifying resources (write)
- Managing access (IAM administration)
Permissions are evaluated against the target resource and the action being performed.
Resource scoping
Roles can be scoped to specific resources (or resource groups) to limit where permissions apply.
Examples:
- Grant a team Viewer access to a single project
- Allow an automation service account to manage resources only in a specific organization
This scoping is what allows ABAC-style behavior: access can depend on attributes such as organization, project, region, environment, or resource identifiers.
How authorization works
When a request is made, Dodil evaluates authorization in this order:
- Identify the principal (user or service account) and its assigned roles.
- Match the request to a permission/scope (action) and a target resource.
- Apply resource scope rules (if the role assignment is scoped).
- Decide: allow if there is at least one role assignment that grants the required permission for the target resource.
If no role assignment matches the requested action and resource, the request is denied.
Recommended role design
To keep IAM maintainable as your organization grows:
- Prefer least privilege: grant the minimal permissions required.
- Use small, purpose-driven roles (avoid overly broad “god roles”).
- Prefer resource scoping over creating many near-duplicate roles.
- Separate operational permissions from IAM administration.
- Review roles regularly and remove stale assignments.
Common patterns
- Humans: assign roles to users through groups/teams where possible.
- Automation: use service accounts with narrowly scoped roles.
- Environment separation: scope roles by environment (dev/staging/prod).
- Break-glass admin: keep a limited number of admins with strong controls.
Where to manage roles
You can view and manage roles from the IAM Console: