API Console Auditing

Elastic Orchestration Elastic Cloud Enterprise (ECE)
1

Hi there all deployments have a api console that uses the default elastic user to execute commands to the clusters. Is there any where that this is audited. IE something like user bob has executed command Post _search on cluster id XXXXXX

If not is there away to disable this console. We have some very strict auditing requirements based on the data we hold

2

Can I get a clarification, since there are some terms that are a bit overloaded here:

  • Are you referring to the API console in ECE, or the dev console in Kibana?
    • The first (ECE UI) of these runs all commands as (I believe) found-internal-admin-proxy user
    • The second (Kibana UI) runs all commands as whatever ES user they are logged in as

I'm going to assume that you are referring to the ECE console, and what you want to do is give colleagues "read only" access to the ECE UI and for them not to be able to perform certain actions on the cluster, including certain types of data access

If so, there's 2 answers:

  • Longer term, it will be possible to provision users with different roles with fairly granular access (we actually use a beta of this in our cloud to restrict access to the console) ... this may not be possible in ECE but it might be worth filing an issue to see if there is a workaround
  • In the short term, if you just remove (post deployment creation) all roles from the found-internal-admin-proxy user in the "Data" section of the advanced editor, then you can give users readonly access to the ECE console and they will not be able to access the cluster
    • (or you can create roles with the desired access, eg calls like _cat/recovery and _node/stats are made by the UI via this route to populate the various pages)
    • (Any user with write privileges on a cluster can do what they want to it - that will have to wait for more granular ECE role definitions)
3

Hi yes this is for the ECE console not kibana

Changing the roles for each deployment is going to be a pain when as we are planning that we will have over 50 deployments that is change will need to be applied for.

having a more granular RBAC for the console would nice

4

Yep agreed it's not ideal, the best you can do so far is use the /metadata/raw API endpoint to automate

(How are you authenticating users? LDAP, SAML, or native? I was going to look into whether we can use (internal) ECE custom roles that we use in ESS without breaking the production ECE RBAC)

5

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.