mirror of
https://github.com/elastic/kibana.git
synced 2025-06-28 19:13:14 -04:00
504510b92b
## 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>
|
||
|---|---|---|
| .. | ||
| __fixtures__/no_restricted_paths | ||
| disallow_license_headers.js | ||
| disallow_license_headers.test.js | ||
| module_migration.js | ||
| module_migration.test.js | ||
| no_async_foreach.js | ||
| no_async_foreach.test.js | ||
| no_async_promise_body.js | ||
| no_async_promise_body.test.js | ||
| no_constructor_args_in_property_initializers.js | ||
| no_constructor_args_in_property_initializers.test.js | ||
| no_deprecated_authz_config.js | ||
| no_deprecated_authz_config.test.js | ||
| no_export_all.js | ||
| no_export_all.test.js | ||
| no_this_in_property_initializers.js | ||
| no_this_in_property_initializers.test.js | ||
| no_trailing_import_slash.js | ||
| no_trailing_import_slash.test.js | ||
| no_unsafe_console.js | ||
| no_unsafe_console.test.js | ||
| no_unsafe_hash.js | ||
| no_unsafe_hash.test.js | ||
| require_kibana_feature_privileges_naming.js | ||
| require_kibana_feature_privileges_naming.test.js | ||
| require_license_header.js | ||
| require_license_header.test.js | ||