Cloud IAM Import — Turn Existing Cloud Identity Into zopdev Teams and Roles

Most teams arriving at zopdev have already spent years describing who may do what, in AWS IAM or its GCP and Azure equivalents. Cloud IAM import reads that structure and proposes the equivalent zopdev teams and roles, so access control does not have to be rebuilt by hand in a second place.

One-way, by design

The import runs in one direction only: cloud into zopdev. Nothing is written back to your IAM, no policies are edited, and no permissions are granted in your cloud account as a result of running it. All three major clouds are supported: AWS, GCP and Azure.

Preview commits nothing

The wizard starts with a preview that fetches live IAM state (first listing principals, then pulling details for the users, roles and groups it found) and runs the suggestion pipeline over them. Preview performs no database writes at all. What you see is a proposal: which cloud users map to which zopdev users, which roles become zopdev roles, which groups become teams.

Nothing is applied until you send resolutions back. That is where an administrator’s judgement enters, and it is the point of splitting the two calls.

Why a stale preview is safe anyway

There is deliberately no drift detection between preview and apply. Re-fetching IAM state at apply time measured around thirty seconds, which is a long time to hold an administrator on a spinner for a check that rarely changes the answer.

Instead, safety comes from apply being idempotent. Every imported object records where it came from, and apply looks up existing rows by that cloud-native identifier, an ARN on AWS, before creating anything. Click apply on a preview generated ten minutes ago and the rows that already exist simply no-op. Running the import twice produces the same estate as running it once.

Two behaviours worth knowing before you run it

Imported members get no in-team role grant. A team member created by the import carries an empty role reference rather than a default one. Handing every imported user a role because the importer needed a value to write is precisely the failure mode that turns an access-control migration into an access-control incident, so the field is left empty and granted deliberately.

GCP custom roles translate, and say so when they cannot. Custom-role permissions are auto-translated into zopdev actions. A role that does not translate cleanly is still imported, with empty policies and a review flag on the role itself, so it appears on the Roles page rather than silently disappearing or blocking the run.

Alongside preview and apply there is a needs-attention view that re-runs the same pipeline and returns only the flagged items, and a disconnect that unwinds the import.

The limit to be honest about

Users created by an import are ordinary user rows and carry no marker distinguishing them from users who signed up directly. If you later want to undo an import completely, those accounts have to be reviewed by hand. Some of them belong to real people who have since logged in, and deleting them by rule rather than by review would remove the wrong ones.