Adds Role Based Access-Control to the Alerting & Action plugins based on Kibana Feature Controls

examples/alerting_example/kibana.json

@@ -4,6 +4,6 @@
   "kibanaVersion": "kibana",
   "server": true,
   "ui": true,
-  "requiredPlugins": ["triggers_actions_ui", "charts", "data", "alerts", "actions", "developerExamples"],
+  "requiredPlugins": ["triggers_actions_ui", "charts", "data", "alerts", "actions", "features", "developerExamples"],
   "optionalPlugins": []
 }

examples/alerting_example/server/plugin.ts

@@ -19,19 +19,49 @@
 
 import { Plugin, CoreSetup } from 'kibana/server';
 import { PluginSetupContract as AlertingSetup } from '../../../x-pack/plugins/alerts/server';
+import { PluginSetupContract as FeaturesPluginSetup } from '../../../x-pack/plugins/features/server';
 
 import { alertType as alwaysFiringAlert } from './alert_types/always_firing';
 import { alertType as peopleInSpaceAlert } from './alert_types/astros';
 
 // this plugin's dependendencies
 export interface AlertingExampleDeps {
   alerts: AlertingSetup;
+  features: FeaturesPluginSetup;
 }
 
 export class AlertingExamplePlugin implements Plugin<void, void, AlertingExampleDeps> {
-  public setup(core: CoreSetup, { alerts }: AlertingExampleDeps) {
+  public setup(core: CoreSetup, { alerts, features }: AlertingExampleDeps) {
     alerts.registerType(alwaysFiringAlert);
     alerts.registerType(peopleInSpaceAlert);
+
+    features.registerFeature({
+      id: 'alertsExample',
+      name: 'alertsExample',
+      app: [],
+      privileges: {
+        all: {
+          alerting: {
+            all: [alwaysFiringAlert.id, peopleInSpaceAlert.id],
+          },
+          savedObject: {
+            all: [],
+            read: [],
+          },
+          ui: [],
+        },
+        read: {
+          alerting: {
+            read: [alwaysFiringAlert.id, peopleInSpaceAlert.id],
+          },
+          savedObject: {
+            all: [],
+            read: [],
+          },
+          ui: [],
+        },
+      },
+    });
   }
 
   public start() {}

x-pack/plugins/alerting_builtins/server/index.ts

@@ -7,6 +7,7 @@
 import { PluginInitializerContext } from 'src/core/server';
 import { AlertingBuiltinsPlugin } from './plugin';
 import { configSchema } from './config';
+export { ID as IndexThresholdId } from './alert_types/index_threshold/alert_type';
 
 export const plugin = (ctx: PluginInitializerContext) => new AlertingBuiltinsPlugin(ctx);
 

x-pack/plugins/alerts/README.md

@@ -18,6 +18,7 @@ Table of Contents
 		- [Methods](#methods)
 		- [Executor](#executor)
 		- [Example](#example)
+	- [Role Based Access-Control](#role-based-access-control)
 	- [Alert Navigation](#alert-navigation)
 	- [RESTful API](#restful-api)
 		- [`POST /api/alerts/alert`: Create alert](#post-apialert-create-alert)
@@ -58,7 +59,8 @@ A Kibana alert detects a condition and executes one or more actions when that co
 ## Usage
 
 1. Develop and register an alert type (see alert types -> example).
-2. Create an alert using the RESTful API (see alerts -> create).
+2. Configure feature level privileges using RBAC 
+3. Create an alert using the RESTful API (see alerts -> create).
 
 ## Limitations
 
@@ -293,6 +295,105 @@ server.newPlatform.setup.plugins.alerts.registerType({
 });
 ```
 
+## Role Based Access-Control
+Once you have registered your AlertType, you need to grant your users privileges to use it.
+When registering a feature in Kibana you can specify multiple types of privileges which are granted to users when they're assigned certain roles.
+
+Assuming your feature introduces its own AlertTypes, you'll want to control:
+- Which roles have all/read privileges for these AlertTypes when they're inside the feature
+- Which roles have all/read privileges for these AlertTypes when they're outside the feature (in another feature or in the global alerts management)
+
+In addition, when users are inside your feature you might want to grant them access to AlertTypes from other features, such as built-in AlertTypes or AlertTypes provided by other features.
+
+You can control all of these abilities by assigning privileges to the Alerting Framework from within your own feature, for example:
+
+```
+features.registerFeature({
+      id: 'my-application-id',
+      name: 'My Application',
+      app: [],
+      privileges: {
+        all: {
+          alerting: {
+            all: [
+				// grant `all` over our own types
+				'my-application-id.my-alert-type',
+				'my-application-id.my-restricted-alert-type',
+				// grant `all` over the built-in IndexThreshold
+				'.index-threshold',
+				// grant `all` over Uptime's TLS AlertType
+				'xpack.uptime.alerts.actionGroups.tls'],
+          },
+        },
+        read: {
+          alerting: {
+            read: [
+				// grant `read` over our own type
+				'my-application-id.my-alert-type',
+				// grant `read` over the built-in IndexThreshold
+				'.index-threshold', 
+				// grant `read` over Uptime's TLS AlertType
+				'xpack.uptime.alerts.actionGroups.tls'],
+          },
+        },
+      },
+    });
+```
+
+In this example we can see the following:
+- Our feature grants any user who's assigned the `all` role in our feature the `all` role in the Alerting framework over every alert of the `my-application-id.my-alert-type` type which is created _inside_ the feature. What that means is that this privilege will allow the user to execute any of the `all` operations (listed below) on these alerts as long as their `consumer` is `my-application-id`. Below that you'll notice we've done the same with the `read` role, which is grants the Alerting Framework's `read` role privileges over these very same alerts.
+- In addition, our feature grants the same privileges over any alert of type `my-application-id.my-restricted-alert-type`, which is another hypothetical alertType registered by this feature. It's worth noting though that this type has been omitted from the `read` role. What this means is that only users with the `all` role will be able to interact with alerts of this type.
+- Next, lets look at the `.index-threshold` and `xpack.uptime.alerts.actionGroups.tls` types. These have been specified in both `read` and `all`, which means that all the users in the feature will gain privileges over alerts of these types (as long as their `consumer` is `my-application-id`). The difference between these two and the previous two is that they are _produced_ by other features! `.index-threshold` is a built-in type, provided by the framework, and specifying it here is all you need in order to grant privileges to use this type. On the other hand, `xpack.uptime.alerts.actionGroups.tls` is an AlertType provided by the _Uptime_ feature. Specifying this type here tells the Alerting Framework that as far as the `my-application-id` feature is concerned, the user is privileged to use this type (with `all` and `read` applied), but that isn't enough. Using another feature's AlertType is only possible if both the producer of the AlertType, and the consumer of the AlertType, explicitly grant privileges to do so. In this case, the _Uptime_ feature would have to explicitly add these privileges to a role and this role would have to be granted to this user.
+
+It's important to note that any role can be granted a mix of `all` and `read` privileges accross multiple type, for example:
+
+```
+features.registerFeature({
+      id: 'my-application-id',
+      name: 'My Application',
+      app: [],
+      privileges: {
+        all: {
+          alerting: {
+            all: ['my-application-id.my-alert-type', 'my-application-id.my-restricted-alert-type'],
+          },
+        },
+        read: {
+          alerting: {
+			all:['my-application-id.my-alert-type']
+            read: ['my-application-id.my-restricted-alert-type'],
+          },
+        },
+      },
+    });
+```
+
+In the above example, you note that instead of denying users with the `read` role any access to the `my-application-id.my-restricted-alert-type` type, we've decided that these users _should_ be granted `read` privileges over the _resitricted_ AlertType.
+As part of that same change, we also decided that not only should they be allowed to `read` the _restricted_ AlertType, but actually, despite having `read` privileges to the feature as a whole, we do actualyl want to allow them to create our basic 'my-application-id.my-alert-type' AlertType, as we consider it an extension of _reading_ data in our feature, rather than _writing_ it.
+
+### `read` privileges vs. `all` privileges
+When a user is granted the `read` role in the Alerting Framework, they will be able to execute the following api calls:
+- get
+- getAlertState
+- find
+
+When a user is granted the `all` role in the Alerting Framework, they will be able to execute al lof the `read` privileged api calls, but in addition they'll be granted the following calls:
+- `create`
+- `delete`
+- `update`
+- `enable`
+- `disable`
+- `updateApiKey`
+- `muteAll`
+- `unmuteAll`
+- `muteInstance`
+- `unmuteInstance`
+
+Finally, all users, whether they're granted any role or not, are privileged to call the following:
+- `listAlertTypes`, but the output is limited to displaying the AlertTypes the user is perivileged to `get`
+
+Attempting to execute any operation the user isn't privileged to execute will result in an Authorization error throws by the AlertsClient.
+
 ## Alert Navigation
 When registering an Alert Type, you'll likely want to provide a way of viewing alerts of that type within your own plugin, or perhaps you want to provide a view for all alerts created from within your solution within your own UI.
 

x-pack/plugins/alerts/common/index.ts

@@ -21,3 +21,4 @@ export interface AlertingFrameworkHealth {
 }
 
 export const BASE_ALERT_API_PATH = '/api/alerts';
+export const AlertsFeatureId = 'alerts';

x-pack/plugins/alerts/kibana.json

@@ -5,6 +5,6 @@
   "version": "8.0.0",
   "kibanaVersion": "kibana",
   "configPath": ["xpack", "alerts"],
-  "requiredPlugins": ["licensing", "taskManager", "encryptedSavedObjects", "actions", "eventLog"],
+  "requiredPlugins": ["licensing", "taskManager", "encryptedSavedObjects", "actions", "eventLog", "features"],
   "optionalPlugins": ["usageCollection", "spaces", "security"]
 }

x-pack/plugins/alerts/server/alert_type_registry.test.ts

@@ -43,6 +43,38 @@ describe('has()', () => {
 });
 
 describe('register()', () => {
+  test('throws if AlertType Id contains invalid characters', () => {
+    const alertType = {
+      id: 'test',
+      name: 'Test',
+      actionGroups: [
+        {
+          id: 'default',
+          name: 'Default',
+        },
+      ],
+      defaultActionGroupId: 'default',
+      executor: jest.fn(),
+      producer: 'alerting',
+    };
+    // eslint-disable-next-line @typescript-eslint/no-var-requires
+    const registry = new AlertTypeRegistry(alertTypeRegistryParams);
+
+    const invalidCharacters = [' ', ':', '*', '*', '/'];
+    for (const char of invalidCharacters) {
+      expect(() => registry.register({ ...alertType, id: `${alertType.id}${char}` })).toThrowError(
+        new Error(`expected AlertType Id not to include invalid character: ${char}`)
+      );
+    }
+
+    const [first, second] = invalidCharacters;
+    expect(() =>
+      registry.register({ ...alertType, id: `${first}${alertType.id}${second}` })
+    ).toThrowError(
+      new Error(`expected AlertType Id not to include invalid characters: ${first}, ${second}`)
+    );
+  });
+
   test('registers the executor with the task manager', () => {
     const alertType = {
       id: 'test',
@@ -177,7 +209,7 @@ describe('list()', () => {
   test('should return empty when nothing is registered', () => {
     const registry = new AlertTypeRegistry(alertTypeRegistryParams);
     const result = registry.list();
-    expect(result).toMatchInlineSnapshot(`Array []`);
+    expect(result).toMatchInlineSnapshot(`Set {}`);
   });
 
   test('should return registered types', () => {
@@ -197,7 +229,7 @@ describe('list()', () => {
     });
     const result = registry.list();
     expect(result).toMatchInlineSnapshot(`
-      Array [
+      Set {
         Object {
           "actionGroups": Array [
             Object {
@@ -214,7 +246,7 @@ describe('list()', () => {
           "name": "Test",
           "producer": "alerting",
         },
-      ]
+      }
     `);
   });
 

x-pack/plugins/alerts/server/alert_type_registry.ts

@@ -6,6 +6,8 @@
 
 import Boom from 'boom';
 import { i18n } from '@kbn/i18n';
+import { schema } from '@kbn/config-schema';
+import typeDetect from 'type-detect';
 import { RunContext, TaskManagerSetupContract } from '../../task_manager/server';
 import { TaskRunnerFactory } from './task_runner';
 import { AlertType } from './types';
@@ -15,6 +17,34 @@ interface ConstructorOptions {
   taskRunnerFactory: TaskRunnerFactory;
 }
 
+export interface RegistryAlertType
+  extends Pick<
+    AlertType,
+    'name' | 'actionGroups' | 'defaultActionGroupId' | 'actionVariables' | 'producer'
+  > {
+  id: string;
+}
+
+/**
+ * AlertType IDs are used as part of the authorization strings used to
+ * grant users privileged operations. There is a limited range of characters
+ * we can use in these auth strings, so we apply these same limitations to
+ * the AlertType Ids.
+ * If you wish to change this, please confer with the Kibana security team.
+ */
+const alertIdSchema = schema.string({
+  validate(value: string): string | void {
+    if (typeof value !== 'string') {
+      return `expected AlertType Id of type [string] but got [${typeDetect(value)}]`;
+    } else if (!value.match(/^[a-zA-Z0-9_\-\.]*$/)) {
+      const invalid = value.match(/[^a-zA-Z0-9_\-\.]+/g)!;
+      return `expected AlertType Id not to include invalid character${
+        invalid.length > 1 ? `s` : ``
+      }: ${invalid?.join(`, `)}`;
+    }
+  },
+});
+
 export class AlertTypeRegistry {
   private readonly taskManager: TaskManagerSetupContract;
   private readonly alertTypes: Map<string, AlertType> = new Map();
@@ -41,7 +71,7 @@ export class AlertTypeRegistry {
       );
     }
     alertType.actionVariables = normalizedActionVariables(alertType.actionVariables);
-    this.alertTypes.set(alertType.id, { ...alertType });
+    this.alertTypes.set(alertIdSchema.validate(alertType.id), { ...alertType });
     this.taskManager.registerTaskDefinitions({
       [`alerting:${alertType.id}`]: {
         title: alertType.name,
@@ -66,15 +96,22 @@ export class AlertTypeRegistry {
     return this.alertTypes.get(id)!;
   }
 
-  public list() {
-    return Array.from(this.alertTypes).map(([alertTypeId, alertType]) => ({
-      id: alertTypeId,
-      name: alertType.name,
-      actionGroups: alertType.actionGroups,
-      defaultActionGroupId: alertType.defaultActionGroupId,
-      actionVariables: alertType.actionVariables,
-      producer: alertType.producer,
-    }));
+  public list(): Set<RegistryAlertType> {
+    return new Set(
+      Array.from(this.alertTypes).map(
+        ([id, { name, actionGroups, defaultActionGroupId, actionVariables, producer }]: [
+          string,
+          AlertType
+        ]) => ({
+          id,
+          name,
+          actionGroups,
+          defaultActionGroupId,
+          actionVariables,
+          producer,
+        })
+      )
+    );
   }
 }
 

x-pack/plugins/alerts/server/alerts_client.mock.ts

@@ -24,6 +24,7 @@ const createAlertsClientMock = () => {
     unmuteAll: jest.fn(),
     muteInstance: jest.fn(),
     unmuteInstance: jest.fn(),
+    listAlertTypes: jest.fn(),
   };
   return mocked;
 };