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

> Import the users, roles and groups already in AWS, GCP or Azure into zopdev teams and roles. Preview before apply, idempotent on re-run, and reversible with a single disconnect.

Source: https://zop.dev/integrations/cloud-iam-import
Updated: 2026-08-20

---

## Common questions

### Does importing IAM change anything in my cloud account?

No. The import runs one way, cloud into zopdev. No policies are edited, nothing is written back to your IAM, and no permissions are granted in AWS, GCP or Azure as a result of running it.

### Is it safe to apply a preview generated ten minutes ago?

Yes. Apply looks up existing rows by the cloud-native identifier each object was imported with, an ARN on AWS, before creating anything, so rows that already exist simply no-op. Running the import twice produces the same estate as running it once.

### What role do imported team members get?

None. A member created by the import carries an empty role reference rather than a default one, so the grant is a deliberate decision instead of whatever value the importer needed to write.

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.