Introduction to Identity and Access

Accounts and Projects

The virtual resources of the Zadara Cloud Services region are managed through an administrative hierarchy of accounts and projects as shown in figure below. The Zadara Cloud Services region consists of one or more accounts, each of which contains one or more projects. Virtual resources such as VLANs, instances, volumes, images and snapshots are created per project, account or region. Users or User Groups, which are members of an account, can be assigned different projects within their account through a Zadara Cloud Services role, together with one or more Zadara Cloud Services and AWS API policies. This assignment enables you to provide access to Zadara Cloud Services to numerous users or groups, while dividing and separating the resources that each user will be able to view, create, and manage.

image1

See the video on the basics of zCompute Identity and Access:

Identity Provider (IdP)

Zadara Cloud Services users and groups can be accessed from an identity provider such as MS Active Directory. This is done by first connecting the Zadara Cloud Services account to the MS Active Directory. Connection with the identity provider must be configured independently for each Zadara Cloud Services account.

Once an account becomes connected to Active Directory, the newly available Active Directory users and groups must be assigned Zadara Cloud Services Project Roles and Policies. This can be done either through CLI commands or via the GUI.

Each of these users will now be able to login to Zadara Cloud Services with their Active Directory name and password.

If an account is not connected to an identity provider, users can be manually created within Zadara Cloud Services as members of this account.

Note

An account with an IdP configured should have no local member users, because keeping local member users:

  • Bypasses policies enforced by the IdP

  • Defeats some of the purposes of using such an identity provider

Once an IdP is configured, changes cannot be applied to local users.

It is recommended to create and configure a “break-the-glass” local admin user before configuring an IdP.

Roles and Policies

Access to Zadara Cloud Services functionality is gained by assigning the user to one or more projects within this account. The user is then assigned policies and roles per project which are used as follows:

  1. Policies define the ZCS and AWS functionality or APIs, which are being permitted for the user. Policies essentially determine what functionality is permitted. Multiple policies can be assigned.

  2. Roles determines which of those policies or APIs can actually be assigned or used, by a user. Both ZCS and AWS roles are used. A user must be assigned a single ZCS role. In addition, a user may be associated with one or more AWS roles. Roles essentially determine the type of user who is permitted to perform this functionality.

ZCS Roles

There are three Zadara Cloud Services roles, each allowing different functionality, as follows:

  1. Member - This role allows the user to use policies and APIs for creating, viewing, modifying and deleting virtual resources belonging to projects to which the user has been assigned. This is the standard role for most users.

  2. MSP or Tenant Admin - In addition to allowing the use of those policies and APIs which are granted to a Member, the MSP or Tenant Admin role also allows the user to use policies and APIs for creating and managing new projects and users within a specific account, assigning to these users, per project, roles and Zadara Cloud Services and AWS policies. It is recommended that each account have at least one user with this role.

  3. Zadara Ops Admin - In addition to allowing the use of those policies and APIs which are granted to a Member and an MSP/Tenant Admin, the Zadara Ops Admin role also allows the user to use policies and APIs for viewing, creating, managing and deleting all physical resources, such as nodes (servers), disks, storage pools, physical networks, etc., and administrative entities such as accounts. It is possible to create more than one user per region with Zadara Ops Admin rights.

    Note

    The Zadara Ops Admin user admin is only available to a Zadara user.

Two important guidelines concerning the assignment of Zadara Cloud Services roles:

  1. Only assign a single role per project.

  2. When assigning multiple projects to a user, assign the same role for each project.

When Zadara Cloud Services is installed, it comes with a single account containing one project and one user available to Zadara.

  • The account is called cloud_admin.

  • The project inside is called default.

  • The special Zadara user is called admin.

This user, who serves as the System Administrator of the entire region, comes assigned to the ‘default’ project with the ‘Admin’ Zadara Cloud Services role, the ‘FullAccess’ Zadara Cloud Services Policy and the ‘AdministratorAccess’ AWS API policy. This built-in account, project and user cannot be deleted or modified in any way.

Important

It is highly recommended to create and keep a “break the glass“ local account admin user, with its credentials vaulted for future use. (i.e. This is not a personal user who can leave the organization potentially causing the credentials to be lost, but rather a user for emergency “break the glass” use cases).

This admin user can be used for maintenance of the IdP connection if it stops working properly for any reason.

AWS Roles

AWS IAM Roles are policy-based tokens with temporary credentials, allowing a user temporary access to AWS services and actions which the user is normally not permitted to access. These users may be from different projects or even different accounts. These roles can also be embedded into specific instances allowing these instances access to the necessary actions.

Note

The AWS IAM roles are independent of the Zadara Cloud Services roles, which together with Zadara Cloud Services policies, grant access to Zadara Cloud Services services and actions.

The AWS IAM role consists of the following:

  1. Permissions which give access to certain Zadara Cloud Services, supported AWS services or actions.

  2. Trust policy that defines the relationship between user per project and this role.

    1. This nature of the relationship may be ‘allow’ which grants permission to the specified users to assume the role, or ‘deny’ which prevents these users from assuming the role.

    2. This permission may be granted to multiple users of the same projects, different projects within the same account, or even users of different accounts.

  3. The maximum session duration that can be requested when assuming this role.

Policies

Policies can be defined and assigned to a user per project for both Zadara Cloud Services and AWS API. While AWS APIs and Zadara Cloud Services functionality may overlap, they are essentially two independent areas of functionality, requiring separate sets of policies. A user can be granted access to both AWS API and Zadara Cloud Services functionality on the same project.

  1. The two policy types support the granting of access to one area without granting access to the other. For example, users working with only AWS APIs do not need access to the Zadara Cloud Services API/GUI.

  2. The Zadara Cloud Services API is more extensive and all of its functionality is not covered by the AWS APIs.

  3. Even APIs that appear to be similar in AWS API and Zadara Cloud Services API, such as “create vm” and “runinstances”, actually permit different actions.