mirror of
https://github.com/elastic/kibana.git
synced 2025-06-28 03:01:21 -04:00
15348c0f28
# Backport This will backport the following commits from `main` to `9.0`: - [[Hardening] Kibana Feature API Privileges Names (#208067)](https://github.com/elastic/kibana/pull/208067) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Elena Shostak","email":"165678770+elena-shostak@users.noreply.github.com"},"sourceCommit":{"committedDate":"2025-02-03T14:22:29Z","message":"[Hardening] Kibana Feature API Privileges Names (#208067)\n\n## Summary\r\n\r\nAs part of our effort to harden API action definitions and enforce\r\nstandards this PR adds an utility `ApiPrivileges` class.\r\nIt is supposed to be used for both feature registration and API route\r\ndefinition to construct the privilege name.\r\n```ts\r\nplugins.features.registerKibanaFeature({\r\n privileges: {\r\n all: {\r\n app: [...],\r\n catalogue: [...],\r\n api: [ApiPrivileges.manage('subject_name')],\r\n ...\r\n },\r\n read: {\r\n ...\r\n api: [ApiPrivileges.read('subject_name')],\r\n ...\r\n },\r\n },\r\n})\r\n....\r\n\r\n// route definition\r\nrouter.get(\r\n {\r\n path: 'api_path',\r\n security: {\r\n authz: {\r\n requiredPrivileges: [ApiPrivileges.manage('subject_name')],\r\n },\r\n },\r\n },\r\n async (ctx, req, res) => {}\r\n);\r\n```\r\n\r\n`require_kibana_feature_privileges_naming` eslint rule has been added to\r\nshow warning if the API privilege name doesn't satisfy the naming\r\nconvention.\r\n\r\n### Naming convention\r\n\r\n- API privilege should start with valid `ApiOperation`: `manage`,\r\n`read`, `update`, `delete`, `create`\r\n- API privilege should use `_` as separator\r\n\r\n❌ `read-entity-a`\r\n❌ `delete_entity-a`\r\n❌ `entity_manage`\r\n✅ `read_entity_a`\r\n✅ `delete_entity_a`\r\n✅ `manage_entity`\r\n\r\n> [!IMPORTANT] \r\n> Serverless ZDT update scenario:\r\n>\r\n> - version N has an endpoint protected with the `old_privilege_read`.\r\n> - version N+1 has the same endpoint protected with a new\r\n`read_privilege`.\r\n> \r\n> There might be a short period between the time the UI pod N+1 passes\r\nSO migrations and updates privileges and the time it's marked as\r\nready-to-handle-requests by k8s, and when UI pod N is terminated.\r\n>\r\n> After discussion with @legrego and @azasypkin we decided to ignore it\r\ndue to the perceived risk-to-cost ratio:\r\n> 1. The time window users might be affected is very narrow because we\r\nregister privileges late in the Kibana startup flow (e.g., after SO\r\nmigrations).\r\n> 2. The transient 403 errors users might get won't result in session\r\ntermination and shouldn't lead to data loss.\r\n> 3. The roll-out will be performed in batches over the course of\r\nmultiple weeks and implemented by different teams. This means the impact\r\nper release shouldn't be significant.\r\n\r\n### Checklist\r\n\r\n- [x]\r\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\r\nwas added for features that require explanation or tutorials\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios\r\n\r\n__Relates: https://github.com/elastic/kibana/issues/198716__\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>","sha":"504510b92b0e92cbc173f0de517c506d2f54d536","branchLabelMapping":{"^v9.1.0$":"main","^v8.19.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Security","release_note:skip","Feature:Hardening","backport:prev-minor","Team:Obs AI Assistant","v9.1.0"],"title":"[Hardening] Kibana Feature API Privileges Names","number":208067,"url":"https://github.com/elastic/kibana/pull/208067","mergeCommit":{"message":"[Hardening] Kibana Feature API Privileges Names (#208067)\n\n## Summary\r\n\r\nAs part of our effort to harden API action definitions and enforce\r\nstandards this PR adds an utility `ApiPrivileges` class.\r\nIt is supposed to be used for both feature registration and API route\r\ndefinition to construct the privilege name.\r\n```ts\r\nplugins.features.registerKibanaFeature({\r\n privileges: {\r\n all: {\r\n app: [...],\r\n catalogue: [...],\r\n api: [ApiPrivileges.manage('subject_name')],\r\n ...\r\n },\r\n read: {\r\n ...\r\n api: [ApiPrivileges.read('subject_name')],\r\n ...\r\n },\r\n },\r\n})\r\n....\r\n\r\n// route definition\r\nrouter.get(\r\n {\r\n path: 'api_path',\r\n security: {\r\n authz: {\r\n requiredPrivileges: [ApiPrivileges.manage('subject_name')],\r\n },\r\n },\r\n },\r\n async (ctx, req, res) => {}\r\n);\r\n```\r\n\r\n`require_kibana_feature_privileges_naming` eslint rule has been added to\r\nshow warning if the API privilege name doesn't satisfy the naming\r\nconvention.\r\n\r\n### Naming convention\r\n\r\n- API privilege should start with valid `ApiOperation`: `manage`,\r\n`read`, `update`, `delete`, `create`\r\n- API privilege should use `_` as separator\r\n\r\n❌ `read-entity-a`\r\n❌ `delete_entity-a`\r\n❌ `entity_manage`\r\n✅ `read_entity_a`\r\n✅ `delete_entity_a`\r\n✅ `manage_entity`\r\n\r\n> [!IMPORTANT] \r\n> Serverless ZDT update scenario:\r\n>\r\n> - version N has an endpoint protected with the `old_privilege_read`.\r\n> - version N+1 has the same endpoint protected with a new\r\n`read_privilege`.\r\n> \r\n> There might be a short period between the time the UI pod N+1 passes\r\nSO migrations and updates privileges and the time it's marked as\r\nready-to-handle-requests by k8s, and when UI pod N is terminated.\r\n>\r\n> After discussion with @legrego and @azasypkin we decided to ignore it\r\ndue to the perceived risk-to-cost ratio:\r\n> 1. The time window users might be affected is very narrow because we\r\nregister privileges late in the Kibana startup flow (e.g., after SO\r\nmigrations).\r\n> 2. The transient 403 errors users might get won't result in session\r\ntermination and shouldn't lead to data loss.\r\n> 3. The roll-out will be performed in batches over the course of\r\nmultiple weeks and implemented by different teams. This means the impact\r\nper release shouldn't be significant.\r\n\r\n### Checklist\r\n\r\n- [x]\r\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\r\nwas added for features that require explanation or tutorials\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios\r\n\r\n__Relates: https://github.com/elastic/kibana/issues/198716__\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>","sha":"504510b92b0e92cbc173f0de517c506d2f54d536"}},"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/208067","number":208067,"mergeCommit":{"message":"[Hardening] Kibana Feature API Privileges Names (#208067)\n\n## Summary\r\n\r\nAs part of our effort to harden API action definitions and enforce\r\nstandards this PR adds an utility `ApiPrivileges` class.\r\nIt is supposed to be used for both feature registration and API route\r\ndefinition to construct the privilege name.\r\n```ts\r\nplugins.features.registerKibanaFeature({\r\n privileges: {\r\n all: {\r\n app: [...],\r\n catalogue: [...],\r\n api: [ApiPrivileges.manage('subject_name')],\r\n ...\r\n },\r\n read: {\r\n ...\r\n api: [ApiPrivileges.read('subject_name')],\r\n ...\r\n },\r\n },\r\n})\r\n....\r\n\r\n// route definition\r\nrouter.get(\r\n {\r\n path: 'api_path',\r\n security: {\r\n authz: {\r\n requiredPrivileges: [ApiPrivileges.manage('subject_name')],\r\n },\r\n },\r\n },\r\n async (ctx, req, res) => {}\r\n);\r\n```\r\n\r\n`require_kibana_feature_privileges_naming` eslint rule has been added to\r\nshow warning if the API privilege name doesn't satisfy the naming\r\nconvention.\r\n\r\n### Naming convention\r\n\r\n- API privilege should start with valid `ApiOperation`: `manage`,\r\n`read`, `update`, `delete`, `create`\r\n- API privilege should use `_` as separator\r\n\r\n❌ `read-entity-a`\r\n❌ `delete_entity-a`\r\n❌ `entity_manage`\r\n✅ `read_entity_a`\r\n✅ `delete_entity_a`\r\n✅ `manage_entity`\r\n\r\n> [!IMPORTANT] \r\n> Serverless ZDT update scenario:\r\n>\r\n> - version N has an endpoint protected with the `old_privilege_read`.\r\n> - version N+1 has the same endpoint protected with a new\r\n`read_privilege`.\r\n> \r\n> There might be a short period between the time the UI pod N+1 passes\r\nSO migrations and updates privileges and the time it's marked as\r\nready-to-handle-requests by k8s, and when UI pod N is terminated.\r\n>\r\n> After discussion with @legrego and @azasypkin we decided to ignore it\r\ndue to the perceived risk-to-cost ratio:\r\n> 1. The time window users might be affected is very narrow because we\r\nregister privileges late in the Kibana startup flow (e.g., after SO\r\nmigrations).\r\n> 2. The transient 403 errors users might get won't result in session\r\ntermination and shouldn't lead to data loss.\r\n> 3. The roll-out will be performed in batches over the course of\r\nmultiple weeks and implemented by different teams. This means the impact\r\nper release shouldn't be significant.\r\n\r\n### Checklist\r\n\r\n- [x]\r\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\r\nwas added for features that require explanation or tutorials\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios\r\n\r\n__Relates: https://github.com/elastic/kibana/issues/198716__\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>","sha":"504510b92b0e92cbc173f0de517c506d2f54d536"}}]}] BACKPORT--> Co-authored-by: Elena Shostak <165678770+elena-shostak@users.noreply.github.com>
26 lines
1.4 KiB
JavaScript
26 lines
1.4 KiB
JavaScript
/*
|
|
* Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
|
|
* or more contributor license agreements. Licensed under the "Elastic License
|
|
* 2.0", the "GNU Affero General Public License v3.0 only", and the "Server Side
|
|
* Public License v 1"; you may not use this file except in compliance with, at
|
|
* your election, the "Elastic License 2.0", the "GNU Affero General Public
|
|
* License v3.0 only", or the "Server Side Public License, v 1".
|
|
*/
|
|
|
|
module.exports = {
|
|
rules: {
|
|
'require-license-header': require('./rules/require_license_header'),
|
|
'disallow-license-headers': require('./rules/disallow_license_headers'),
|
|
module_migration: require('./rules/module_migration'),
|
|
no_export_all: require('./rules/no_export_all'),
|
|
no_async_promise_body: require('./rules/no_async_promise_body'),
|
|
no_async_foreach: require('./rules/no_async_foreach'),
|
|
no_trailing_import_slash: require('./rules/no_trailing_import_slash'),
|
|
no_constructor_args_in_property_initializers: require('./rules/no_constructor_args_in_property_initializers'),
|
|
no_this_in_property_initializers: require('./rules/no_this_in_property_initializers'),
|
|
no_unsafe_console: require('./rules/no_unsafe_console'),
|
|
no_unsafe_hash: require('./rules/no_unsafe_hash'),
|
|
no_deprecated_authz_config: require('./rules/no_deprecated_authz_config'),
|
|
require_kibana_feature_privileges_naming: require('./rules/require_kibana_feature_privileges_naming'),
|
|
},
|
|
};
|