Introduction to FlexOrgs

What Are FlexOrgs and Why Use Them

FlexOrgs provide organizations greater control over user access, sharing, and delegation across multiple levels of organizational hierarchy.

With FlexOrgs, you build and manage your organization as a hierarchy composed of multiple organizational units (OU). Each organization unit is assigned access and responsibility for managing resources through the VMware Tanzu CloudHealth Platform.

With FlexOrgs you can:

• Create an organizational structure that reflects your company’s hierarchy.
• Define and link organizational units that reflects how your cloud infrastructure should be managed.
• Separate each organizational unit in the hierarchy so each OU views only its infrastructure.
• Map users to specific organizational units and control their levels of access in each organizational unit.

Basic Units of FlexOrgs

FlexOrgs are made up of organizational units (OU), users, user groups, and role documents.

• Organizational units define what content and data an assigned user can see in the platform, and are based on AWS accounts, Azure subscriptions, or GCP projects. OUs are organized under a top-level organizational unit (TLOU) into a hierarchy of tiered parent OUs and child OUs. For more information about organizational units, see Use Organizational Units to Define Organizational Hierarchy.

• Users are people who have access to the Tanzu CloudHealth platform.

• User groups define characteristics of an OU, and assign permissions to users within the user group using role documents. User groups can give a user access to one or more OUs. Users can be assigned to user groups manually or using SSO. For more information about user groups, see Use User Groups to Define FlexOrgs Relationships.

• Role documents are a list of permissions that define what a user can do with content in the platform. Role documents are attached to user groups. For more information about role documents, see Use Role Documents to Define Permissions.

Use Organizational Units to Define Organizational Hierarchy

An organizational hierarchy is represented as a collection of connected organizational units (OUs). Each OU owns a portion of the cloud infrastructure. The OU at the top of the hierarchy, called the Top-Level Organizational Unit (TLOU), owns all the assets for the entire organization.

At each level of the hierarchy, there are operational rules to keep in mind.

Top-Level Organization Unit Owns All Assets

Operational Rule 1: Each Tanzu CloudHealth customer can have one and only one TLOU, which owns all assets of the Organization.

When the Tanzu CloudHealth customer Acme Corporation signs into the Tanzu CloudHealth Platform, a Top-Level OU (TLOU) called Acme Corporation is created. This TLOU owns all the cloud assets of this customer. There can be only one TLOU per Organization. Cloud resources, which are called assets in the Tanzu CloudHealth Platform, can be of various types, for example, EC2 Instances, EBS Volumes, S3 buckets.

Decentralization through Hierarchical Child OUs

Operational Rule 2: Each child OU can have only one parent OU, but a parent OU can have many children OUs.

Operational Rule 3: An Organization can have a maximum of 10 levels. Each level can have any number of OUs, but an entire Organization can have a maximum of 5,000 OUs.

In this example, TLOU Acme Corporation owns 1,000 cloud assets. These assets can be distributed among smaller child OUs to establish operational boundaries. Then each OU can operate on its own, providing access to specific users and groups and administering the assets it owns. A child OU can only inherit assets belonging to its parent OU. A parent OU can assign an asset to only one of its child OUs - in other words, each asset can only belong to one OU per hierarchy level. Each child OU can have only one parent OU, but a parent OU can have many children OUs.

An easy way of achieving this division is to use the departmental or team-specific hierarchy in Acme Corporation and implementing it in the Tanzu CloudHealth Platform.

When built, this is how a three-level hierarchy translates into an ownership structure in the Tanzu CloudHealth Platform.

Level	What’s at this level	Designation in Tanzu CloudHealth
Root	Acme Corporation	TLOU
Level 1	Business Groups (x2)	2 OUs
Level 2	Products (x4)	4 OUs
Level 3	Teams (x8)	8 OUs

Use User Groups to Define FlexOrgs Relationships

A user group is a collection of users that all require the same level of access to content in one or more OUs. For example, a user group might be defined as employees belonging to the same team. User groups define the relationship between users, OUs, and role documents. The user group links role documents to OUs, defining the level of access that users in the user group have to that OU or OUs. A user group can contain multiple OU-role document pairings, which allows you to grant users varying levels of access to different OUs within a single user group.

