System indices should be treated as a special set of indices and not be
accessible by all users. The existing security codebase has the notion
of restricted indices, which are currently a subset of system indices.
This change unifies the two concepts by making system indices the set
of restricted indices. This means that going forward, consumers of
system indices will need access to restricted indices.
Our intention is that this will be handled internally as much as
possible. For example, restricted index access can be used implicitly
by setting a valid origin on a request or using a system index plugin.
In these cases, the security module will apply internally defined
privileges when necessary.
The main impact of this change for developers is that system index
deletions will require superuser privileges, so we have to make sure
we are using an admin role for test cleanup.
Closes#69298
Co-authored-by: William Brafford <william.brafford@elastic.co>
Co-authored-by: Albert Zaharovits <albert.zaharovits@elastic.co>
* Adding base RestHandler class for Enrollment APIs
This change adding an abstract RestHandler class and extends it by
enrollment API classes (node and Kibana enrollment). It will handle the
cases when `enrollment.enabled` is not set to `true`. It will return an
appropriate exception in this case.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
This commit changes the Enroll Kibana API to create and return
a token for this service account, instead of setting and returning the
password of the kibana_system built-in user. Both the token name and
value are returned in the response of the API.
In 8.0, with security on by default, we store the HTTP
layer CA PrivateKeyEntry in the http.ssl keystore (along
with the node certificate) so that it is available in our
Enrollment API transport actions.
When loading a keystore, the current behavior is that the
X509ExtendedKeyManager will iterate through the PrivateKeyEntry
objects and will return the first key/certificate that satisfies
the requirements of the client and the server configuration,
and lacks any additional logic/filters.
We need the KeyManager to deterministically pick the node
certificate/key in all cases as this is the intended entry to be
used for TLS on the HTTP layer.
This change introduces filtering when creating the in-memory
keystore the KeyManager is loaded with, so that it will not
include PrivateKeyEntry objects when:
- there are more than 1 PrivateKeyEntry objects in the keystore
- The leaf certificate associated with the PrivateKeyEntry is a
CA certificate
Related: #75097
Co-authored-by: Ioannis Kakavas <ioannis@elastic.co>
Jay Modi
Lyudmila Fokina
Ioannis Kakavas
Rene Groeschke