[Workspace][Feature] Add ACL related functions

[gaobinlong]

Description

The main change of this PR are:

• Add permissions field to the default mapping of the OSD index(.kibana) to support ACL for workspace
• Update the test snapshot after we change the default mapping of the OSD index
• Add ACL class and basic functions

Issues Resolved

#5083

Testing the changes

Check List

• All tests pass
  • yarn test:jest
  • yarn test:jest_integration
  • yarn test:ftr
• New functionality includes testing.
• New functionality has been documented.
• Update CHANGELOG.md
• Commits are signed per the DCO using --signoff

[codecov]

Codecov Report

Attention: Patch coverage is 89.89899% with 10 lines in your changes are missing coverage. Please review.

Project coverage is 67.13%. Comparing base (5ef10da) to head (b80101a).
Report is 1 commits behind head on main.

Files	Patch %	Lines
...ore/server/saved_objects/permission_control/acl.ts	87.50%	3 Missing and 7 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5084      +/-   ##
==========================================
+ Coverage   67.10%   67.13%   +0.03%     
==========================================
  Files        3315     3316       +1     
  Lines       63922    64015      +93     
  Branches    10220    10256      +36     
==========================================
+ Hits        42892    42975      +83     
- Misses      18544    18547       +3     
- Partials     2486     2493       +7     

Flag	Coverage Δ
Linux_1	31.63% <0.00%> (-0.01%)	⬇️
Linux_2	55.20% <89.89%> (+0.13%)	⬆️
Linux_3	44.57% <0.00%> (-0.02%)	⬇️
Linux_4	35.16% <0.00%> (-0.02%)	⬇️
Windows_1	31.65% <0.00%> (-0.01%)	⬇️
Windows_2	55.17% <89.89%> (+0.13%)	⬆️
Windows_3	44.59% <0.00%> (-0.02%)	⬇️
Windows_4	35.16% <0.00%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kavilla]

Thanks for opening!

IMO, it might be worth to have this one hooked into the saved object functionality for us to see how it is being used and to give suggestions.

I see it on the mappings but I'm not sure how it interacts for existing data barring the mapping addition.

Also, just a heads up but I'm sure you already know. I'm really easily able to pass a compressed file of a 100+ MB files to the saved objects API. But the default size of the saved objects payload is quite large. Some users saved objects are sometimes too large that it is really not as performant. So based off the design proposal seeing how these permission controls are being used might make a big difference for our suggestions and increased latency to a potential slower response.

Would also suggest adding a configuration here that gives cluster admins the ability to disable permission controls? But I'm not sure how that impacts your design proposal but would make me sleep easier at night when we are filtering responses.

Final thing, which I tried seeing in the design, I'm pretty sure the saved objects retrieval is slightly cached and it might refresh at specific times. So I can see it having an impact on design if we want to worry about where to store this information but seems like a difficult issue to solve. For example, what do we plan to do as a user who originally had access, could still get the saved objects. Will they have the ability to have write permissions still in the cache state. They also still have access to the data and resending the request without refreshing the page.

I will paste a links to this on the design doc.

Thanks again!

[ruanyl]

Excellent job! Appreciate your dedication to refining the code according to the comments and discussions. It looks good to me now. 👍