Use access policies to implement role-based access control (RBAC) for the users and resources in your organization.
For a manageable security posture, VMware Tanzu Mission Control allows you to secure the resources in your organization with access policies that govern the users and groups that can see and edit them. This section discusses access policies; see Users and Groups for more information about combining users into manageable groups.
Managing Service Security Posture with Access Policies
Access policies allow you to control the permissions granted to the users of Tanzu Mission Control in your organization. Each object in your organizational hierarchy has an access policy where you can specify permissions using role bindings that associate a role with an identity. For more information about the organizational hierarchy, see What is Tanzu Mission Control.
In addition to the direct policy defined for a given object, each object also has inherited policies that are defined in the parent objects. For more information about policy inheritance, see Policy-Driven Cluster Management.
There are predefined roles for each type of object in your organization. Each role defines a set of permissions that apply to a given type of object. By contrast, the access policy where you define the role binding defines the scope to which the role applies. To learn how to create role bindings in Tanzu Mission Control, see Managing Access to Your Resources in Using VMware Tanzu Mission Control.
For example, the
cluster.edit role grants permission to make edits to a cluster. If that role is bound to a given identity (group or individual) in the access policy for a cluster, this set of permissions applies only to the cluster. But if you bind the
cluster.edit role to an identity in a cluster group access policy, members included in that identity are granted permissions to edit all clusters included in that cluster group.
|Role||organization||cluster group / cluster / workspace||namespace||Notes|
||x||x||x||Grants full root-level access to the object, including permission to see and edit access policies.|
||x||x||x||Grants permission to view the object, and create and delete child objects.|
||x||x||x||Grants permission to see the object and its resources and child objects.|
||x||Applicable only on the workspace, grants permission to create a namespace. Identities with this role are assigned the
||x||Grants permission to create and edit credentials for data protection, connections to cloud provider accounts, and other features.|
||x||Grants permission to see and use credentials for data protection, connections to cloud provider accounts, and other features.|
Best Practices for Assigning Roles
- Use groups in role bindings rather than individual identities.
- Use a Kubernetes service account identity in role bindings for permissions that are not tied to individuals.
- Assign only the roles that grant the permissions necessary for an entity to perform its function within the organization.
- Use the
.adminrole judiciously and sparingly. The
.adminrole allows full root access to all of the resources and policies of an object, and recursively for its child objects, from within Tanzu Mission Control and also directly in the cluster.
About Roles in VMware Cloud Services
- Service Member
This role provides typical service usage permissions for most members in your organization.
- Service Admin
This role provides additional permissions for administrators of the service in your organization.
As an organization owner, you can also invite additional members to your organization, and specify the organization and service roles in the invitations that you send out. For information about assigning roles in VMware Cloud Services and inviting users to join your organization, see Identity & Access Management in the Using VMware Cloud documentation.
Initial Security Posture for Default Resource Groups
The initial setup for your organization in Tanzu Mission Control contains a cluster group named default and a workspace named default. To help you get started, these default resource groups have relaxed permissions that allow all authenticated users associated with the service member role to create and manipulate clusters and other resources.
As a best practice, create new cluster groups and workspaces for both development and production activities, and apply appropriate access control to them. Use the default cluster group and workspace only to initially familiarize your users with the service.