From 5f858f3e3a8592cbf27542b64eb6b1d8a71ca95e Mon Sep 17 00:00:00 2001 From: Amanda Calatrava Date: Thu, 13 Feb 2025 18:55:45 +0100 Subject: [PATCH 1/2] Update multitenancy documentation --- docs/multitenancy.md | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/docs/multitenancy.md b/docs/multitenancy.md index 709d0aa5..a2f0228b 100644 --- a/docs/multitenancy.md +++ b/docs/multitenancy.md @@ -1,25 +1,26 @@ # Multitenancy support in OSCAR -In the context of OSCAR, multi-tenancy support refers to the platform's ability to enable multiple users or organizations (tenants) to deploy and run their applications or functions on the same underlying infrastructure. Support for multitenancy in OSCAR has been available since version v3.0.0. To use this functionality, there are some requisites that the cluster and the users have to fulfill: +In the context of OSCAR, multi-tenancy support refers to the platform's ability to enable multiple users or organizations (tenants) to deploy and run their applications or functions on the same underlying infrastructure. Support for multitenancy in OSCAR has been available since version v3.0.0. To use this functionality, there are some requisites that the cluster and the users have to fulfil: - **The cluster needs to have enabled OIDC access.** - This is because the implementation of this functionality uses directly the EGI UIDs to distinguish between users, therefore removing the need to manage a database. + This is because the implementation of this functionality relies on the EGI ePUIDs to distinguish between users, therefore removing the need to manage a database. -- **Users who want to create new services need to know the UID of the users who will have access to the service.** +- **Users who want to create new services need to know the ePUID of the users who will have access to the service.** - Each service has a list of "allowed users," so a service can be accessed not only by one but by multiple users chosen by the service creator. This way, users have the ability to decide who can operate over its services. It is important to note that only the service creator or "owner" can update it; this means that allowed users will only be able to see the service (and its buckets) and make invocations. + Each service has a list of "allowed users," so a service can be accessed not only by one but multiple users chosen by the service creator. This way, users can decide who can operate over its services. It is important to note that only the service creator or "owner" can update it; this means that only allowed users can see the service (and its buckets) and perform service invocations. At creation time, the ePUID of the user creating the service doesn't need to be present on the list; however, when a service is updated, if the user who has created the service needs to access it, its ePUID must be on the list. This "allowed users" list is defined on the FDL at service creation time (more info in [FDL docs](fdl.md)). - This allowed users list is defined on the FDL on the service creation (more info in [FDL docs](fdl.md)). The following is an example of an FDL that creates a service that gives access to two EGI users. If the allowed_users field is empty, the service is treated as "public," so every user within the cluster will have access to it. +> **_NOTE:_** A user can obtain its EGI User ePUID by login into https://aai.egi.eu/ (for the production instance of EGI Check-In) or https://aai-demo.egi.eu (for the demo instance of EGI Check-In). - At the moment of the creation, the UID of the user creating the service doesn't need to be present on the list; however, when a service is updated, if the user will still have access, its UID has to be on the list. + +The following is an example of an FDL that creates a service whose usage is limited to two different EGI users. Notice that, if the *allowed_users* field is **empty**, the service is treated as **public**, so every user within the cluster can use it and access the corresponding MinIO bucket and its content. ``` yaml functions: oscar: - oscar-cluster: - name: grayify_multitenant + name: grayify-multitenant memory: 1Gi cpu: '0.6' image: ghcr.io/grycap/imagemagick @@ -31,31 +32,30 @@ functions: - "5e14d33ac4abc96272cc163da6a200c2e18591bfb3b0f32a4c9c867f5e938463@egi.eu" input: - storage_provider: minio.default - path: grayify_multitenant/input + path: grayify-multitenant/input output: - storage_provider: minio.default - path: grayify_multitenant/output + path: grayify-multitenant/output ``` +> **_NOTE:_** To test the service in the FDL above, please use this script to execute the function: [ImageMagick example](https://github.com/grycap/oscar/blob/master/examples/imagemagick/script.sh). + ## ISOLATION LEVEL -The isolation level variable has been added to the service definition for better privacy definition of the service. There are 2 modes available. +The isolation level variable has been added to the FDL service definition to facilitate the configuration of the service's privacy. There are 2 configurations available, *SERVICE* and *USER*. Below we explain them in more detail. ### SERVICE -The service isolation level is the default value. If you isolate the service at the service level and use MinIO as the event source, the buckets you selected in the input/output sections will be created. These buckets will only be visible to the users defined in allowed_users. +The *SERVICE* isolation level is the default value. If you isolate the service at the service level and use MinIO as the storage provider (event source), the buckets indicated in the input/output sections of the service definition will be created. These buckets will only be visible to the users defined in the *allowed_users* list. ### USER -By isolating the service at the user level, in addition to creating the buckets specified in input/output, additional private buckets will be created. Each user defined in allowed_users will have access to one of the private buckets, which will also run the service if a file is uploaded to the /in folder located inside. - -The services triggered by those private buckets will redirect the output into the same bucket with the key 'out'. For example, if we use 'gray' as the input bucket, we are the user '5e14d33a'. Our private bucket is 'car-5e14d33a'. Inside that private bucket, we have folders for 'in' and 'out'. Upload a file into the 'in' folder to trigger the service. The output is uploaded into the 'out' folder. +By isolating the service at the *USER* level, in addition to creating the buckets specified in input/output, additional private buckets will be created. Each user defined in the *allowed_users* list will have access to its private bucket, which will also trigger the execution of the service if a file is uploaded to the /input folder located inside it. The executions triggered by those private buckets will redirect the output into the same private bucket, in the /output folder. +Let's see how it works with an example. Let's suppose that we are the user '5e14d33a', and we create a service called 'gray', with a default bucket also called 'gray' and a list of two users (ourselves and user '62bb11b'). Our automatically created **private bucket** will be 'gray-5e14d33a'. Inside that private bucket, we will find two folders: one for 'input' files and another for 'output' files. When we, as user '5e14d33a' upload a file into the 'input' folder, this provokes an event in MinIO that triggers the service. The output of this execution will be uploaded into the 'output' folder of our private bucket, meaning that the other users of the service (in the example, user '62bb11b') cannot access the inputs/outputs of our execution. THe same happens for user '62bb11b' and its private bucket. However, if we use the default 'gray' bucket, the files stored on it will be accessible by both users. ![multitenancy-diagram](images/multitenancy.png) -> **_NOTE:_** A user can obtain its EGI User Id by login into https://aai.egi.eu/ (for the production instance of EGI Check-In) or https://aai-demo.egi.eu (for the demo instance of EGI Check-In). - -Since OSCAR uses MinIO as the main storage provider, so that the users only have access to their designated bucket's service, MinIO users are created on the fly for each EGI UID. Consequently, each user accessing the cluster will have a MinIO user with its UID as AccessKey and an autogenerated SecretKey. +Since OSCAR uses MinIO as the main storage provider, so that users only have access to their designated bucket's service, MinIO users are created on-the-fly for each EGI ePUID. Consequently, each user accessing the cluster will have a MinIO user with its UID as AccessKey and an autogenerated SecretKey. From 79346589392a616a8691f2697350c15dd1fe241e Mon Sep 17 00:00:00 2001 From: Robert Kazaryan Date: Wed, 19 Feb 2025 14:18:08 +0100 Subject: [PATCH 2/2] Updated oscar-cli documentation to oscar-cli v1.10.1 --- docs/oscar-cli.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/docs/oscar-cli.md b/docs/oscar-cli.md index b30e1598..6ba1358b 100644 --- a/docs/oscar-cli.md +++ b/docs/oscar-cli.md @@ -114,6 +114,9 @@ Flags: oidc-agent. Note that oidc-agent must be started and properly configured (See:https://indigo-dc.gitbook.io/oidc-agent/) + -t, --oidc-refresh-token string OIDC token to authenticate using oidc-token. + Note that oidc-token must be started and + properly configured --password-stdin take the password from stdin Global Flags: @@ -263,17 +266,19 @@ Invoke a service synchronously (a Serverless backend in the cluster is required) ``` Usage: - oscar-cli service run SERVICE_NAME {--input | --text-input} [flags] + oscar-cli service run SERVICE_NAME {--file-input | --text-input} [flags] Aliases: run, invoke, r Flags: -c, --cluster string set the cluster + -e, --endpoint string endpoint of a non registered cluster + -f, --file-input string input file for the request -h, --help help for run - -i, --input string input file for the request -o, --output string file path to store the output - -t, --text-input string text input string for the request + -i, --text-input string text input string for the request + -t, --token string token of the service Global Flags: --config string set the location of the config file (YAML or JSON)