Granting kibana_system reserved role access to "all" privileges to .alerts* and .siem-signals* index#72181
Conversation
elasticsearchmachine
added
the
external-contributor
dhurley14
changed the title
dhurley14
added
:Security/Authorization
|
Pinging @elastic/es-security (Team:Security) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
force-pushed
the
add-rac-kibana-user
branch
from
1a9c353 to
d676a8a
Compare
dhurley14
changed the title
dhurley14
force-pushed
the
add-rac-kibana-user
branch
from
d676a8a to
c44e163
Compare
dhurley14
changed the title
dhurley14
force-pushed
the
add-rac-kibana-user
branch
from
c44e163 to
bad1737
Compare
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
| ReservedRolesStore.LEGACY_ALERTS_INDEX, | |
| ReservedRolesStore.ALERTS_INDEX, | |
| ReservedRolesStore.LEGACY_ALERTS_INDEX + randomAlphaOfLength(randomIntBetween(0, 13)), | |
| ReservedRolesStore.ALERTS_INDEX + randomAlphaOfLength(randomIntBetween(0, 13)), |
albertzaharovits
left a comment
albertzaharovits
left a comment
There was a problem hiding this comment.
Please remove the CCS pattern, and it should be OK.
|
LGTM after removing the CCS pattern. |
dhurley14
force-pushed
the
add-rac-kibana-user
branch
from
da076ef to
11e31f4
Compare
dhurley14
force-pushed
the
add-rac-kibana-user
branch
from
11e31f4 to
bfe416a
Compare
…#72181) Co-authored-by: Devin W. Hurley <snowmiser111@gmail.com>
…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 <banderror@gmail.com>
7 participants
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