Skip to content
qibdo qibdo
Theme
Book a demo

Overview

IAM lets you manage who can do what, and where, across your on-premise infrastructure and every public cloud you operate. It provides fine-grained access control in a single console: it manages identities, bundles permissions into roles, and grants them within the right scope. The goal is to consolidate access control across all your clouds into one consistent model, so the same identities and the same rules apply everywhere, all in one.

Every other service relies on IAM to identify the caller and decide whether an action is permitted.

  • Identities: the users and service accounts that call the platform, each keyed by a unique email.
  • Tokens: the credentials a caller presents. Users hold opaque session tokens, where the raw value is returned only once, at sign-in, then referenced by a hash, with the source IP, user agent, and expiry recorded. Service accounts authenticate with signed JWTs.
  • Permissions: granular actions named <service>.<resource>.<action> (for example compute.vm.create), system-defined and read-only.
  • Roles: named bundles of permissions, either system-defined or custom.
  • Bindings: grant a role to an identity within a scope (group, workspace, organisation, or platform), optionally constrained by a policy.
  • Policies: conditions that narrow when a binding applies, by source IP, time window, or which services a role is allowed to grant.
  • Operations: the record returned by every IAM mutation, capturing what changed and its outcome.

Authorization is composed: a request is allowed when the caller holds a binding whose role carries the required permission, at a scope that covers the target, and whose policy conditions (if any) hold.