For help with creating user groups, see Create User Groups.

One OU can be assigned to multiple user groups. This allows users from different user groups to have access to the same OU at varying permission levels.

You can configure your user groups to automatically add users upon login based on SSO attributes. You can also manually assign users to a user group.

User Groups and Role Document Hierarchy

Role document hierarchy only functions within a user group. If an OU is assigned to multiple user groups, the role document hierarchy in one user group does not affect the role document hierarchy in a second user group - unless a user is assigned to both user groups. If a user is assigned to multiple user groups for the same OU, conflicting permissions are resolved by Deny overruling Allow.

For example, there are two user groups in the same OU. The Admin User role document in User Group A grants its users total read and edit access to the Tanzu CloudHealth Platform. The End User role document in User Group B grants read-only access to the entire Tanzu CloudHealth Platform. Even though both user groups have the same OU, the two user groups are entirely distinct and do not affect each other. Users in User Group A do not lose edit access to the Platform.

One user - User I - belongs to both user groups. Her Admin User role document in User Group A has higher privileges than her End User role document in User Group B. In this case, role hierarchy kicks in. The End User role document’s Deny permission overrules the Admin User role document’s Allow permission. User I has read-only access to the Platform for this OU. The other members of User Group A maintain read and edit access because they are not in another user group for this OU.

Use Role Documents to Define Permissions

A role document defines the permissions granted to a user, thereby determining which Platform features a user has access to. For example, an administrator role document may grant full read/edit permissions, while an end user role document may grant limited read permissions. Role documents are assigned to OU’s and users via user groups. Multiple role documents can be assigned to a single OU, creating an overlapping tapestry of permissions.

For help with creating role documents, see Create Role Documents.

Role documents apply to the OU hierarchy from the top down. Therefore, the permissions in a role document assigned to a parent OU are also assigned to a child OU. If a parent OU and child OU have conflicting permissions, the Deny permission always overrules the Allow permission.

Operational Rule 4: Child OUs inherit the permissions of their parent OUs’ role documents.

Operational Rule 5: When an OU’s assigned or inherited role document permissions conflict, Deny overrules Allow.

Example Role Document Hierarchies

Example 1

In this example, a parent OU, Acme Corporation, has two child OU’s: Business Group 1 and Business Group 2. Acme Corporation A has been assigned a role document that allows users in this OU to create, read, update, and delete Perspectives in the Tanzu CloudHealth Platform. Business Group 2’s role document also allows full access to Perspectives, but Business Group 1’s role document denies any access. Users in Acme Corporation and Business Group 2 can both create, read, update, and delete Perspectives, but Users in Business Group 1 cannot because Business Group 1’s deny permission overrules Acme Corporation’s allow permission.

Example 2

In this example, the parent OU, Business Group 1, is assigned a role document that denies create, read, update, and delete access to Perspectives. The permissions of role documents assigned to the parent OU are also assigned to the child OU, so both Product 1.1 and Product 1.2 are assigned this permission as well. Deny permissions overrule allow permissions, so users assigned to Product 1.1 and Product 1.2 cannot access Perspectives.

Example 3

In this example, an OU has been assigned two different role documents. Role Document B denies create, read, update, and delete access to Perspectives, while Role Document C allows access. Deny permissions overrule allow permissions, so users assigned to Team 1.1.1 cannot access Perspectives.

Best Practices for Planning FlexOrgs

Before configuring FlexOrgs in Tanzu CloudHealth, you should plan how to organize and configure each of the FlexOrgs building blocks: organizational units (OU), role documents, and user groups.

Determine your organization goals

It is important to know what your organization’s end goal is when building FlexOrgs so you know where to focus your efforts as you begin the building process.

Delegation of resource management

In larger organizations, scale can be a big problem. FlexOrgs helps solve this issue through increased delegation of administrative controls and responsibilities to users at different levels within the organization. You can provide the exact level of permissions to administrators, power-users and regular users at each level of the organization. Users can then create their own content like reports and policies that remain within their OU.

