Skip to content

WMCore CRIC‐based permissions

Jump to bottom
Alan Malta Rodrigues edited this page Oct 27, 2023 · 2 revisions

The WM central services are only accessible for users that are member of the cms virtual organization. In addition to that, some WM services also provide further fine-grain permissions which are based on CRIC roles. This wiki summarizes what services are those, what is the CRIC group and role, and what power is granted with such permissions.

Granting CRIC permissions

As discussed in the JIRA ticket CMSPROD-30, some CRIC group/roles can now be granted through egroup lists, in order to facilitate the process for CompOps and PdmV. A summary of the CRIC roles and the egroup mapped to them is as follows:

  • dataops : production-operator: egroup called "cms-cric-dataops-production-operator" (named "CMS_DataOps_ProductionOperator_autosynced" in CRIC)
  • reqmgr : data-manager: egroup called "cms-cric-reqmgr-data-manager" (named "CMS_ReqMgr_DataManager_autosynced" in CRIC)

These 2 new CRIC groups are automatically sync'ed from their equivalent egroups and the group/roles above are granted. Note that self-subscription is disabled for both egroups and an admin needs to manually approve any subscriptions. Admins of this egroup are stored in another egroup, called "cms-comp-ops-workflow-team-admin".

Request Manager

Request Manager allows for different actions based on the group/roles that a given person/DN has. The goal with these different roles is to limit which workflow status transitions are allowed for each client.

The following group/roles are supported in ReqMgr2:

# Admin level: facops/web-service, reqmgr/admin, reqmgr/developer
# Ops/P&R level: dataops/production-operator
# Offline/PPD level: reqmgr/data-manager

where:

  • Admin can perform any status transition in ReqMgr2.
  • Ops can perform the workflow assignment and announcement. The actual complete list of target statuses is: ["assigned", "staging", "staged", "force-complete", "closed-out", "announced"].
  • PPD can create, abort and reject workflows. The actual complete list of target statuses is: ["new", "assignment-approved", "rejected", "aborted", "NO_STATUS"]. Note that NO_STATUS corresponds to solely a workflow priority change.

Lastly, note that only the production service instance applies these rules, while in pre-production the PPD level privileges are the same as the Ops one.

MSPileup

The microservice managing pileup datasets - called MSPileup - also requires CRIC roles for specific actions. The goal with these different roles is to limit access according to the CRUD (create, read, update, delete) operations, which are enforced according to the HTTP method used by the client. In general, anyone member of the cms VO is allowed to read documents.

The following group/roles are supported in MSPileup:

# Admin level: reqmgr/admin
# Ops/P&R level: dataops/production-operator

where:

  • Admin can create, update and delete pileup documents.
  • Ops can create and update pileup documents.

Note that pileup document deletion is restrict only to admins. The reason for that is that pileup documents should never be deleted before spending some time disabled in the system, such that the relevant Rucio rules can be properly removed. Pileup document deletion is an automated action taken by MSPileup itself.

Lastly, permissions are slightly relaxed in the pre-production environment, which allows Ops to delete pileup documents as well.

Clone this wiki locally