Use projects in VMware Aria Automation for Secure Clouds to control access for your organization
VMware Aria Automation for Secure Clouds uses projects to separate an organization's cloud accounts into discrete collections with separate authorization. Using projects, you can ensure the appropriate access and control of information is available to your users while the information security team can centrally govern security policy and administer the service.
This is particularly important for organizations with multiple teams that have separate cloud resources to support different initiatives. These teams can use projects to understand and act on the security and compliance of their cloud accounts without having unnecessary access and visibility to the security posture of other groups.
The ability to separate your cloud resources into distinct units that can be associated with a given team, service, or initiative is essential for you to efficiently manage your organization's cloud security at scale. Using projects, a security team can group cloud accounts together and manage access so that users only see and manage the resources they're responsible for. This self-service model empowers teams to take an active role in managing their own security insights and resolutions.
Organization access
In VMware Aria Automation for Secure Clouds, an organization is the top-level context that contains all customer cloud accounts. You have one organization per service subscription.
All cloud accounts in an organization must be assigned to a project. All organizations have at least one project, the Default Project, that is created automatically when the organization is provisioned.
Here is a simple example of what one subscription's account hierarchy might look like.
Every cloud account in this example is unique, as cloud accounts can't be shared across multiple projects in the same organization. Cloud accounts from different providers can be part of the same project, however.
The Default Project contains any cloud accounts that aren't assigned to a named project. This project can be viewed only by a user (typically an administrator) with access to the organization context.
Depending on access, you can switch from the organization or project context with the context switcher in the upper-right corner of the app.
Changing contexts affects the cloud accounts, findings, and reporting metrics visible from the dashboard. The organization context provides visibility to all cloud accounts in all projects, while the project context presents only the data from the selected project.
Users and roles
A user is invited or otherwise granted access to a VMware Aria Automation for Secure Clouds deployment through federated identity, managed in the VMware Cloud Services Platform (CSP). From the CSP dashboard, you can give a user access to the organization, or one or more projects. You must also give the user a role that defines the actions they can perform. There are three role types for the organization and project contexts.
- Admin - Provides full create and edit capability for the assigned context. Typically reserved for central security teams at the organization context and team leads or managers in the project context.
- Analyst - Provides limited administration capabilities. Intended for users who are primarily responsible for investigation and resolution of security findings.
- Viewer - Provides read-only permissions for users who don't need to perform actions.
Any role assigned to a user at the organization context is passed down to all projects as well. For example, the user Jane in the figure below has viewer access to the organization. Because the viewer role was assigned at the organization context, she also has viewer access to all projects in the organization. Should Jane need elevated permissions in one or more projects, then she must be assigned explicit access to those projects with the desired role. The graphic demonstrates that Jane has also been assigned the admin role for the dev project in addition to her viewer role for the organization.
Note that a more privileged organization role is prioritized over a less privileged project role. This means a user with admin privileges at the organization context can't be assigned an analyst or viewer role for a specific project; the higher organization role inherits over any lesser roles.
If the user has one or more roles assigned, they are given permissions based on the union of the roles assigned.
To simplify role assignment, users can be added to a group. That group can be assigned a role, along with access to the organization or a project. In the example figure above, the Operations group has been assigned the admin role for the prod project context. This group does not have access to the dev project or organization context.
CSP roles
There are also roles in CSP that you must be aware of. To see an example, go to the Identity & Access Management and select Add Users.
Any user you onboard into your deployment must either be assigned an Organization Owner or Organization Member role. Owners can delegate rights and access to others users from the CSP dashboard, while members cannot.
Service roles are assigned when a user needs access to VMware Aria Automation for Secure Clouds's organization context, and correspond to the admin, analyst, and viewer roles previously defined. Users who only need project-level access should not have a service role assigned. Instead, they're onboarded into CSP as members and assigned project access through the VMware Aria Automation for Secure Clouds Projects page.
You can review the Manage users section for specific directions on how to add organization or project-level users.
Role privileges for projects and organizations
The privileges a role permits differ based on its assigned context (like an organization admin and a project admin). Most privileges associated with account creation and management are restricted to the organization context because it's typically owned by a central administrative or security team. Organization roles are used to onboard accounts into VMware Aria Automation for Secure Clouds, manage projects, and enforce security requirements. Consult the matrix below to see which privileges are available for roles at either context.
| Organization Context | Project Context | ||||||
|---|---|---|---|---|---|---|---|
| Category | Action | admin | analyst | viewer | admin | analyst | viewer |
| Projects | Edit | Y | N | N | N | N | N |
| Read | Y | N | N | N | N | N | |
| Cloud accounts | Edit | Y | N | N | N | N | N |
| Read | Y | Y | Y | Y | Y | Y | |
| Usage | Read | Y | N | N | N | N | N |
| Dashboards | Set default | Y | N | N | Y | N | N |
| Create | Y | Y | N | Y | Y | N | |
| Edit (self) | Y | Y | N | Y | Y | N | |
| Edit (any) | Y | N | N | Y | N | N | |
| Read | Y | Y | Y | Y | Y | Y | |
| Explore | Read | Y | Y | Y | Y | Y | Y |
| Entitlements | Read | Y | Y | Y | Y | Y | Y |
| Findings | Read | Y | Y | Y | Y | Y | Y |
| Reports | Edit | Y | Y | N | Y | Y | N |
| Run | Y | Y | N | Y | Y | N | |
| Read | Y | Y | Y | Y | Y | Y | |
| Alerts | Edit | Y | Y | N | Y | Y | N |
| Read | Y | Y | Y | Y | Y | Y | |
| Integrations | Edit | Y | N | N | Y | N | N |
| Read | Y | Y | Y | Y | Y | Y | |
| Rules | Edit | Y | N | N | N | N | N |
| Read | Y | Y | Y | Y | Y | Y | |
| Custom rules | Edit | Y | N | N | N | N | N |
| Suppressions | Edit | Y | N | N | N | N | N |
| Read | Y | Y | Y | Y | Y | Y | |
| Suppression request | Finding Edit | Y | Y | N | Y | Y | N |
| Policy Edit | Y | Y | Y | N | N | N | |
| Approve | Y | N | N | N | N | N | |
| Read | Y | Y | Y | Y | Y | Y | |
| Remediation worker groups | Edit | Y | N | N | N | N | N |
| Read | Y | Y | Y | N | N | N | |
| Remediations | Edit | Y | N | N | N | N | N |
| Run | Y | Y | N | Y | N | N | |
| Read | Y | Y | Y | Y | N | N | |
To expand on these permissions:
- Rules are centrally managed by the organization and apply identically to each project. Any custom rules made apply to all accounts, so they can only be created at the organization context.
- Suppressions for a finding can be requested by a project or organization user, but only an organization admin can approve or deny the request. Project users may request a suppression policy in the context of their current project, while organization users may request a suppression policy for any project, or the entire organization.
- Alerts, integrations, and reports can be created in either context. At the organization context, the user can see all alerts, integrations, and reports created. Features are visible and can be modified in the organization. To see or modify these features, you must be in the context it was created in. You can create a report for all cloud accounts in the organization, but that report is available only from the organization context. If a report or alert is created in a project, you can only see or manage them in the context of that specific project.