If delegation of resource management is your organization’s goal within FlexOrgs, Tanzu CloudHealth recommends starting by defining your organizational hierarchy:

• How many tiers does your organization need?
• How do you define each tier - by department, BU, or team?
• Which group of users reside at each tier?

Once this framework is in place, you can then strategize which sets or permissions are appropriate for each group of users.

Security

FlexOrgs provides security-conscious organizations with powerful controls to limit visibility, prevent unwanted actions, and prevent users from seeing information that they should not. Using a combination of system-defined or custom-built role documents and a well-thought-out FlexOrgs structure, you can tightly control the visibility and actions of every user.

If security is your organization’s priority, Tanzu CloudHealth recommends focusing on defining who your administrators and power-users are. Understand the default permissions provided by our system-defined Admin and Power User Role Documents to determine whether you should use these out-of-the-box permission sets or custom role documents. If you need custom role documents, begin building these first before you create your FlexOrgs hierarchy.

Tanzu CloudHealth recommends testing your role documents within a set of sample OUs and user groups before committing to your final build process.

Visibility

FlexOrgs provides a solid foundation for users to focus on the reports and policies that matter most to them. FlexOrgs can help users cut down on clutter and avoid unnecessary noise by removing their ability to roam throughout the organization as you deem necessary.

If Visibility is your core goal, Tanzu CloudHealth recommends focusing on your AWS account, Azure subscription, and GCP project assignment strategy as it applies to the hierarchy of your organization. Start by building a map of your accounts as they pertain to each Department, Business Unit, Team, or whatever unit you use to define your OUs. Keep in mind that accounts and assets flow down to avoid pitfalls when you begin building your hierarchy.

Determine your organizational source of truth

Your Cloud Service Provider (CSP)

Amazon, Azure and Google Cloud Platform all provide the ability to build out an organizational structure. If you’ve done this with your CSP already, consider replicating that structure within Tanzu CloudHealth to save yourself time.

Identity Provider (IDP)

If you use an SSO service to provide your users with easy access to their applications, Tanzu CloudHealth recommends recreating this structure in Tanzu CloudHealth to make user access simpler. FlexOrgs allows you to pass any key value pairs you use in your SSO structure to match users to the right User Groups. As a result, when a user logs into the platform, they’re seamlessly placed in the proper OUs with the proper permissions.

Start from Scratch

If you aren’t using your CSP or IDP as an organizational model, Tanzu CloudHealth recommends designing a mapping document in a spreadsheet that details each OU at each tier and the accounts that live within the OU.

Determine your account, subscriptions and projects assignment strategy

Accounts and the assets within them flow down through the organizational hierarchy in FlexOrgs. Every account you have configured resides in the Top Level Organizational Unit (TLOU). The TLOU is the pool of accounts you can pull from as you build out each FlexOrgs tier.

For example, you want to place a certain AWS Account at the fourth tier in one branch of your FlexOrgs hierarchy. To reside at the fourth tier in that branch, the account must also be in that OU’s parent in the second and third tiers. This can have an impact on your desired visibility and security goals. Make sure you define your account assignment and organizational hierarchy maps carefully.

If you’ve already built classic organizations in Tanzu CloudHealth, contact Support for a report that describes where your accounts currently overlap and for guidance with upgrading from classic organizations to FlexOrgs.

Determine how your users are grouped

Before you start the building phase of your FlexOrgs project, determine how your users are grouped.

In order for a user to live within one or more OUs, they must be assigned to a User Group. You can assign users to a User Group by manually assigning them in the platform, by mapping your SSO key value pairs to each user, or with a combination of both approaches. When using both methods of user group assignment, a manual user assignment takes precedence over an SSO assignment.

Determine your required levels of access

FlexOrgs provides three system-defined role documents for Administrator, Power User, and Standard User level permissions. Review the capabilities of these role documents to determine whether you need to create additional custom role documents. Some teams may find that the default role document permissions are sufficient.

You can also build restrictive role documents to remove access to certain features and capabilities for certain user groups. Restrictive role documents act in the opposite way a typical role document does; toggling a permission disables it.