Cloud IAM Import: Mirroring Cloud Access in ZopNight

Cloud IAM import is the process of reading identities and permissions from a cloud provider and translating them into another system’s users, teams, and roles. The goal is to avoid maintaining two access models by hand: one in the cloud, one in the tools that sit on top of it.

The difficulty is that cloud permissions do not translate one-to-one. AWS IAM organizes access around users, user groups, and roles with attached policies. Google Cloud grants roles to principals through allow policies that inherit down a resource hierarchy. Azure assigns role definitions to security principals at a scope. A cost platform has its own, much smaller vocabulary: view reports, edit schedules, approve remediation. Import has to map the first onto the second without widening anyone’s access.

Why import must never auto-apply

Permission to administer infrastructure is not the same as permission to operate a cost platform. An engineer with broad rights in one AWS account was granted them for that account’s workloads, not to change schedules for the whole organization. If an import applied every translated grant automatically, it would silently hand out access on the strength of permissions given for something else. ZopNight’s design takes that position explicitly: import produces suggestions only, and nothing is written until an admin applies them.

How ZopNight’s import works

1. Import. From a connected AWS, GCP, or Azure account, an admin runs Import IAM, which reads the account’s users, groups, and roles.
2. Review. Every proposed user, team, and role is shown before anything changes. Known cloud policies and roles map to a curated ZopNight policy set; custom roles are translated action by action; anything unrecognized lands in a Needs Attention list.
3. Fill gaps. Missing email addresses can be entered one by one or by CSV, then applied again.
4. Apply. Only now are ZopNight users, teams, and roles written. The customer’s own cloud IAM is never modified.

Two safeguards are built in. Organization-management grants, meaning role, user, assignment, and organization administration, are never auto-imported, even from administrator-level roles such as AWS AdministratorAccess; an admin promotes those later from Settings. And imported teams arrive with members only when the optional group-read grant (Cloud Identity on Google Cloud, Microsoft Graph on Azure) is present; otherwise the teams arrive empty.

Re-importing is idempotent, so running it again after a reorganization updates rather than duplicates. Disconnecting removes everything that was imported from that account, and deleting the cloud account cleans up its imported identities as well.

Getting value from it

• Clean up stale cloud identities first. Import mirrors what is there, including people who have left.
• Decide which cloud groups correspond to ZopNight teams, because team membership is what scopes access to a team’s resources in ZopNight RBAC.
• Treat the Needs Attention list as a review of custom roles you may no longer need.

For the step-by-step flow, see how to import cloud IAM users and roles; for tracking what imported users then do, see audit trails.