# 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.
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.
See [Connecting an Account to a Microsoft Active Directory Identity Provider](connect-to-idp.md#connect-to-idp) for detailed steps.
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.
## 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.
**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.
### 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.
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.