## Summary
Currently, our `requiredPrivileges` structure supports `allRequired` and
`anyRequired` for defining authorization logic. However, there is [a
need to
support](https://github.com/elastic/kibana/pull/205335#issuecomment-2569275302)
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 <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
As part of our effort to harden API action definitions and enforce
standards this PR adds an utility `ApiPrivileges` class.
It is supposed to be used for both feature registration and API route
definition to construct the privilege name.
```ts
plugins.features.registerKibanaFeature({
privileges: {
all: {
app: [...],
catalogue: [...],
api: [ApiPrivileges.manage('subject_name')],
...
},
read: {
...
api: [ApiPrivileges.read('subject_name')],
...
},
},
})
....
// route definition
router.get(
{
path: 'api_path',
security: {
authz: {
requiredPrivileges: [ApiPrivileges.manage('subject_name')],
},
},
},
async (ctx, req, res) => {}
);
```
`require_kibana_feature_privileges_naming` eslint rule has been added to
show warning if the API privilege name doesn't satisfy the naming
convention.
### Naming convention
- API privilege should start with valid `ApiOperation`: `manage`,
`read`, `update`, `delete`, `create`
- API privilege should use `_` as separator
❌ `read-entity-a`
❌ `delete_entity-a`
❌ `entity_manage`
✅ `read_entity_a`
✅ `delete_entity_a`
✅ `manage_entity`
> [!IMPORTANT]
> Serverless ZDT update scenario:
>
> - version N has an endpoint protected with the `old_privilege_read`.
> - version N+1 has the same endpoint protected with a new
`read_privilege`.
>
> There might be a short period between the time the UI pod N+1 passes
SO migrations and updates privileges and the time it's marked as
ready-to-handle-requests by k8s, and when UI pod N is terminated.
>
> After discussion with @legrego and @azasypkin we decided to ignore it
due to the perceived risk-to-cost ratio:
> 1. The time window users might be affected is very narrow because we
register privileges late in the Kibana startup flow (e.g., after SO
migrations).
> 2. The transient 403 errors users might get won't result in session
termination and shouldn't lead to data loss.
> 3. The roll-out will be performed in batches over the course of
multiple weeks and implemented by different teams. This means the impact
per release shouldn't be significant.
### 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
__Relates: https://github.com/elastic/kibana/issues/198716__
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR adds support for explicit indication whether endpoint is
restricted to operator only users.
### Context
1. If user has [all operator
privileges](https://github.com/elastic/elasticsearch/blob/main/x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/operator/DefaultOperatorOnlyRegistry.java#L35-#L53)
granted, but is not listed as operator in `operator_users.yml`, ES would
throw an unauthorized error.
2. If user is listed as operator in `operator_users.yml`, but doesn't
have necessary privileges granted, ES would throw an unauthorized error.
3. It’s not possible to determine if a user is operator via any ES API,
i.e. `_has_privileges`.
4. If operator privileges are disabled we skip the the check for it,
that's why we require to explicitly specify additional privileges to
ensure that the route is protected even when operator privileges are
disabled.
### 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
__Relates: https://github.com/elastic/kibana/issues/196271__
### How to test
1. Add your user to the operators list
1bd8144924/packages/kbn-es/src/serverless_resources/operator_users.yml (L4)
or use existing user from the list to log in.
2. Run ES and Kibana serverless
3. Change any endpoint or create a new one with the following security
config
```
security: {
authz: {
requiredPrivileges: [ReservedPrivilegesSet.operator],
},
},
```
4. Check with enabled and disabled operator privileges (set
`xpack.security.operator_privileges.enabled`)
## Release Note
Added support for explicit indication whether endpoint is restricted to
operator only users at the route definition level.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
- Added section for migrating routes created by utility function.
- Added `patch` method to route methods in eslint rule.
### Checklist
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
## Summary
Added documentation for the security route configuration.
### Checklist
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
