Cloud IAM Import

If you’ve already organised your cloud accounts around IAM users, groups, and policies, IAM Import saves you from recreating that structure in ZopNight by hand. The wizard previews every user, group, and policy attachment your AWS, GCP, or Azure account has and proposes a ZopNight equivalent for each one. Nothing is written until you click Apply.

Before you start

• A connected AWS, GCP, or Azure cloud account. See Cloud accounts.
• Your ZopNight role. The wizard needs no new RBAC policy; it checks existing ones. Preview needs cloud-account:view. Apply, resolving Needs Attention, and Disconnect need cloud-account:update.
• AWS: an email tag on each IAM user you want imported, because AWS IAM users have no built-in email field.
• GCP: roles/iam.securityReviewer to read IAM members and bindings, plus roles/cloudidentity.groups.reader at the organisation level if you want Google Group members. See Cloud permissions.
• Azure: the grant the wizard names at connect time, plus an optional Microsoft Graph directory read grant to populate imported teams with members.

How it works

The import has two layers: a passive inventory and an admin-triggered identity import. The passive layer keeps cloud-side IAM principals in your resource inventory on every discovery cron, with no admin action needed. The identity layer creates ZopNight users, teams, and roles only when you click Apply.

What gets imported

Cloud concept	ZopNight equivalent
AWS IAM User	ZopNight User
AWS IAM Group	ZopNight Team
AWS managed policy	ZopNight Role (mapped via curated translation table)
AWS custom policy	Translated from the actions it grants; anything unrecognised lands in Manage IAM → Needs Attention
GCP user member	ZopNight User
GCP Google Group member (optional)	ZopNight Team
GCP predefined role	ZopNight Role (mapped via curated translation table)
GCP custom role	Translated from the permissions it grants; anything unrecognised lands in Needs Attention
Azure AD principal	ZopNight User
Azure role assignment	ZopNight Role (mapped via curated translation table)

What’s never auto-granted

Read this section before a security review. ZopNight’s translation table is deliberately conservative:

Cloud IAM often has admin-shape policies attached liberally (an iam_role Terraform module from five years ago, a “platform admin” group that grew to 30 people). Auto-promoting those into ZopNight org-management policies would silently widen access. The wizard requires you to look at each one.

Type-scoped policies (resource:view:s3, resource:delete:lambda) are auto-granted from service-specific cloud roles. Those are safe to translate because they preserve the cloud-side scope.

Run the import

1. Open Manage IAM

   Settings → Cloud Accounts → the AWS, GCP, or Azure card → Import IAM (pre-import) or Edit IAM (post-import).

2. Preview

   The Preview tab lists every IAM user, group, and policy attachment with a proposed ZopNight equivalent. Emails for AWS users come from the AWS email tag.

3. Resolve Needs Attention

   Anything ZopNight could not translate lands here. You map each one to ZopNight policies. Team bindings for these custom roles are pre-positioned at import time. Once you map the policy, the bindings activate immediately, with no re-import.

4. Apply

   Click Apply. ZopNight creates the ZopNight users, teams, roles, role-to-policy assignments, and team memberships based on your resolutions. Every imported entity carries provenance metadata (see Idempotency below).

Verify the import

After Apply, check three places:

• Settings → Organization → Members: imported users with the Imported from cloud badge
• Governance → Teams: imported teams with member counts
• Settings → Roles: imported roles with their policy sets

Every Apply is recorded in the audit log, and each imported entity keeps the cloud-native identifier it came from, so reviewers can trace it back to its cloud-side origin.

Resolve AWS users without an email tag

AWS IAM users don’t have a built-in email field, so ZopNight reads it from an email tag on the user. If a user has no email tag, the wizard skips them at Apply time and surfaces them in Manage IAM → Missing emails.

Resolve them one of two ways:

• One at a time: type the email into each row and click Save
• Bulk: download the CSV template (cloud-username,email), fill it in, and upload it

The Apply that follows runs a server-side catch-up: for every newly resolved user, ZopNight looks up the cloud roles and groups they were attached to in AWS, and emits the missing role and team-membership assignments against ZopNight roles already imported by the original wizard run. The user then lands in the org with the bindings they should have received the first time.

The catch-up never creates new ZopNight roles. Roles imported during the original wizard remain the universe of options; cloud roles that weren’t imported initially stay in Needs Attention.

GCP IAM Import

Same wizard, same review-before-apply contract. Differences from AWS:

Behaviour	AWS	GCP
Scope	Account	Project
Bindings outside project scope	n/a	Excluded: org-level and folder-level bindings are not imported. A user granted roles/owner at the org but never at the project will not appear. Grant the role at the project too, or invite them manually.
Group members	n/a	Optional; requires roles/cloudidentity.groups.reader at the org level. Without it, imported teams come in with zero members. The wizard surfaces a copy-paste gcloud command to grant it.
Service account dropping	Kept	Custom roles whose principals were all serviceAccount: get dropped at import, and the dropped-role count is reported for that import.

The GCP translation table maps common predefined roles (roles/owner, roles/storage.admin, and others) following the same admin-collapse pattern: roles/owner → built-in Admin, predefined viewer-style roles → Viewer.

Idempotency

Every imported entity records the cloud-native identifier it came from (the AWS ARN or GCP resource path). A second wizard run finds existing entities by this identifier and reuses them instead of duplicating.

Change in cloud directory	What happens on re-import
User renamed in AWS	ZopNight user keeps the same id; ARN lookup still hits
User renamed in ZopNight	Re-import preserves the ZopNight name; ARN lookup still hits
Group renamed in AWS	Same. ARN is the key
User deleted in AWS	Re-import leaves the ZopNight user unchanged. Use Disconnect to remove.

A user, team, or role that comes from more than one connected account (a single shared role, say) keeps a link to each account. Disconnecting one account removes only its contribution; the entity stays while another account still references it.

Disconnect

Disconnecting from the wizard (or from the cloud-account card’s Remove flow) soft-deletes everything imported from that cloud account and clears the matching role and team-membership assignments.

The IAM import view is refreshed on cloud-account delete, so reconnecting and re-importing produces a clean state immediately.

Troubleshooting

Next steps