[Fleet] Allow Kibana system user to read and write to Fleet server indices #67726
Conversation
|
Pinging @elastic/es-security (Team:Security) |
nchaulet
force-pushed
the
feature-allow-kibana-system-user-read-write-fleet-server-indices
branch
from
ddda8b7 to
7719096
Compare
There was a problem hiding this comment.
Lets make sure we specify the minimal permissions needed.
@scunningham Would be good to get your eyes on this one too.
| // Fleet Server indices Kibana read and write to these indices to manage Elastic Agents | ||
| RoleDescriptor.IndicesPrivileges.builder() | ||
| .indices(".fleet-agents") | ||
| .privileges("read", "write").build(), |
There was a problem hiding this comment.
Does Kibana need write permissions for the agents?
There was a problem hiding this comment.
Yes right now if we want to reassign an agent to a new policy, force unenroll, we do it by writing to .fleet-agents
There was a problem hiding this comment.
Would be nice to use the doc line 158 to also mention why a specific access is needed.
There was a problem hiding this comment.
I was hoping for a bit more details and have comments on all the lines. For example that write permissions are need to force unenroll etc.
There was a problem hiding this comment.
Just updated with more a per indice comment 👍
...core/src/main/java/org/elasticsearch/xpack/core/security/authz/store/ReservedRolesStore.java
Outdated
Show resolved
Hide resolved
...core/src/main/java/org/elasticsearch/xpack/core/security/authz/store/ReservedRolesStore.java
Outdated
Show resolved
Hide resolved
nchaulet
force-pushed
the
feature-allow-kibana-system-user-read-write-fleet-server-indices
branch
from
094d3ed to
a9e1003
Compare
There was a problem hiding this comment.
Overall LGTM. Would be good to get a check on this also from @blakerouse @aleksmaus @scunningham as this is pretty fundamental to all we do.
Are these all indices or do we also have data streams?
| .privileges("read", "write").build(), | ||
| // Kibana write to this indice new enrollment api key | ||
| RoleDescriptor.IndicesPrivileges.builder() | ||
| .indices(".fleet-enrollment-api-keys") |
There was a problem hiding this comment.
TLDR: If there are Kibana authz checks that can be bypassed by directly reading the enrollment api keys index, I suggest we make it a restricted index. This might be the case for the other fleet indices as well.
Users that have read access to all indices, eg:
POST /_security/role/read_all_indices
{
"indices": [
{
"names": [ "*" ],
"privileges": ["all"]
}
]
}
can access dot-named indices (which are implicitly hidden) using the index name or, in the case of wildcards, with a request option.
For indices that contain sensitive data (more than just configuration data or raw-metrics, which is a nuisance to expose but is not equivalent to bypassing any other checks we have in place) we have an extra protection level, named restricted indices. The restricted indices concept is most likely to become superseded by system indices, but this is what we have and use currently.
There was a problem hiding this comment.
I was not aware of restricted indices @ruflin @blakerouse @aleksmaus do you think this will work for us. The mapping of this indices will be created with a regular user using an integration package.
There was a problem hiding this comment.
Was also not aware of restricted indices concept. @scunningham @jaymode One more option ... ?
There was a problem hiding this comment.
To maybe make it more clear what I mean, restricted indices confer addition protection by requiring explicit toggling of a flag when defining index permissions in a role, and relies on the expectation that roles in general don't have this flag toggled. Importantly, .kibana* is not a restricted index (but .security* is) which means that roles don't require the "hidden" flag toggled to grant access to it. Besides kibana there are other indices (think ML) that maybe should deserve more protection.
The fact that this is a new index and that it contains credentials prompted my suggestion.
But restricted indices is no silver bullet, we can just simply document non-fleet-admin users should not be granted privileges over these indices.
There was a problem hiding this comment.
nchaulet
deleted the
feature-allow-kibana-system-user-read-write-fleet-server-indices
branch
…dices (#67726) (#67838) To allow to migrate from Kibana saved object to new indices for Fleet server we need to add `read` and `write` permissions to the following indices: * `.fleet-agents` * `.fleet-actions` * `.fleet-actions-results` * `.fleet-enrollment-api-keys` * `.fleet-policies` * `.fleet-servers` The indices will be created via an integration package with the current user permissions.
Description
To allow to migrate from Kibana saved object to new indices for Fleet server we need to add
readandwritepermissions to the following indices:.fleet-agents.fleet-actions.fleet-actions-results.fleet-enrollment-api-keys.fleet-policies.fleet-serversThe indices will be created via an integration package with the current user permissions.
Related to elastic/kibana#87372