Import AWS, GCP and Azure IAM Principals into ZopNight

Rebuilding users and teams by hand in a cost platform duplicates work your cloud IAM already did. ZopNight’s IAM import reads principals from a connected AWS account, GCP project or Azure subscription and proposes matching ZopNight users, roles and teams. Nothing is applied until you say so. This guide adds one step first: pulling the native picture yourself, so you can judge the suggestions against it.

1. Snapshot the source, natively

Having the raw export open next to the import review makes the “why is this person here” questions quick to answer.

AWS. One call returns users, groups, roles and policies and how they relate. It needs iam:GetAccountAuthorizationDetails.

aws iam get-account-authorization-details --filter User Group Role \
  --query "UserDetailList[].[UserName,GroupList]" --output json > aws-iam.json

Google Cloud. Project-level bindings, flattened to one row per role and member:

gcloud projects get-iam-policy my-project \
  --flatten="bindings[].members" \
  --format="table(bindings.role,bindings.members)"

This shows the project’s own policy. Access inherited from a folder or the organisation lives in those policies, not here.

Azure. Role assignments with readable names. By default the command lists only subscription-scope assignments; --all adds resource-group and resource scopes.

az role assignment list --all --include-inherited \
  --query "[].[principalName,roleDefinitionName,scope]" -o table

2. Start the import

Open the connected cloud account in ZopNight and choose Import IAM. The import only writes ZopNight’s own users, teams and roles; it never changes anything in the cloud’s IAM.

3. Review the suggestions

Every proposed user, role and team is shown before anything is written. Known cloud policies and roles map to a curated ZopNight permission set; custom roles are translated action by action; anything the import cannot place lands in Needs Attention.

Two behaviours to expect:

• Organisation-management rights are never imported automatically, even from administrator-level cloud roles. Role, user, assignment and organisation management stay with you; promote people later from Settings, then Roles, if they need it.
• Teams may arrive empty. Group membership comes across only when the optional group-read grant is present (Cloud Identity on Google Cloud, Microsoft Graph on Azure). Without it, teams are created with no members.

Cross-check a handful of suggestions against the export from step 1, especially anyone with broad cloud rights who would otherwise get broad cost-data access.

4. Resolve Needs Attention and missing emails

Cloud principals do not always carry an email, and ZopNight users need one. Fill missing emails one at a time or from a CSV, then work through the Needs Attention list: decide a role for each unmapped principal, or leave it out.

5. Apply, then re-run when the cloud changes

Choose Apply. Re-running the import later is safe; it is idempotent, so it updates rather than duplicates. Disconnecting the import removes everything it created from that account, and deleting the cloud account in ZopNight cleans up imported items too.

Check the result

Sign in as one imported user, or ask one to, and confirm they see the resources and reports their role implies and nothing more. Team members inherit their role’s permissions scoped to the resources assigned to their team, so a team with no assigned resources will see an empty estate. For designing the roles themselves, see setting up RBAC for scheduling and cloud IAM import.