Cloud Services

ModernOps configuration

CAS authorization model
Published On May 16, 2024 - 1:59 PM

CAS authorization model

Details the Common Actions Services (CAS) authorization model that allows service providers and direct enterprise customers to manage and operate the hybrid IT landscape.
As Common Action Services (CAS) has adopted the new authorization model, which might have resulted in non-availability of
action features in AIOPS
 for certain users, specific steps to assign the required CAS roles need to be taken to enable actions for these users.

CAS roles

  • Action Practitioner role
    : The user with this role will have the responsibility to view resources across different providers, execute action at instance and component levels, track and view action history and status, retry, abort or cancel an action.
  • Action Registry Admin role
    : The user with this role is involved in onboarding the provider account and Discovery/Import of action and will be responsible for registering the content repositories (Github or Ansible Tower) from which action will be sourced, importing/discovering Action definition files from the local system, Github or Ansible Tower, viewing, adding, publishing/un-publishing Action content.
  • Action Policy Admin role
    : The user with this role will have governance and will ensure that all the action that gets executed are compliant to the action policies and is responsible for adding new policies, getting policies approval if needed, save policies as drafts, view the list of policies and their details, track policies life cycles, disable/enable and delete policies.
  • Action Viewer role
    : The user in this role will track or supervise end to end action lifecycle (action statuses) and the history of the action at a team on an organizational level. The user will be responsible for viewing resources across different applications, tracking ongoing action and viewing action history of each resource. This role is
    NOT
     involved in executing or canceling an action.
  • Action Support role
    : The user with this role will help Kyndryl Operations or Client operations to oversee all the action that are getting performed through a full UI visibility. This role will be responsible for accessing the Action fulfilment UI, tracking all ongoing action, viewing the diagnosis info of all the action that are stuck or delayed etc, take corrective action based on diagnostic info and have the ability to restart or retry an action that are stuck or delayed, undo incomplete action before retrying and manually aborting or canceling an action.

Assigning CAS roles

Assigning the
Registry Admin
 and
Action Viewer
 roles is required to perform actions, as part of Kyndryl's new Identity Access Management model.
To assign these roles, follow these steps:
  4. This Access Policy must include the
    Registry Admin
     and
    Action Viewer
     roles. These roles can be found by selecting
    Actions
     from the
    Service
     dropdown.

CAS entitlements

As each application is able to setup who can execute which actions from which console, the CAS entitlements have been tracked against an entitlement policy. These policies can be setup at a Team, Organization and Tenant level, independently. Additionally, these policies are currently focused on what is
"allowed"
 and not what is
"denied"
.
A
"Managed To Who"
 construct, which represent on whom this policy is applicable, may contain the following attributes:
  1. Identification of Organization, or Team, or both. It defaults to the entire tenant if no Organization or Team has been specified.
  2. Identification of Role (Platform or Application) within the Organization or Team. If Platform roles are enabled, it defaults to
    "SSOB Platform Admin"
    role at the chosen Organization or Team scope. If no Platform roles have been specified, there is no default.
  3. Logical Operators
    AND/OR/NOT
     can be used.

Implementation

To implement this new authorization model, there has been a full execution of trust between CAS and the applications, as described next:
  1. The
    Administrator
     sets up an application authorization policy.
  2. The
    End user
     requests a retry execution with a set of parameters (some parameters can be used for authorization).
  3. The
    Application
     receives the request, authorizes the request, and calls the
    CAS Retry Execution API
     internally with the application's Foundation service token as trust.
  4. CAS verifies the service token and executes the request.
  5. The
    User
     token is not supported.
  6. The
    Retry with CAS UI/API
     is not supported with this authorization.
  7. The
    Retry with Application UI/API
     can be supported with this authorization by the application.

CAS role matrix

See the following role matrix to understand the types of permission a user has to execute actions on resources from the Kyndryl Modern Operations applications inventory:
Service
Resource / Action
Platform Operator
Platform Viewer
Action Registry Admin
ITOps Tenant Viewer
ITOps Manager
Common Inventory
View
Yes
Yes
No
Yes
Yes
Common Inventory
Actions
 (execute, retry, cancel)
Yes
No
No
No
Yes
Common Inventory
Actions
 (view)
Yes
No
No
Yes
Yes
Common Inventory
Tag, untag resources
No
No
No
No
Yes
Common Inventory
Update tag provider console
No
No
No
No
Yes
Common Inventory
Export, download list view
No
No
No
Yes
Yes
Common Discovery
View management
Yes
No
No
No
Yes
Common Actions
Onboarding
 (import, publish, retire)
No
No
Yes
No
Yes
Common Actions
Onboarding
 (view history)
No
No
No
Yes
Yes
Common Actions
Action History
 (view)
Yes
Yes
No
Yes
Yes
Common Actions
Action History
 (retry, cancel)
Yes
No
No
No
Yes
Do you have two minutes for a quick survey?
Take Survey