Starting with Cyfuture Cloud Console 10.2, service providers can use the Cyfuture Cloud Console API to create extensions that provide additional Cyfuture Cloud Console capabilities to the tenants. If a service provider granted you access, you can manage defined entities and share them with other tenants.
Service providers can create Runtime Defined Entities (RDEs) enabling extensions to store and manipulate the extension-specific information in Cyfuture Cloud Console. For example, a
Kubernetes extension can store information about the Kubernetes clusters it manages in RDEs. The extension can then provide extension APIs for managing those clusters using the information from the RDEs.
Access to Defined Entities
Two complementary mechanisms control the access to RDEs.
- Rights - When a service provider creates an RDE type, they create a rights bundle for the type. A service provider must assign you one or more of the five type-specific rights: View: TYPE, Edit: TYPE, Full Control: TYPE, Administrator View: TYPE, and Administrator Full Control: TYPE.
The View: TYPE, Edit: TYPE, and Full Control: TYPE rights work only in combination with an ACL entry.
- Access Control List (ACL) - The ACL table contains entries defining the access users have to specific entities in the system. It provides an extra level of control over the entities. For
example, while an Edit: TYPE right specifies that a user can modify entities to which they have access, the ACL table defines which entities the user has access to.
Table 18-1. Rights and ACL Entries for RDE Operations
Entity Operation |
Option |
Description |
|
Read |
Administrator View: TYPE right |
Users with this right can see all RDEs of this type within an organization. |
|
View: TYPE right and ACL entry >= View |
Users with this right and a read-level ACL can view RDEs of this type. |
|
|
Modify |
Administrator Full Control: TYPE right |
Users with this right can create, view, modify, and delete RDEs of this type in all organizations. |
|
|
Edit: TYPE right and ACL entry >= Change |
Users with this right and modify-level ACL can create, view, and modify RDEs of this type. |
|
Delete |
Administrator Full Control: TYPE right |
Users with this right can create, view, modify, and delete RDEs of this type in all organizations. |
|
|
Full Control: TYPE right and ACL entry = Full Control |
Users with this right and full control-level ACL can create, view, modify, and delete RDEs of this type. |
Sharing Defined Еntities with Another User
If a system administrator published the rights bundle for a defined entity type and granted you ReadWrite or FullControl access or you are the defined entity owner, you can share the access to those entities with other users.
1. Assign the View: TYPE, Edit: TYPE, or Full Control: TYPE right from the bundle to the user roles you want to have the specific level of access to the defined entity.
Note: You must be logged in as a system administrator or organization administrator to assign rights.
For example, if you want the users with the tkg_viewer role to view Tanzu Kubernetes clusters within the organization, you must add the View: Tanzu Kubernetes Guest Cluster right to the role. If you want the users with the tkg_author role to create, view, and modify Tanzu Kubernetes clusters within this organization, add the Edit: Tanzu Kubernetes Guest Cluster to that role. If you want the users with the tkg_admin role to create, view, modify, and delete Tanzu Kubernetes clusters within this organization, add the Full Control: Tanzu Kubernetes Guest Cluster right to the role.
2. Grant the specific user an Access Control List (ACL) by making the following REST API call.
Access_level must be ReadOnly, ReadWrite, or FullControl. User_ID must be the ID of the user to which you want to grant the access to the defined entity.
You must have ReadWrite or FullControl access to an entity to grant ACL access to that entity.
Users with the tkg_viewer role, described in the example, cannot grant ACL access. Users with the tkg_author or tkg_admin role can share access to a CYFUTURE CLOUD:TKGCLUSTER entity with users who have the tkg_viewer, tkg_author, or tkg_admin role by granting them ACL access using the API request.
Users with the Administrator Full Control: Tanzu Kubernetes Guest Cluster right can grant ACL access to any CYFUTURE CLOUD:TKGCLUSTER entity.
You can also use REST API calls to revoke the access or to view who has access to the entity. See the Cyfuture Cloud Console REST API documentation on code.Cyfuture Cloud.com.
Changing the Owner of a Defined Entity
The owner of a defined entity or a user with the Administrator Full Control: TYPE right can transfer the ownership to another user by updating the defined entity model and changing the owner field with the ID of the new owner.
This chapter includes the following topics: Working with Custom Entity Definitions
Working with Custom Entity Definitions
The custom entity definitions in Cyfuture Cloud Console are object types that are bound to vRealize Orchestrator object types. Users within a Cyfuture Cloud Console organization can own, manage, and change these types according to their needs. By executing services, organization users can instantiate the custom entities and apply actions over the instances of the objects.
Search for a Custom Entity
You can search for those of the custom entities that were published to your organization.
Prerequisites
This operation requires the Custom Entity rights to be included in the predefined user role.
Procedure
1. In the top navigation bar, click Libraries and under Services, select Custom Entity Definitions.
The list of custom entities appears in a card view of 12 items per page, sorted by names alphabetically. Each card shows the name of the custom entity, the vRealize Orchestrator type to which the entity is mapped, the type of the entity, and a description, if available.
2. In the Search text box on the top of the page, enter a word or a character of the name of the entity you want to find.
The search results display in a card view of twelve items per page, sorted by names in alphabetical order.
Edit a Custom Entity Definition
You can modify the name and the description of a custom entity. You cannot change the type of the entity or the vRealize Orchestrator object type, to which the entity is bound, these are the default properties of the custom entity. If you want to modify any of the default properties, you must delete the custom entity definition and recreate it.
Prerequisites
This operation requires the Custom Entity rights to be included in the predefined user role.
Procedure
-
In the top navigation bar, click Libraries and under Services, select Custom Entity Definitions.
The list of custom entities appears in a card view of 12 items per page, sorted by names alphabetically. Each card shows the name of the custom entity, the vRealize Orchestrator type to which the entity is mapped, the type of the entity, and a description, if available.
2.In the card of the selected custom entity, select Actions > Edit. A new dialog opens.
3. Modify the name or the description of the custom entity definition.
4. Click OK to confirm the change.
Add a Custom Entity Definition
You can create a custom entity and map it to an existing vRealize Orchestrator object type.
Prerequisites
This operation requires the Custom Entity rights to be included in the predefined user role.
Procedure
-
In the top navigation bar, click Libraries and under Services, select Custom Entity Definitions.
The list of custom entities appears in a card view of 12 items per page, sorted by names alphabetically. Each card shows the name of the custom entity, the vRealize Orchestrator type to which the entity is mapped, the type of the entity, and a description, if available.
2. Click the 
3. Follow the steps of the Custom Entity Definition wizard.
|
Step |
|
|
Name and Description |
Enter a name and, optionally a description for the new entity. Enter a name for the entity type, for example sshHost. |
|
vRO |
From the drop-down menu, select the vRealize Orchestrator that you will use to map the custom entity definition. Note If you have more than one vRealize Orchestrator server, you must create a custom entity definition for each one of them separately. |
Type |
Click the view list icon ( If you know the name of the type, you can enter it directly in the text box. For example SSH:Host. |
|
Review |
Review the details that you specified and click Done to complete the creation. |
) to browse through the available vRealize Orchestrator object types grouped by plug-ins. For example, SSH > Host.Results
The new custom entity definition appears in the card view.
Custom Entity Instances
Running a vRealize Orchestrator workflow with an input parameter being an object type that is already defined as a custom entity definition in Cyfuture Cloud Console shows the output parameter as an instance of a custom entity.
Prerequisites
This operation requires the Custom Entity rights to be included in the predefined user role.
Procedure
-
In the top navigation bar, click Libraries and under Services, select Custom Entity Definitions.
The list of custom entities appears in a card view of 12 items per page, sorted by names alphabetically. Each card shows the name of the custom entity, the vRealize Orchestrator type to which the entity is mapped, the type of the entity, and a description, if available.
2. In the card of the selected custom entity, click Instances. The available instances display in a grid view.
3. Click the list bar ( ) on the left of each entity to display the associated workflows.
Clicking on a workflow initiates a workflow run which takes the entity instance as an input parameter.
Associate an Action to a Custom Entity
By associating an action to a custom entity definition, you can execute a set of vRealize Orchestrator workflows on the instances of a particular custom entity.
Prerequisites
This operation requires the Custom Entity rights to be included in the predefined user role.
Procedure
1. In the top navigation bar, click Libraries and under Services, select Custom Entity Definitions.
The list of custom entities appears in a card view of 12 items per page, sorted by names alphabetically. Each card shows the name of the custom entity, the vRealize Orchestrator type to which the entity is mapped, the type of the entity, and a description, if available.
2. In the card of the selected custom entity, select Actions > Associate Action. A new dialog opens.
3. Follow the steps of the Associate Custom Entity to VRO Workflow wizard.
|
Step |
Details |
|
Select VRO Workflow |
Select one of the listed workflows. These are the workflows that are available in the Service Library page. |
|
Select Workflow Input Parameter |
Select an available input parameter from the list. You associate the type of the vRealize Orchestrator workflow with the type of the custom entity definition. |
|
Review Association |
Review the details that you specified and click Done to complete the association. |
Example
For example, if you have a custom entity of type SSH:Host, you can associate it with the Add a Root Folder to SSH Host workflow by selecting the sshHost input parameter, which matches the type of the custom entity.
Dissociate an Action from a Custom Entity Definition
You can remove a vRealize Orchestrator workflow from the list of associated actions.
Prerequisites
This operation requires the Custom Entity rights to be included in the predefined user role.
Procedure
1. In the top navigation bar, click Libraries and under Services, select Custom Entity Definitions.
The list of custom entities appears in a card view of 12 items per page, sorted by names alphabetically. Each card shows the name of the custom entity, the vRealize Orchestrator type to which the entity is mapped, the type of the entity, and a description, if available.
2. In the card of the selected custom entity, select Actions > Dissociate Action. A new dialog opens.
Select the workflow you want to remove and click Dissociate Action.
3. The vRealize Orchestrator workflow is no longer associated with the custom entity.
Publish a Custom Entity
You must publish a custom entity so users from other tenants or service providers can run workflows using the custom entity instances as input parameters.
Prerequisites
This operation requires the Custom Entity rights to be included in the predefined user role.
Procedure
1. In the top navigation bar, click Libraries and under Services, select Custom Entity Definitions.
The list of custom entities appears in a card view of 12 items per page, sorted by names alphabetically. Each card shows the name of the custom entity, the vRealize Orchestrator type to which the entity is mapped, the type of the entity, and a description, if available.
2. In the card of the selected custom entity, select Actions > Publish. A new dialog opens.
3. Choose whether you want to publish the custom entity definition to service providers, all tenants, or only to selected tenants.
4. Click Save to confirm the change.
The custom entity definition becomes available to the selected parties.
Delete a Custom Entity
You can delete a custom entity definition if the custom entity is no longer in use, if it was configured incorrectly, or if you want to map the vRealize Orchestrator type to a different custom entity.
Prerequisites
This operation requires the Custom Entity rights to be included in the predefined user role.
Procedure
1. In the top navigation bar, click Libraries and under Services, select Custom Entity Definitions.
The list of custom entities appears in a card view of 12 items per page, sorted by names alphabetically. Each card shows the name of the custom entity, the vRealize Orchestrator type to which the entity is mapped, the type of the entity, and a description, if available.
2. In the card of the selected custom entity, select Actions > Delete.
3. Confirm the deletion.
The custom entity is removed from the card view.