iam-import

command
v1.801.466 Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Aug 5, 2026 License: Apache-2.0 Imports: 9 Imported by: 0

Documentation

Overview

Command iam-import copies an identity store from the standalone IAM into the store the EMBEDDED iam subsystem reads (apps/iam), so cloud can serve identity in-process and the separate pod can be retired.

WHY THIS IS NOT A FILE COPY. The two stores differ in three ways at once. The standalone writes `iam.db` as a PLAINTEXT SQLite file — the literal "SQLite format 3" header, which is the exposure apps/iam/openStore exists to remove. The embed writes `global.db` through cek, keyed from the process master, and names the file after the PARTITION it holds rather than after the product. And the embed opens exactly one path, derived by namespace from the data dir, so a file dropped beside it is not a file it will read.

So the rows are moved, not the bytes: read the source with a plain driver, write the destination through the same cek.Open the subsystem itself uses. The result is the identity graph that was in the clear, at rest under a key, in the place the running binary already looks.

WHAT MOVES. Everything in `_entities` — hanzoai/iam stores users, organizations, applications, certs, providers, memberships, sessions and tokens as one document table, so there is one thing to copy and no per-type list to keep in step with a schema that grows. The signing CERTS are the load-bearing rows: an empty set is why the embedded store answers `{"keys":[]}` at /v1/iam/.well-known/jwks, which would fail every token in the fleet the moment traffic moved to it.

IDEMPOTENT, AND IT REFUSES TO GUESS. Rows are keyed by (kind, name) — the identity hanzoai/iam already uses — so a re-run updates rather than duplicates, and an interrupted run is resumable. It will not write into a destination that already holds rows unless --overwrite says so, because merging two live identity stores is a decision, not a default.

iam-import --src /path/to/iam.db --dir /var/lib/cloud [--dry-run]

The master key comes from the environment the cloud binary already uses (CLOUD_KMS_MASTER_KEY_REF, base64), because a tool that took a key on the command line would put it in a shell history and a process list.

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL