-
Notifications
You must be signed in to change notification settings - Fork 8.5k
[Fleet] Use Kibana Authz for API authorization #205335
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…t --include-path /api/status --include-path /api/alerting/rule/ --include-path /api/alerting/rules --include-path /api/actions --include-path /api/security/role --include-path /api/spaces --include-path /api/fleet --include-path /api/dashboards --update'
…o feature-kibana-authz
…t --include-path /api/status --include-path /api/alerting/rule/ --include-path /api/alerting/rules --include-path /api/actions --include-path /api/security/role --include-path /api/spaces --include-path /api/fleet --include-path /api/dashboards --update'
…o feature-kibana-authz
…t --include-path /api/status --include-path /api/alerting/rule/ --include-path /api/alerting/rules --include-path /api/actions --include-path /api/security/role --include-path /api/spaces --include-path /api/fleet --include-path /api/dashboards --update'
…t --include-path /api/status --include-path /api/alerting/rule/ --include-path /api/alerting/rules --include-path /api/actions --include-path /api/security/role --include-path /api/spaces --include-path /api/fleet --include-path /api/dashboards --update'
…o feature-kibana-authz
|
Pinging @elastic/fleet (Team:Fleet) |
@elena-shostak what do you think about this request? |
…t --include-path /api/status --include-path /api/alerting/rule/ --include-path /api/alerting/rules --include-path /api/actions --include-path /api/security/role --include-path /api/spaces --include-path /api/fleet --include-path /api/dashboards --update'
|
@elasticmachine merge upstream |
juliaElastic
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
…o feature-kibana-authz
…t --include-path /api/status --include-path /api/alerting/rule/ --include-path /api/alerting/rules --include-path /api/actions --include-path /api/security/role --include-path /api/spaces --include-path /api/fleet --include-path /api/dashboards --update'
…o feature-kibana-authz
…t --include-path /api/status --include-path /api/alerting/rule/ --include-path /api/alerting/rules --include-path /api/actions --include-path /api/security/role --include-path /api/spaces --include-path /api/fleet --include-path /api/dashboards --update'
|
@elasticmachine merge upstream |
💔 Build Failed
Failed CI StepsMetrics [docs]
History
cc @nchaulet |
|
@elasticmachine merge upstream |
## Summary Currently, our `requiredPrivileges` structure supports `allRequired` and `anyRequired` for defining authorization logic. However, there is [a need to support](#205335 (comment)) more complex scenarios as `(privilege1 AND privilege2) OR (privilege3 AND privilege4)` To achieve `anyRequired` has been extended to allow defining multiple AND conditions evaluated with OR logic: ```ts security: { authz: { requiredPrivileges: [{ anyRequired: [ { allOf: ['privilege1', 'privilege2'] }, { allOf: ['privilege3', 'privilege4'] } ] } ] } } ``` `allRequired` now also supports scenarios `(privilege1 OR privilege2) AND (privilege3 OR privilege4)` ```ts security: { authz: { requiredPrivileges: [{ allRequired: [ { anyOf: ['privilege1', 'privilege2'] }, { anyOf: ['privilege3', 'privilege4'] } ] } ] } } ``` > [!IMPORTANT] > We expect to have unique privileges in `anyOf` or `allOf` conditions, assuming that most complex conditions can be simplified by boolean algebra laws (OR/AND distributive etc). ### Checklist - [x] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [x] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) __Closes: https://github.com/elastic/kibana/issues/210977__ --------- Co-authored-by: kibanamachine <[email protected]> Co-authored-by: Elastic Machine <[email protected]>
## Summary Currently, our `requiredPrivileges` structure supports `allRequired` and `anyRequired` for defining authorization logic. However, there is [a need to support](elastic#205335 (comment)) more complex scenarios as `(privilege1 AND privilege2) OR (privilege3 AND privilege4)` To achieve `anyRequired` has been extended to allow defining multiple AND conditions evaluated with OR logic: ```ts security: { authz: { requiredPrivileges: [{ anyRequired: [ { allOf: ['privilege1', 'privilege2'] }, { allOf: ['privilege3', 'privilege4'] } ] } ] } } ``` `allRequired` now also supports scenarios `(privilege1 OR privilege2) AND (privilege3 OR privilege4)` ```ts security: { authz: { requiredPrivileges: [{ allRequired: [ { anyOf: ['privilege1', 'privilege2'] }, { anyOf: ['privilege3', 'privilege4'] } ] } ] } } ``` > [!IMPORTANT] > We expect to have unique privileges in `anyOf` or `allOf` conditions, assuming that most complex conditions can be simplified by boolean algebra laws (OR/AND distributive etc). ### Checklist - [x] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [x] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) __Closes: https://github.com/elastic/kibana/issues/210977__ --------- Co-authored-by: kibanamachine <[email protected]> Co-authored-by: Elastic Machine <[email protected]> (cherry picked from commit ed05808) # Conflicts: # oas_docs/bundle.json # oas_docs/bundle.serverless.json # oas_docs/output/kibana.serverless.yaml # oas_docs/output/kibana.yaml # src/core/packages/http/router-server-internal/tsconfig.json # src/platform/packages/shared/kbn-router-to-openapispec/src/__snapshots__/generate_oas.test.ts.snap # src/platform/packages/shared/kbn-router-to-openapispec/src/generate_oas.test.fixture.ts
## Summary Currently, our `requiredPrivileges` structure supports `allRequired` and `anyRequired` for defining authorization logic. However, there is [a need to support](elastic#205335 (comment)) more complex scenarios as `(privilege1 AND privilege2) OR (privilege3 AND privilege4)` To achieve `anyRequired` has been extended to allow defining multiple AND conditions evaluated with OR logic: ```ts security: { authz: { requiredPrivileges: [{ anyRequired: [ { allOf: ['privilege1', 'privilege2'] }, { allOf: ['privilege3', 'privilege4'] } ] } ] } } ``` `allRequired` now also supports scenarios `(privilege1 OR privilege2) AND (privilege3 OR privilege4)` ```ts security: { authz: { requiredPrivileges: [{ allRequired: [ { anyOf: ['privilege1', 'privilege2'] }, { anyOf: ['privilege3', 'privilege4'] } ] } ] } } ``` > [!IMPORTANT] > We expect to have unique privileges in `anyOf` or `allOf` conditions, assuming that most complex conditions can be simplified by boolean algebra laws (OR/AND distributive etc). ### Checklist - [x] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [x] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) __Closes: https://github.com/elastic/kibana/issues/210977__ --------- Co-authored-by: kibanamachine <[email protected]> Co-authored-by: Elastic Machine <[email protected]> (cherry picked from commit ed05808) # Conflicts: # oas_docs/bundle.json # oas_docs/bundle.serverless.json # oas_docs/output/kibana.serverless.yaml # oas_docs/output/kibana.yaml # src/platform/packages/shared/kbn-router-to-openapispec/src/__snapshots__/generate_oas.test.ts.snap # src/platform/packages/shared/kbn-router-to-openapispec/src/generate_oas.test.fixture.ts
Summary
Resolve #203170
Use Kibana authz instead of having custom logic for Fleet when it's possible. This add the required privileges to the generated open API doc.
Privileges are tested with API integration tests, so I do not think we will introduce a regression or a breaking change with that PR.
It was not possible to migrate all routes as some scenario are not yet supported like a route need
(privilege1 AND privilege2) OR (privilege3 AND privilege 4)@legrego do you think it will be possible to support this kind of rules? do you want me to create an issue for that.Do we want to backport this to 8.x?