Ignite Auth and Access

Last validated: 2026-05-20

Ignite uses token-based tenant identity on public surfaces

Access Planes

Public User Plane

Applies to:

• ComputeService
• BuildService
• ModelService
• SecretService

Identity model:

• Bearer token validated through gateway/auth chain
• Tenant org context propagated via trusted metadata (x-organization-name)
• Method-level scope checks enforced via proto auth annotations and runtime middleware

Organization Context Rules

1. Runtime treats organization context as authoritative metadata, not user-editable payload fields.
2. Cross-org reads/writes are blocked by tenant scoping in service logic.
3. Secret paths are org-scoped, preventing cross-tenant secret access.

CLI Auth and Config Precedence

CLI resolves auth and endpoint values from (highest to lowest):

1. Explicit command flags
2. Shared Dodil token env (DODIL_TOKEN) and Ignite env vars
3. Config files (~/.config/dodil/config.yaml in plugin flow, plus CLI-local config paths)

Scope Model (High Level)

Representative scopes used across RPCs:

• DeployApp, GetApp, ListApps, ListAppVersions, RollbackApp
• InvokeApp, GetExecution
• CreateBuild, GetBuild, ListBuilds, CancelBuild, SaveBuildSecrets
• CreateSecret, GetSecret, ListSecrets, DeleteSecret

Interpretation:

• API call success requires both valid identity and matching method scope.
• Scope policy details are environment-managed IAM concerns.