Members, groups, service users and roles

A principal is anything a policy can be attached to. An organization has four kinds:

Every principal belongs to one organization, and its permissions apply only there. To give a person access to two organizations, make them a member of both, or let them assume a role in the other organization.

Members

A member is a Hexel account in your organization. In policy attachments and group memberships, a member is identified by their user ID (user_id in the members list), with the target type USER.

Each member has one member role: owner, admin, member or viewer. The role decides the member's default access. You set it when you invite or add the member and can change it later. See Members and invitations.

What a member gets by default

When you create an organization, Hexel Studio creates four membership groups, one per member role, and attaches managed policies to each. Every member is in exactly the group of their role. Changing a member's role moves them to the other group, and removing a member from the organization removes them from it.

The policies attached to these groups give each role the following access:

The managed policies behind each role:

• Owner: Organization Owner Full Access (pol_org_owner_full).
• Admin: pol_billing_full, pol_compute_full, pol_data_full, pol_deploy_full, pol_dir_user_mgmt, pol_env_full, pol_iam_admin, pol_memory_full, pol_monitoring, pol_org_member, pol_skills_full, pol_support_customer, pol_support_org_admin, pol_svc_account, pol_tool_full, pol_ws_full.
• Member: pol_compute_readonly, pol_data_readonly, pol_deploy_full, pol_dir_readonly, pol_env_full, pol_memory_user, pol_monitoring, pol_org_readonly, pol_skills_publisher, pol_support_customer, pol_tool_execute, pol_ws_full.
• Viewer: pol_billing_readonly, pol_deploy_readonly, pol_dir_readonly, pol_env_readonly, pol_iam_readonly, pol_memory_readonly, pol_monitoring, pol_org_readonly, pol_skills_readonly, pol_support_customer, pol_ws_readonly.

Read any of them with GET /v1/policies/<policy-id>.

You can't add or remove members of a membership group, or rename or delete it, through the groups API: use the member role instead. You can attach more policies to a membership group to give every member of that role more access. Detaching one of its default policies does not last: Hexel Studio attaches the default policies again whenever a member joins or changes role.

Beyond the defaults

To give a member more access than their role, attach a policy to them, add them to a group that has the policy, or assign them a permission set. Their access is the union of all of these. Nothing you attach can take access away: Deny statements are not applied to API calls yet (see Policies). To give someone less access than a role, give them a lower role and add what they need.

Adding a member to a workspace's member list does not change their permissions. Workspace access comes from policies and permission sets only.

Groups

A group is a set of members. A policy attached to a group applies to every member of the group, and a permission set assigned to a group grants to every member. Groups are the simplest way to manage access for teams. See Manage groups.

GET /v1/groups returns three kinds of group:

Groups don't nest: parent_group_id is stored but a member of a child group does not get the parent group's policies.

Service users

A service user is a non-human identity for scripts, servers and CI jobs. It belongs to your organization, is not a member, and signs in with an API key or an OAuth client. Its ID starts with su_ and its target type is SERVICE_USER.

A new service user has no permissions. It can do only what the policies attached to it, and permission sets assigned to it, allow. Give it the smallest set of actions its job needs. See Service users and API keys.

Roles and role sessions

A role is an identity that others assume for a limited time. It has its own policies (attached with target type ROLE) and a trust policy that says who may assume it. Assuming a role returns a role session: an access token whose caller is the role, not the person or service user who assumed it.

• A role session gets only the policies attached to the role. The policies of whoever assumed it don't apply during the session.
• Policies attached to a role you create grant nothing outside its sessions. Being trusted by a role does not give you its permissions until you assume it.
• A role can be limited to one workspace or one environment. Its sessions then have its permissions in that scope only and none at organization level.
• A role can have a permission boundary. Its sessions get only the actions that are both in the role's policies and in the boundary.
• A session lasts up to the role's max_session_duration (900 to 43,200 seconds, default 3,600). You can revoke every session of a role at once.

Roles are how you give temporary or cross-organization access. See Roles and role sessions to create one and assume it.

How a principal gets a permission

Policies and permissions explains how these grants combine into a decision.