github-mirrors/kibana
1
0
Fork 0
mirror of https://github.com/elastic/kibana.git synced 2025-04-24 17:59:23 -04:00
Code Issues Projects Releases Packages Wiki Activity
kibana/oas_docs
History
Elena Shostak 2ff384b02a
[9.0] [Authz] Added allOf and anyOf nested conditions (#215516) (#217051) 
# Backport

This will backport the following commits from `main` to `9.0`:
- [[Authz] Added allOf and anyOf nested conditions
(#215516)](https://github.com/elastic/kibana/pull/215516)

<!--- Backport version: 9.6.6 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sorenlouv/backport)

<!--BACKPORT [{"author":{"name":"Elena
Shostak","email":"165678770+elena-shostak@users.noreply.github.com"},"sourceCommit":{"committedDate":"2025-04-03T12:28:17Z","message":"[Authz]
Added allOf and anyOf nested conditions (#215516)\n\n##
Summary\n\nCurrently, our `requiredPrivileges` structure supports
`allRequired` and\n`anyRequired` for defining authorization logic.
However, there is [a\nneed
to\nsupport](https://github.com/elastic/kibana/pull/205335#issuecomment-2569275302)\nmore
complex scenarios as `(privilege1 AND privilege2) OR (privilege3\nAND
privilege4)`\n\nTo achieve `anyRequired` has been extended to allow
defining multiple\nAND conditions evaluated with OR
logic:\n```ts\nsecurity: {\n authz: {\n requiredPrivileges: [{\n
anyRequired: [\n { allOf: ['privilege1', 'privilege2'] }, \n { allOf:
['privilege3', 'privilege4'] }\n ] \n }\n ]\n }\n}\n```\n\n`allRequired`
now also supports scenarios `(privilege1 OR privilege2)\nAND (privilege3
OR privilege4)`\n```ts\nsecurity: {\n authz: {\n requiredPrivileges:
[{\n allRequired: [\n { anyOf: ['privilege1', 'privilege2'] }, \n {
anyOf: ['privilege3', 'privilege4'] }\n ] \n }\n ]\n }\n}\n```\n\n>
[!IMPORTANT]\n> We expect to have unique privileges in `anyOf` or
`allOf` conditions,\nassuming that most complex conditions can be
simplified by boolean\nalgebra laws (OR/AND distributive etc).\n\n\n###
Checklist\n\n-
[x]\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\nwas
added for features that require explanation or tutorials\n- [x] [Unit or
functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere
updated or added to match the most common scenarios\n- [x] The PR
description includes the appropriate Release Notes section,\nand the
correct `release_note:*` label is applied per
the\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\n\n__Closes:
https://github.com/elastic/kibana/issues/210977__\n\n---------\n\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"ed058086e27c2b6f5015647b446304608d6b14a9","branchLabelMapping":{"^v9.1.0$":"main","^v8.19.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Security","enhancement","release_note:skip","Feature:Security/Authorization","backport:prev-minor","backport:version","v9.1.0","v8.19.0"],"title":"[Authz]
Added allOf and anyOf nested
conditions","number":215516,"url":"https://github.com/elastic/kibana/pull/215516","mergeCommit":{"message":"[Authz]
Added allOf and anyOf nested conditions (#215516)\n\n##
Summary\n\nCurrently, our `requiredPrivileges` structure supports
`allRequired` and\n`anyRequired` for defining authorization logic.
However, there is [a\nneed
to\nsupport](https://github.com/elastic/kibana/pull/205335#issuecomment-2569275302)\nmore
complex scenarios as `(privilege1 AND privilege2) OR (privilege3\nAND
privilege4)`\n\nTo achieve `anyRequired` has been extended to allow
defining multiple\nAND conditions evaluated with OR
logic:\n```ts\nsecurity: {\n authz: {\n requiredPrivileges: [{\n
anyRequired: [\n { allOf: ['privilege1', 'privilege2'] }, \n { allOf:
['privilege3', 'privilege4'] }\n ] \n }\n ]\n }\n}\n```\n\n`allRequired`
now also supports scenarios `(privilege1 OR privilege2)\nAND (privilege3
OR privilege4)`\n```ts\nsecurity: {\n authz: {\n requiredPrivileges:
[{\n allRequired: [\n { anyOf: ['privilege1', 'privilege2'] }, \n {
anyOf: ['privilege3', 'privilege4'] }\n ] \n }\n ]\n }\n}\n```\n\n>
[!IMPORTANT]\n> We expect to have unique privileges in `anyOf` or
`allOf` conditions,\nassuming that most complex conditions can be
simplified by boolean\nalgebra laws (OR/AND distributive etc).\n\n\n###
Checklist\n\n-
[x]\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\nwas
added for features that require explanation or tutorials\n- [x] [Unit or
functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere
updated or added to match the most common scenarios\n- [x] The PR
description includes the appropriate Release Notes section,\nand the
correct `release_note:*` label is applied per
the\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\n\n__Closes:
https://github.com/elastic/kibana/issues/210977__\n\n---------\n\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"ed058086e27c2b6f5015647b446304608d6b14a9"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/215516","number":215516,"mergeCommit":{"message":"[Authz]
Added allOf and anyOf nested conditions (#215516)\n\n##
Summary\n\nCurrently, our `requiredPrivileges` structure supports
`allRequired` and\n`anyRequired` for defining authorization logic.
However, there is [a\nneed
to\nsupport](https://github.com/elastic/kibana/pull/205335#issuecomment-2569275302)\nmore
complex scenarios as `(privilege1 AND privilege2) OR (privilege3\nAND
privilege4)`\n\nTo achieve `anyRequired` has been extended to allow
defining multiple\nAND conditions evaluated with OR
logic:\n```ts\nsecurity: {\n authz: {\n requiredPrivileges: [{\n
anyRequired: [\n { allOf: ['privilege1', 'privilege2'] }, \n { allOf:
['privilege3', 'privilege4'] }\n ] \n }\n ]\n }\n}\n```\n\n`allRequired`
now also supports scenarios `(privilege1 OR privilege2)\nAND (privilege3
OR privilege4)`\n```ts\nsecurity: {\n authz: {\n requiredPrivileges:
[{\n allRequired: [\n { anyOf: ['privilege1', 'privilege2'] }, \n {
anyOf: ['privilege3', 'privilege4'] }\n ] \n }\n ]\n }\n}\n```\n\n>
[!IMPORTANT]\n> We expect to have unique privileges in `anyOf` or
`allOf` conditions,\nassuming that most complex conditions can be
simplified by boolean\nalgebra laws (OR/AND distributive etc).\n\n\n###
Checklist\n\n-
[x]\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\nwas
added for features that require explanation or tutorials\n- [x] [Unit or
functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere
updated or added to match the most common scenarios\n- [x] The PR
description includes the appropriate Release Notes section,\nand the
correct `release_note:*` label is applied per
the\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\n\n__Closes:
https://github.com/elastic/kibana/issues/210977__\n\n---------\n\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"ed058086e27c2b6f5015647b446304608d6b14a9"}},{"branch":"8.x","label":"v8.19.0","branchLabelMappingKey":"^v8.19.0$","isSourceBranch":false,"url":"https://github.com/elastic/kibana/pull/217050","number":217050,"state":"OPEN"}]}]
BACKPORT-->

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
2025-04-04 13:13:40 +02:00
..
examples [DOCS] Remove inference connector docs (#198633) 2024-11-12 11:56:37 -06:00
linters [9.0] [DOCS] Removes Serverless API x-beta overlay (#215587) (#215598) 2025-03-25 16:36:19 -04:00
output [9.0] [Authz] Added allOf and anyOf nested conditions (#215516) (#217051) 2025-04-04 13:13:40 +02:00
overlays [9.0] [DOCS] Removes Serverless API x-beta overlay (#215587) (#215598) 2025-03-25 16:36:19 -04:00
scripts [9.0] [DOCS] Add minimal task manager health APIs (#213862) (#215986) 2025-03-26 09:48:35 +01:00
bundle.json [9.0] [Authz] Added allOf and anyOf nested conditions (#215516) (#217051) 2025-04-04 13:13:40 +02:00
bundle.serverless.json [9.0] [Fleet] fix latest_executed_state error (#212935) (#212969) 2025-03-04 10:34:37 +00:00
kibana.info.yaml Update branch in OpenAPI intro (#215970) 2025-03-26 09:47:58 +01:00
makefile [9.0] [DOCS] Add minimal task manager health APIs (#213862) (#215986) 2025-03-26 09:48:35 +01:00
package-lock.json [9.0] Update dependency @redocly/cli to ^1.34.0 (main) (#216050) (#216444) 2025-03-31 13:35:28 +01:00
package.json [9.0] Update dependency @redocly/cli to ^1.34.0 (main) (#216050) (#216444) 2025-03-31 13:35:28 +01:00
README.md [9.0] SKA: Relocate "platform" packages that remain on /packages (#208704) (#212224) 2025-02-28 10:10:29 +01:00

README.md

Kibana API reference documentation

Documentation about our OpenAPI bundling workflow and configuration. See Kibana's hosted stateful and serverless docs.

Workflow

The final goal of this workflow is to produce an OpenAPI bundle containing all Kibana's public APIs.

Step 0

OAS from Kibana's APIs are continuously extracted and captured in bundle.json and bundle.serverless.json as fully formed OAS documentation. See node scripts/capture_oas_snapshot --help for more info.

These bundles form the basis of our OpenAPI bundles to which we append and layer extra information before publishing.

Step 1

Append pre-existing bundles not extracted from code using kbn-openapi-bundler to produce the final resulting bundles.

To add more files into the final bundle, edit the appropriate oas_docs/scripts/merge*.js files.

Step 2

Apply any final overalys to the document that might include examples or final tweaks (see the "Scripts" section for more details).

Scripts

The oas_docs/scripts folder contains scripts that point to the source domain-specific OpenAPI bundles and specify additional parameters for producing the final output bundle. Currently, there are the following scripts:

  • merge_ess_oas.js script produces production an output bundle for ESS

  • merge_serverless_oas.js script produces production an output bundle for Serverless

Output Kibana OpenAPI bundles

The oas_docs/output folder contains the final resulting Kibana OpenAPI bundles

  • kibana.yaml production ready ESS OpenAPI bundle
  • kibana.serverless.yaml production ready Serverless OpenAPI bundle

Bundling commands

Besides the scripts in the oas_docs/scripts folder, there is an oas_docs/makefile to simplify the workflow. Use make help to see available commands.