Contents:
- Tanzu Mission Control - Access Policies Lab Guide
- Introduction
- Lab Exercises
- Step 1 : Open the Policies page
- Step 2 : Select the view for applying access policies
- Step 3 : Apply access policies
- 3.1: Apply policies on Organization
- 3.1.1: View default organization access policies
- 3.1.2: Add new role binding to organization
- 3.1.3 Click on Role arrow to list the valid roles and choose a role:
- 3.1.4 Click on Role arrow to list the valid roles and choose a role:
- 3.1.5 Fill in the User identity and click Add, for more Identities to the same role click on Add for each identity
- 3.1.6: Click "Save" to add the new role binding.
- 3.1.7: Edit/Delete existing role binding
- 3.2: Apply policies on Cluster group
- 3.3: Apply policies on Cluster
- 3.4: Apply policies on Workspace
- 3.5 Apply policies on Namespace
- 3.1: Apply policies on Organization
- Validate Lab Guide
This document is intended to provide a guide to exploring basic usages of access policies in TMC through its UI.
TMC provides two views to set access policies
Clusters View Access policies can be set at organization, cluster group and clusters level. The policies at a resource level are
-
Inherited Access Policies Policies set at organization gets inherited to all the cluster groups and clusters under the organization. Policies set at cluster group gets inherited to all the clusters under the cluster group.
-
Direct Access policies Policies can be applied directly on the Organization, Cluster group and clusters. Workspaces View Access policies can be set at workspace and namespace level.
-
Inherited Access Policies Policies set at organization gets inherited to all the workspaces and namespaces under it. Policies set at workspace gets inherited to all the namespaces under it.
-
Direct Access policies Policies can be applied directly on the workspace and namespace.
This lab has a completion difficulty of Partial
. Please see the rubrik below for an explanation of lab completion difficulty rankings
Lab Completion Difficulty Rankings:
- Difficulty Levels:
Complete
- A lab guide with a difficulty of
Complete
includes comprehensive, click-by-click instructions, usually with a screenshot for every command entered.Complete
lab guides must be associated with an online lab environment fully prepped to execute the exact instructions provided in the lab guide. Most users could successfully execute the steps in aComplete
lab guide, even if they do not have expertise in the subject, by following detailed instructions.
- A lab guide with a difficulty of
Partial
- A lab guide with a difficulty of
Partial
includes full instructions to complete the exercise, with enough detail to where a user with moderate experience in the subject matter could complete the exercise.Partial
lab guides provide a level of detail similar gto most typical technical documentation, where the user is expected to be able to configure their lab environment with dependencies required for the exercise, and to contextualize general instructions to the users own environment.
- A lab guide with a difficulty of
Challenge
- A lab guide with a difficulty of
Challenge
is designed to be technically challenging for the guide's target audience to complete.Challenge
lab guides do not include comprehensive instructions, and intentionally leave out details required to complete exercises as a challenge or test of the users proficiency in a topic.
- A lab guide with a difficulty of
The demo in this document is conducted with a development TMC stack in which a Kind cluster is attached.
In order to demonstrate applying and viewing access policies a kind cluster (kind) is attached under the default cluster group and
a namespace (demo-ns) is created under default workspace.
Click on Policies tab on the leftmost panel and choose the Policy Type "Access" from top panel.
Select CLUSTERS view to apply access policies on the cluster Or Select WORKSPACES view to apply access policies on the namespaces.
- Click on Organization name on left panel under Access Policies.
- Click on organization name under "Direct Access policies" tab on the right to expand Policies to view the role bindings.
- There is a default policy that is auto applied to all the Organizations, it grants Organization.admin role to all members of csp:org_owner and tmc:admin group and organization.credential.view role to members of csp:org_member group.
Click on "New Role Binding" button under "DirectAccess Policies" panel.
3.1.5 Fill in the User identity and click Add, for more Identities to the same role click on Add for each identity
Click on EDIT button to add/delete user/group identities to a role.
Click on DELETE button to delete a role binding.
3.2.1: View inherited policies from Organization and default direct access policies for cluster group
- Click on cluster group name (default) in left panel under CLUSTERS view in Access Policies panel
- Click on organization name under "Inherited clustergroups access policies" tab on the right to expand inherited org policies to view the role bindings.
- There is a default cluster group access policy that is auto applied only to the "default" clustergroup , It grants cluster.admin and clustergroup.edit role to all members of csp:org_member.
- These default policies are not applied to the user created cluster group.
It is similar to the demo steps as of Organization in previous section.
On cluster group level inherited organization policies cannot be changed.
It is similar to the demo steps as of Organization in previous steps
On cluster level inherited organization and cluster group policies cannot be changed.
- Click on Workspace name(default) on left panel under Access Policies under WORSPACES view tab.
- Click on organization name under "Inherited workspace Access policies" tab on the right to expand Policies to view the role bindings.
- There is a default workspace access policy that is auto applied only to the "default" workspace , It grants workspace.edit role to all members of csp:org_member.
- These default policies are not applied to the user created workspaces.
It is similar to the demo steps as of Organization in previous steps
On workspace level inherited organization policies cannot be changed.
- Click on Namespace name(demo-ns) on left panel under Access Policies under WORSPACES view tab.
- Click on organization name, workspace name(default) clustergroup name(default) under "Inherited namespaces access policies" tab on the right to expand Policies to view the role bindings.
It is similar to the demo steps as of Organization in previous steps
On namespace level inherited organization policies cannot be changed.
If you were able to complete this lab successfully without any significant problems, please sign the validate.md file located in this directory.
If you encountered any problems or have suggestions or feature requests, please open an issue ticket on this repository.
If you have any updates or improvements for this lab guide, please open a PR with your updates.
Thank you for completing the Tanzu Mission Control - Access Policies Lab Guide!