feat: bootstrap Atom's RBAC baseline from a YAML config file

[JeffMboya]

What this PR does — the short version

Adds a single YAML file that describes the initial state of an Atom deployment — admin user, tenants, service accounts, roles, permissions, tokens — and has Atom set it all up on startup.

Like Docker Compose, but for identities and access control instead of containers. Point Atom at the file with ATOM_BOOTSTRAP_FILE=/path/to/bootstrap.yaml, start it, done.

Why

To bring up a fresh Atom today you either:

• Set one env var per admin/service password (ADMIN_SECRET, etc. — passwords only, nothing else), or
• Call the API by hand to create every tenant, group, role, permission, and service account.

Neither is friendly for platform teams who want their deployment described in git, code-reviewed, and reproducible across environments.

A minimal example

tenants:
  - id: 33333333-3333-3333-3333-333333333333
    name: factory

entities:
  # The pre-seeded admin gets a password (replaces ADMIN_SECRET).
  - id: 00000000-0000-0000-0000-000000000001
    kind: human
    name: admin
    credentials:
      - kind: password
        secret: change-me-please

  # A device with a machine key, scoped to the factory tenant.
  - id: 22222222-2222-2222-2222-222222222222
    kind: device
    name: gateway-01
    tenant_id: 33333333-3333-3333-3333-333333333333
    credentials:
      - kind: shared_key
        key: replace-with-a-strong-secret

  # A downstream service with a pre-minted access token.
  # Paste the same string into the service's env — no separate mint step.
  - id: 11111111-1111-1111-1111-111111111111
    kind: service
    name: ingest-service
    credentials:
      - kind: access_token
        token: atom_<32-hex-id>_<64-hex-secret>

Full example lives in bootstrap.example.yaml — the file supports the whole graph: tenants, entities & credentials, resources, principal groups, object groups, permission blocks, roles, role assignments, direct policies, capabilities, and guardrails.

What operators get

Safe to re-run. Every record is keyed on a stable UUID and inserted with ON CONFLICT DO NOTHING. Bootstrapping an already-bootstrapped database is a no-op. Runtime edits never get clobbered.

Managed rows are protected. Anything created (or claimed) via the YAML is stamped managed_by='config' in the database, which means:

• The API returns 409 / 404 on attempts to update, delete or revoke those rows.
• Bootstrap credentials never appear in list responses. The API pretends they don't exist, so a pre-minted service token can't leak through introspection.
• The auth path still accepts those tokens at runtime — services log in normally.

Fails loud. Structural problems (duplicate ids, shared keys on humans, invalid scope combinations, malformed access token strings) abort startup with a clear message, not a half-applied bootstrap.

Same code as the API. Password hashing, shared-key encryption, capability validation, access-token parsing — bootstrap goes through the same functions the API does, so the rows it produces are indistinguishable.

What this replaces

• The ADMIN_SECRET / ATOM_SERVICE_SECRET env vars still work; the YAML is the successor.
• One-shot init containers that products like magistrala shipped just to hit the API at deploy time — everything they used to do (register actions, applicability, assignment guardrails, mint service tokens) is now expressible in this YAML.

Migrations

Three new migrations, all additive:

• 004_managed_by.sql — adds managed_by column to actions, action_applicability, action_assignment_rules.
• 005_managed_by_identity.sql — same for entities and credentials.
• 006_strip_product_specific_applicability.sql — removes two IoT-flavoured seed rows (publish/subscribe → resource:channel, execute → resource:rule) that leaked into 001. Downstream products supply these via their own bootstrap YAML now.

Note: we tried editing 001 in place first — sqlx refused to run against any existing database because the migration's checksum changed. Landing the delete as a new migration keeps upgrades clean.

Tests

• Unit — YAML parsing & validation, every error path.
• Integration (DB-gated) — tests/m25_config_bootstrap.rs (full graph), tests/m26_config_managed_capabilities.rs (capabilities/guardrails + API mutation guards), tests/m27_config_managed_identity.rs (entity/credential guards + list filtering + a regression guard that confirms bootstrap access tokens still authenticate at runtime).
• Two existing tests (m8_guardrails.rs, m13_graphql_authz_admin.rs::channel) were patched to seed publish/subscribe → resource:channel inline, since migration 006 removes that seed.

All green locally: cargo test, cargo test -- --ignored against Postgres, cargo fmt --check, cargo clippy -- -D warnings.

Notes for reviewers

• New dep: serde_yaml = "0.9" for parsing.
• The YAML contains secrets inline (same posture as ADMIN_SECRET today) — mount it as a Kubernetes secret or bind-mount from a protected path; keep it out of version control.
• shared_key credentials are only valid for machine (non-human) entities.
• access_token credentials take the full atom_<id>_<secret> string; the credential id is the upsert key so re-runs are idempotent.

Related

• Resolves Feature: Bootstrap ATOM with configuration file #27.
• Companion PR in magistrala: absmach/magistrala#TBD — deletes the imperative atom-bootstrap Go binary and moves everything (capabilities, guardrails, service tokens) into its own bootstrap YAML template + a shell script that generates the tokens.

[dborovcanin]

@arvindh123 Please carefully review.

[dborovcanin]

@arvindh123 Please review.

[arvindh123]

I'm trying to find different solution, like to avoid atom-bootstrap in MG via Config
I will propose something here in few minutes