Skip to Content
We are live but in Staging 🎉
IAMIAM Overview

IAM (Identity & Access Management)

is the security layer that controls who can access your DODIL resources and what they’re allowed to do.

It covers:

  • Authentication: proving identity (sign-in).
  • Authorization: enforcing permissions (access control).
  • Credentials & policies for both humans and machines.

How to navigate this section

Most users come here for one of three things:

  1. Issue API keys so applications, CI/CD, and servers can call DODIL APIs.
  2. Create service accounts when you need to manage the machine principal directly.
  3. Define roles and policies to control access to specific resources.

Use these pages as your starting points:

  • API Keys → the primary credential for programmatic access: API Keys
  • Service Accounts → the machine principals API keys bind to: Service Accounts
  • Roles & Policies → define permissions and scope access: Roles and Policies

Users vs Service Accounts

Both can access DODIL, but they are designed for different use cases.

Users (humans)

Users represent real people: admins, developers, operators, and analysts.

  • Login is interactive (for example: email + password, and optionally 2FA)
  • Best for using the Console UI and day-to-day operations
  • Permissions are typically assigned via roles

Service accounts (machines)

Service accounts are for software—SDK clients, backend services, pipelines, and automation.

  • Authentication is non-interactive using service account ID + secret
  • Best for production workloads and CI/CD
  • Safer than using personal user credentials for automation
  • Permissions should be scoped narrowly using policies (least privilege)

Typical flow

A common onboarding path looks like this:

  1. Issue an API key for your app with the right role (a managed service account is minted for you automatically).
  2. Configure your SDK or service with the dk_… token.
  3. Come back to Roles and Policies to tighten scoping (per-bucket / per-resource DRNs) as your permissions grow.

If you’re just getting started, begin with API Keys; reach for Service Accounts directly only when you need to manage the underlying principal yourself.