IAM Group Naming

Note

  • Last modified by: Rob Barnsley

  • Last modified date: 18/11/2024

  • This is a work in progress and has not been subject to any formal approval.

The current naming convention for IAM groups follows the premise that permissions will need to need to be allocated for two independent resources: data and services.

Data

For data, the convention couples closely with the concept of scopes (namespaces) in Rucio. To access data in a particular <namespace>, one must be a member of a subgroup of the corresponding data group data/namespaces/<namespace>. Which subgroup to be allocated is dependent on the access level permitted; currently only one access level exists: owner, i.e. data/namespaces/<namespace>/owner. In the future, new access levels will undoubtedly be required to further restrict by method of access.

Other subgroups of the data group may also exist in the future to accommodate the other native Rucio data types for encapsulation, datasets and containers, so data/datasets/... and data/containers/... respectively, but this is dependent on the chosen data model which is TBD.

Services

For services, there is a further subcategorisation to distinguish between global and local services.

Global

Groups for global services exist under services/<service>. The level of access to each of the services is determined by membership of the roles subgroup of each service. The values for <service> are listed under the global array attribute at the Site Capabilities list service types endpoint, here.

For -api services, the possible subgroups of roles can be viewed at the policy package endpoint for each service: https://permissions.srcdev.skao.int/api/v1/policies/route/<service>/latest, where <service> is one of the types above, e.g. for the Data Management API there are two roles subgroups: admin and developer, i.e. services/data-management-api/roles/admin and services/data-management-api/roles/developer respectively.

For other services, the roles subgroups are application dependent, correlating with how the application partitions access.

Local

Groups for local services exist under services/<src>/<service> where <src> is one of the formally recognised names in the SRC naming scheme. The level of access to each of the services is determined by membership of the roles subgroup of each service. The values for <service> are listed under the local array attribute at the Site Capabilities list service types endpoint, here.

The roles subgroups are application dependent, correlating with how the application partitions access.