Granting kibana_system reserved role access to "all" privileges to .alerts* and .siem-signals* index #72181

dhurley14 · 2021-04-23T19:18:20Z

The RAC team is storing alerts as data in the .alerts* and .siem-signals* (legacy) indices, which the Kibana user needs access to in order to CRUD alerts.

Ref: elastic/kibana#95721

drake: elastic/kibana#94502

elasticmachine · 2021-04-23T19:27:46Z

Pinging @elastic/es-security (Team:Security)

dgieselaar · 2021-04-24T08:56:44Z

...core/src/main/java/org/elasticsearch/xpack/core/security/authz/store/ReservedRolesStore.java

@@ -37,6 +37,8 @@
 import java.util.stream.Collectors;

 public class ReservedRolesStore implements BiConsumer<Set<String>, ActionListener<RoleRetrievalResult>> {
+    public static final String LEGACY_ALERTS_INDEX = ".siem-signals*";
+    public static final String ALERTS_INDEX = ".alerts*";


The write target for the rule registry currently is prefixed with .kibana, or rather .${kibana.index}. This is needed to support legacy multi-tenancy. If we don't do this, we'll run into weird things where rules or other saved objects are stored in different Kibana instances but end up writing to the same Elasticsearch index, which could lead to conflicts.

Or not being able to find the rule from an alert because it is in a different space. However, that is probably also an issue with cross-cluster search, or with deleted rules even, so maybe making the index configurable and dealing with missing rules in code/UX would be acceptable.

Okay so we really only need to have the change for .siem-signals since .kibana.{alerts} will be covered by the kibana system user's role privileges for the index pattern .kibana* correct?

If we decide to use the internal user, yes, but I think that we are not sure of that yet (unfortunately). If we don't, it would be up to the user to bootstrap the needed templates/indices/alias though we can think of ways to do that for them, eg by using Fleet or something clever with require_alias when bulk indexing.

dhurley14 · 2021-05-04T15:55:15Z

...core/src/main/java/org/elasticsearch/xpack/core/security/authz/store/ReservedRolesStore.java

@@ -37,6 +37,10 @@
 import java.util.stream.Collectors;

 public class ReservedRolesStore implements BiConsumer<Set<String>, ActionListener<RoleRetrievalResult>> {
+    public static final String LEGACY_ALERTS_INDEX = ".siem-signals*";
+    public static final String LEGACY_ALERTS_INDEX_CCS = "*:.siem-signals*";


I had trouble determining if the additional CCS index pattern is necessary considering all privileges for .siem-signals and .alerts grants CCS privileges. Looking for feedback here from people in-the-know.

albertzaharovits · 2021-05-11T16:45:35Z

...core/src/main/java/org/elasticsearch/xpack/core/security/authz/store/ReservedRolesStore.java

+    public static final String LEGACY_ALERTS_INDEX = ".siem-signals*";
+    public static final String LEGACY_ALERTS_INDEX_CCS = "*:.siem-signals*";
+    public static final String ALERTS_INDEX = ".alerts*";
+    public static final String ALERTS_INDEX_CCS = "*:.alerts*";


The CCS patterns here and above don't work with our authz model for CCS.

TLDR: You shouldn't specify CCS patterns.

When the kibana_system reaches cross cluster, it is the remote cluster that performs the authorization there.
So, if on the local cluster node, the kibana user issues a search request for remote_cluster:.alerts_tenant1, that's automatically authorized locally, but the receiving remote node, part of remote_cluster, performs authorization using the local role definition.

albertzaharovits · 2021-05-11T16:47:22Z

...src/test/java/org/elasticsearch/xpack/core/security/authz/store/ReservedRolesStoreTests.java

+            ReservedRolesStore.LEGACY_ALERTS_INDEX,
+            ReservedRolesStore.ALERTS_INDEX,


Suggested change

ReservedRolesStore.LEGACY_ALERTS_INDEX,

ReservedRolesStore.ALERTS_INDEX,

ReservedRolesStore.LEGACY_ALERTS_INDEX + randomAlphaOfLength(randomIntBetween(0, 13)),

ReservedRolesStore.ALERTS_INDEX + randomAlphaOfLength(randomIntBetween(0, 13)),

albertzaharovits

Please remove the CCS pattern, and it should be OK.

kobelb · 2021-05-11T21:37:22Z

LGTM after removing the CCS pattern.

…bana user access

albertzaharovits

LGTM

…#72181) Co-authored-by: Devin W. Hurley <[email protected]>

…ernal.alerts* (#76624) **Parent ticket:** elastic/kibana#101016 **Related to:** #72181 ## Summary Similar to the previous PR (#72181), we'd like to add privileges to a new set of indices to the `kibana_system` role. The reason for that is we need to have different naming schemes for alerts-as-data index aliases and backing indices pointing to these aliases, which in turn is needed to support backwards compatibility, migrations and reindexing in the future. We didn't want to prefix the backing indices with `.kibana-`, so we're adding a new `.internal.alerts` prefix. Prefixing with `.kibana-` would make them system indices, which means they would not be supposed to be read by end users, which is not what we want. `.internal` could become a universal prefix for hidden Kibana indices, but at this point I don't feel confident enough to generalise prematurely.

…ernal.alerts* (elastic#76624) **Parent ticket:** elastic/kibana#101016 **Related to:** elastic#72181 ## Summary Similar to the previous PR (elastic#72181), we'd like to add privileges to a new set of indices to the `kibana_system` role. The reason for that is we need to have different naming schemes for alerts-as-data index aliases and backing indices pointing to these aliases, which in turn is needed to support backwards compatibility, migrations and reindexing in the future. We didn't want to prefix the backing indices with `.kibana-`, so we're adding a new `.internal.alerts` prefix. Prefixing with `.kibana-` would make them system indices, which means they would not be supposed to be read by end users, which is not what we want. `.internal` could become a universal prefix for hidden Kibana indices, but at this point I don't feel confident enough to generalise prematurely.

…ernal.alerts* (#76624) (#76635) **Parent ticket:** elastic/kibana#101016 **Related to:** #72181 ## Summary Similar to the previous PR (#72181), we'd like to add privileges to a new set of indices to the `kibana_system` role. The reason for that is we need to have different naming schemes for alerts-as-data index aliases and backing indices pointing to these aliases, which in turn is needed to support backwards compatibility, migrations and reindexing in the future. We didn't want to prefix the backing indices with `.kibana-`, so we're adding a new `.internal.alerts` prefix. Prefixing with `.kibana-` would make them system indices, which means they would not be supposed to be read by end users, which is not what we want. `.internal` could become a universal prefix for hidden Kibana indices, but at this point I don't feel confident enough to generalise prematurely. Co-authored-by: Georgii Gorbachev <[email protected]>

elasticsearchmachine added the external-contributor Pull request authored by a developer outside the Elasticsearch team label Apr 23, 2021

dhurley14 changed the title ~~adds .alerts and .siem-signals (legacy) alerts as data indices for ki…~~ Granting kibana_system reserved role access to "all" privileges for .alerts* and .siem-signals* indices Apr 23, 2021

dhurley14 self-assigned this Apr 23, 2021

dhurley14 added :Security/Authorization Roles, Privileges, DLS/FLS, RBAC/ABAC Team:Security Meta label for security team v7.14.0 v8.0.0 labels Apr 23, 2021

dhurley14 marked this pull request as ready for review April 23, 2021 19:27

jkakavas requested a review from a team April 23, 2021 19:33

dgieselaar reviewed Apr 24, 2021

View reviewed changes

dhurley14 force-pushed the add-rac-kibana-user branch from 1a9c353 to d676a8a Compare April 29, 2021 13:48

dhurley14 changed the title ~~Granting kibana_system reserved role access to "all" privileges for .alerts* and .siem-signals* indices~~ Granting kibana_system reserved role access to "all" privileges for .siem-signals* index Apr 29, 2021

dhurley14 force-pushed the add-rac-kibana-user branch from d676a8a to c44e163 Compare April 29, 2021 15:20

dhurley14 changed the title ~~Granting kibana_system reserved role access to "all" privileges for .siem-signals* index~~ Granting kibana_system reserved role access to "all" privileges to .alerts* and .siem-signals* index Apr 29, 2021

dhurley14 force-pushed the add-rac-kibana-user branch from c44e163 to bad1737 Compare April 29, 2021 22:53

banderror mentioned this pull request Apr 30, 2021

[RAC] RFC: Index naming and hierarchy elastic/kibana#98912

Open

dhurley14 mentioned this pull request Apr 30, 2021

[RAC][Alerts] - Addition of RBAC to unified alerts index elastic/kibana#96014

Closed

2 tasks

dhurley14 commented May 4, 2021

View reviewed changes

albertzaharovits reviewed May 11, 2021

View reviewed changes

albertzaharovits requested changes May 11, 2021

View reviewed changes

dhurley14 added 2 commits May 11, 2021 19:25

adds .alerts and .siem-signals (legacy) alerts as data indices for ki…

03f6729

…bana user access

adds CCS index patterns to kibana system user privileges

d91f39b

dhurley14 force-pushed the add-rac-kibana-user branch from da076ef to 11e31f4 Compare May 11, 2021 23:26

remove CCS patterns and update test

bfe416a

dhurley14 force-pushed the add-rac-kibana-user branch from 11e31f4 to bfe416a Compare May 11, 2021 23:32

albertzaharovits approved these changes May 12, 2021

View reviewed changes

albertzaharovits merged commit 823abb5 into elastic:master May 12, 2021

albertzaharovits mentioned this pull request May 12, 2021

BACKPORT 7x Grant kibana_system all access to .alerts* and .siem-signals* indices… #72964

Merged

albertzaharovits added the >enhancement label May 12, 2021

albertzaharovits added a commit that referenced this pull request May 12, 2021

Grant kibana_system all access to .alerts* and .siem-signals* indices (…

0bf1601

…#72181) Co-authored-by: Devin W. Hurley <[email protected]>

dgieselaar mentioned this pull request May 12, 2021

[RAC] Decouple registry from alerts-as-data client elastic/kibana#98935

Merged

banderror mentioned this pull request May 17, 2021

[RAC] Rule monitoring: Event Log for Rule Registry elastic/kibana#98353

Merged

8 tasks

dgieselaar mentioned this pull request Jun 10, 2021

[RAC] Update alert documents in lifecycle rule type helper elastic/kibana#101598

Merged

dhurley14 mentioned this pull request Jul 13, 2021

[Alerts as Data] - Finding a home elastic/kibana#104958

Open

jakelandis added v8.0.0-alpha1 and removed v8.0.0 labels Jul 26, 2021

banderror mentioned this pull request Aug 17, 2021

Granting kibana_system reserved role access to "all" privileges to .internal.alerts* index #76624

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Granting kibana_system reserved role access to "all" privileges to .alerts* and .siem-signals* index #72181

Granting kibana_system reserved role access to "all" privileges to .alerts* and .siem-signals* index #72181

dhurley14 commented Apr 23, 2021 •

edited

Loading

elasticmachine commented Apr 23, 2021

dgieselaar Apr 24, 2021 •

edited

Loading

dgieselaar Apr 25, 2021

dhurley14 Apr 26, 2021

dgieselaar Apr 26, 2021

dhurley14 May 4, 2021

albertzaharovits May 11, 2021 •

edited

Loading

albertzaharovits May 11, 2021

albertzaharovits left a comment

kobelb commented May 11, 2021

albertzaharovits left a comment

		ReservedRolesStore.LEGACY_ALERTS_INDEX,
		ReservedRolesStore.ALERTS_INDEX,

Granting kibana_system reserved role access to "all" privileges to .alerts* and .siem-signals* index #72181

Granting kibana_system reserved role access to "all" privileges to .alerts* and .siem-signals* index #72181

Conversation

dhurley14 commented Apr 23, 2021 • edited Loading

elasticmachine commented Apr 23, 2021

dgieselaar Apr 24, 2021 • edited Loading

Choose a reason for hiding this comment

dgieselaar Apr 25, 2021

Choose a reason for hiding this comment

dhurley14 Apr 26, 2021

Choose a reason for hiding this comment

dgieselaar Apr 26, 2021

Choose a reason for hiding this comment

dhurley14 May 4, 2021

Choose a reason for hiding this comment

albertzaharovits May 11, 2021 • edited Loading

Choose a reason for hiding this comment

albertzaharovits May 11, 2021

Choose a reason for hiding this comment

albertzaharovits left a comment

Choose a reason for hiding this comment

kobelb commented May 11, 2021

albertzaharovits left a comment

Choose a reason for hiding this comment

dhurley14 commented Apr 23, 2021 •

edited

Loading

dgieselaar Apr 24, 2021 •

edited

Loading

albertzaharovits May 11, 2021 •

edited

Loading