As a user, I want to have read-only access to all registry indexes

[jordanpadams]

Checked for duplicates

Yes - I've already checked

🧑‍🔬 User Persona(s)

Node Operator

💪 Motivation

...so that I can run tools against the read-only registry indexes. e.g. run validate-refs against all data in the database

📖 Additional Details

No response

Acceptance Criteria

Given one lidvid that exists in the geo-registry index and one lidvid that exists in the naif-registry index
When I perform a query for each of those lidvids against those registries
Then I expect to be able to retrieve results

⚙️ Engineering Details

Blocking #351

🎉 I&T

No response

[al-niessner]

@jordanpadams @tloubrieu-jpl

There are two ways to do this with harvest, mgr tools, and validate-refs (they all use registry-common):

1. make an index in AOSS that maps to all the other indices (may not be possible)
2. make index in the configuration either '.' or ';' or ':' or mix of any separate list instead of a single index. The Java SDK v2 supports assigning multiple indices instead of one. When multiple, make sure operation is read only.

[jordanpadams]

@al-niessner does the Java SDK support wildcards like *-registry? This is something we can do in Kibana to search across indexes.

[al-niessner]

No. It takes a list. We can convert wildcards to list since the full list is known as priori.

…

On Tue, Dec 10, 2024, 13:27 Jordan Padams ***@***.***> wrote: @al-niessner <https://github.com/al-niessner> does the Java SDK support wildcards like *-registry? This is something we can do in Kibana to search across indexes. — Reply to this email directly, view it on GitHub <#350 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIUBIUVN3S3CTYEKIM5RLL2E5MCXAVCNFSM6AAAAABSO7JATCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZSHEZDMMZTGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[sjoshi-jpl]

@jordanpadams @viviant100 @tloubrieu-jpl we will need someone from one of the nodes to confirm there Read access to all indexes. The reason we cannot test with users in EN group is because these users are already have read access to all indexes. Who can I reach out to for testing?

[tloubrieu-jpl]

Hi @sjoshi-jpl , I can volunteer tomorrow to be removed from EN node and be associated to a discipline node.

[sjoshi-jpl]

@tloubrieu-jpl I created a test user, we can test with it tomorrow.

[jordanpadams]

@sjoshi-jpl per this discussion thread on validate, instead of having a read-only role for all indices, could we just create a read-only alias index that maps to all the indices?

[jordanpadams]

e.g.

POST _aliases
{
  "actions": [
    {
      "add": {
        "index": "en-registry",
        "alias": "readall-registry"
      }
    },
    {
      "add": {
        "index": "atm-registry",
        "alias": "readall-registry"
      }
    }
    ...
  ]
}

[tloubrieu-jpl]

Sorry I missed the comment before, but as a first test result, with test user testuser1 belonging to group GEO, created by @sjoshi-jpl:

• we can read all the indexes
• we can write in the geo index:

pds-registry-client '/geo-registry/_create/testttt' --data @/Users/loubrieu/tmp/test_doc.json --pretty
Response returned HTTP201 Created: b'{"_index":"geo-registry","_id":"testttt","_version":1,"result":"created","_shards":{"total":0,"successful":0,"failed":0},"_seq_no":0,"_primary_term":0}'

• we cannot write in the en index

% pds-registry-client '/en-registry/_create/testttt' --data @/Users/loubrieu/tmp/test_doc.json --pretty
Response returned HTTP403 Forbidden: b'{"error":{"root_cause":[{"type":"security_exception","reason":"Authorization failure for the following indices: [index/pds-mcp-registry-prod/en-registry]"}],"type":"security_exception","reason":"Authorization failure for the following indices: [index/pds-mcp-registry-prod/en-registry]"},"status":403}'

[tloubrieu-jpl]

@sjoshi-jpl the initial scope of the ticket is validated. Can you look at the new request of Jordan, regarding having a virtual index aggregating the others ?

We would also need to document how the authorization is managed, in the wiki or in terraform.

[jordanpadams]

@sjoshi-jpl @tloubrieu-jpl I am OK with not pursuing this alias index. It seems like a more concise approach for handling the authorization, but if it is not, then we can continue with the route @tloubrieu-jpl just tested.