Make reserved built-in roles queryable

[slobodanadamovic]

This PR makes reserved built-in roles queryable via Query Role API by indexing them into the .security index.

Currently, the built-in roles were only available via Get Role API.

The built-in roles are synced into the .security index on cluster recovery. The .security index will be created (if it's not existing) before built-in roles are synced. In order to avoid concurrent updates, the built-in roles will only be synced by a master node.

Once the built-in roles are synced, the information about indexed roles is kept in the cluster state as part of the .security index's metadata. The map containing role names and their digests is persisted as part of queryable_built_in_roles_digest property:

GET /_cluster/state/metadata/.security
"queryable_built_in_roles_digest": {
   "superuser": "lRRmA3kPO1/ztr3ESAlTetOuDjgUC3fKcGS3ZCqM+6k=",
    ...
}

Important: The reserved roles stored in the .security index are only intended to be used for querying and retrieving. The role resolution and mapping during authentication will remain the same and give a priority to static/file role definitions. This is ensured by the order in which role providers (built-in, file and native) are invoked. It’s important to note this because there can be a short period of time where we have a temporary inconsistency between actual built-in role definitions and what is stored in the .security index.

---

Note: The functionality is temporarily hidden behind the es.queryable_built_in_roles_enabled system property. By default, the flag is disabled and will become enabled in a followup PR. The reason for this is to keep this PR as small as possible and to avoid the need to adjust a large number of tests that don't expect .security index to exist.

Testing:
To run and test locally execute ./gradlew run -Dtests.jvm.argline="-Des.queryable_built_in_roles_enabled=true".
To query all reserved built-in roles execute:

POST /_security/_query/role
{
  "query": {
    "bool": {
      "must": {
        "term": {
          "metadata._reserved": true
        }
      }
    }
  }
}

[slobodanadamovic]

Calculating hash per role, so we can optimize the update and only update the roles whose definition have actually changed.

[slobodanadamovic]

We want to update only the roles whose definition (digest) changed. On average this will be one or two roles per release.

[slobodanadamovic]

The reserved roles do not change dynamically.

[slobodanadamovic]

Using ordered TreeMap here to produce consistent hash.

[n1v0lg]

Good catch! Just in case you've considered the same thing: instead of imposing this constraint here, I wonder if it makes sense to confine it to QueryableBuiltInRolesUtils by copying the role descriptor. That would avoid data copying on each role descriptor creation. Just a thought though, good to leave as is.

[slobodanadamovic]

I was thinking of a similar(ish) approach: serialize to JSON, flatten all properties, sort them and then hash strings. This way I would avoid imposing any order in the constructor or during parsing of roles, but rather during hashing. Also, we would avoid copying role descriptors (not really true as we would copy a json map) and sorting would be confined in QueryableBuiltInRolesUtils. LMWYT

[slobodanadamovic]

This could look something like this:

    public static String calculateHash(final RoleDescriptor roleDescriptor) {
        final MessageDigest hash = MessageDigests.sha256();
        try (XContentBuilder jsonBuilder = XContentFactory.jsonBuilder()) {
            roleDescriptor.toXContent(jsonBuilder, EMPTY_PARAMS);
            final Map<String, Object> flattenMap = Maps.flatten(
                XContentHelper.convertToMap(BytesReference.bytes(jsonBuilder), /*ordered*/ true, XContentType.JSON).v2(),
                true, // flattenArrays
                true // ordered
            );
            hash.update(flattenMap.toString().getBytes(StandardCharsets.UTF_8));
        } catch (IOException e) {
            throw new IllegalStateException("failed to compute role digest of [" + roleDescriptor.getName() +"] role", e);
        }

        // HEX vs Base64 encoding is a trade-off between readability and space efficiency
        // opting for Base64 here to reduce the size of the cluster state
        return Base64.getEncoder().encodeToString(hash.digest());
    }

Edit: I pushed the change 70181d6. I think this is a better approach as it should be future proof in case we add new map properties.

[slobodanadamovic]

Need to go with the factory approach in order to be able to inject different QueryableBuiltInRoles.Provider implementations.

[slobodanadamovic]

Using a set here, since list caused duplicate results to be returned. I would propose we keep this workaround, until we enable this feature by default. Later we can remove the logic of combining static and native roles here, and always return roles from the .security index.

[slobodanadamovic]

Also, WDYT about a basic upgrade test? Those are a bit of a pain to write--esp. since we are backporting to 8.18--but it feels like a useful thing to cover (going from a version without queryable built-in roles to one with).

Makes total sense to have one. I'll prefer to add it in a followup PR, as this PR is already getting too big to backport.

[n1v0lg]

LGTM -- great work on this. Few more comments/suggestions but no need for a re-review.

[elasticsearchmachine]

💔 Backport failed

Status	Branch	Result
❌	8.x	Commit could not be cherrypicked due to conflicts

You can use sqren/backport to manually backport by running backport --upstream elastic/elasticsearch --pr 117581