IAM (identity and access management) decides what each person and program in your organization can do. Users and bots get access from the policies attached to them, directly or through the groups they’re in. There are no roles: policies are the only source of access. API keys let code act as a user or bot, and SCIM lets your identity provider manage your people and groups.
- Users: invite people, change their groups, remove them.
- Groups: give a set of users and bots the same policies.
- Bots: non-human members for scripts and automation.
- Policies: the policy document format, managed policies, and every action.
- API keys: credentials for code, acting as a user or bot.
- Directory: connect your identity provider for SSO and verify your email domains.
- SCIM provisioning: sync people and groups from your identity provider.
In the console, IAM has a page for each of Users, Groups, Bots, Policies, Directory and SCIM.
Principals
| Principal | What it is |
|---|---|
| User | A person. Each person belongs to one organization at most. |
| Bot | A non-human member of one organization. A bot can’t sign in; it acts only through its API keys. |
| Group | A set of users and bots. Policies attached to a group apply to every member. |
The root user is the person who created the organization, until they make someone else root. Policies never restrict the root user: they can do everything, and a deny statement doesn’t apply to them. Only the root user, signed in to the console, can delete the organization or make another user root.
An API key acts as its owner, a user or a bot, with exactly the owner’s access. A key has no permissions of its own, so its access changes when its owner’s does. A key owned by the root user has the root user’s access, except for the root-only actions above.
How access is decided
Every request is checked when it’s made, against the policies that apply at that moment. For an action on a resource:
- If the caller is the root user, the request is allowed.
- If any statement in any policy that applies to the caller denies the action on that resource, the request is denied.
- If any statement allows the action on that resource, the request is allowed.
- Otherwise, the request is denied.
The policies that apply are those attached to the user or bot directly and those attached to every group it’s in. A user or bot with no policies can do nothing.
A request the caller isn’t allowed to make returns 403 with the error code access_denied. A request for an organization the caller doesn’t belong to returns 404, as if the organization didn’t exist.
List operations for projects, groups, bots and custom policies check the list action on each item, and return only the items the caller may list. They return 403 only when the caller may list none.
See Policies for the document format and the full list of actions.