Kibana 7.11 problems with spaces and roles -

[byteandbit (bog)]

Hello,

We have created a new space just for read only user to access - Visibility in Analytics->Dashboard, Discover and Visualise.

Then we created a new role within new space only, with read only privileges again for Analytics->Dashboard, Discover and Visualise. We did not assigned any Cluster privileges as we are just testing RBAC at this stage.

And then we created a new user and assigned new role to it.

For some reason when the new user logins to Kibana it can change the space to 'default' one with full access to everything.... On top of that within new space Management menu is available (along with Analytics one) with all submenus and again full access to write/read etc.

Is this a bug or we are doing something wrong?

We are running ELK 7.11 on k8s (self managed) on GCP.

Thanks,
Bog

[stephenb (Stephen Brown)]

Hmm It should work as you think. Just curious what license level are you running just Basic Right? pretty sure that should still work.

So this is what my 7.11.1 looks like

Role Definition: Note only my dashboard-external space at the bottom.
I customized the space as well Just Dashboards

Here is my user definition note the only role.

Now here is what mine looks like when I log in note the default space is not available.

[byteandbit (bog)]

Thank you for looking at this!

Yes we are running Basic license.

We have tried to delete new role, space and user and crate again but unfortunately keep getting the same problem (ability to select Default space and access to Stack Management menu).

Any suggestions how to troubleshoot it?

[stephenb (Stephen Brown)]

I was thinking for a moment that Basic would be the problem, but I just set up exactly the same using a Cluster I deployed with ECK (K8s) with a basic license and it worked just how I expected with a basic license.

What version I am using 7.11.1

One question are you actually logging completely out and then logging in with the new user... if you just switch between spaces while you are logged in as elastic user you will not see the role based control because it inherits the the elastic user privileges.

If still trouble please paste a complete view of the role creation. Notice I only have the one space then I went into that a specifically set the priviliges, it is kinda weird you set up what is available in the space under manage space then you refine it / do it again in the Kbana privileges during role creation.

[byteandbit (bog)]

Zone setting:

Rolle setting:

User setting:

After User logins (see default space to chose from):

After switching space to new one, management menu is still visible.

[stephenb (Stephen Brown)]

That is unusual...

What are you putting in for the index privileges in the role? What about cluster privileges?

Are you integrated with some other SAML / Auth provider? How did you install?

Here is what mine looks like no stack management and no other spaces.

What I see your looks like is when I just change spaces without logging out, but I can see your "t" user in the top right.

Can you try logging in from a completely separate browser or incognito window? What Browser are you using?

[byteandbit (bog)]

At this stage we did not configure any cluster privileges. Should we?

No we are not integrating with any 3rd party for Authentication.

As in my first post we are on k8s (self managed) on GCP, 7.11.1 ELK.

We are logging in in private window (FireFox) or Chrome (Incognito). In both cases exactly the same problem.

We are also behind Google Identity-Aware Proxy.

Thank you,
Bog

[TimV (Tim Vernum)]

Can you show us two additional things:

1. the raw role definition
2. the user's privileges

For the role definition, go into Dev Tools / Console in Kibana (when logged in as your administration user, e.g. elastic) and run

GET /_security/role/test-role

That will show us exactly what this role can do, and will show us if something is out of place.

For the user's privileges, go into Dev Tools / Console as the test user (assuming that is possible - it sounds like in your case the user has access to Dev Tools, even though you don't want it to), and run

GET /_security/_authenticate

and

GET /_security/user/_privileges

Something isn't quite right here, and hopefully that information will pinpoint what it is, and then we can try and work out why it got into that state.

[byteandbit (bog)]

As elastic user:

    GET /_security/role/test-role

    {
      "test-role" : {
        "cluster" : [ ],
        "indices" : [ ],
        "applications" : [
          {
            "application" : "kibana-.kibana",
            "privileges" : [
              "feature_discover.read",
              "feature_dashboard.read",
              "feature_visualize.read"
            ],
            "resources" : [
              "space:test-readonly"
            ]
          }
        ],
        "run_as" : [ ],
        "metadata" : { },
        "transient_metadata" : {
          "enabled" : true
        }
      }
    }

As test user and after switching to default space (to access Dev Tools):

     GET /_security/_authenticate 
        
      {
          "username" : "test",
          "roles" : [
            "test-role",
            "superuser"
          ],
          "full_name" : "",
          "email" : "",
          "metadata" : { },
          "enabled" : true,
          "authentication_realm" : {
            "name" : "default_native",
            "type" : "native"
          },
          "lookup_realm" : {
            "name" : "default_native",
            "type" : "native"
          },
          "authentication_type" : "realm"
        }

Strange why there is superuser role?

    GET /_security/user/_privileges

    {
      "cluster" : [
        "all"
      ],
      "global" : [ ],
      "indices" : [
        {
          "names" : [
            "*"
          ],
          "privileges" : [
            "all"
          ],
          "allow_restricted_indices" : true
        }
      ],
      "applications" : [
        {
          "application" : "*",
          "privileges" : [
            "*"
          ],
          "resources" : [
            "*"
          ]
        }
      ],
      "run_as" : [
        "*"
      ]
    }

Full privileges??

[TimV (Tim Vernum)]

@byteandbit

Strange why there is superuser role?

You don't happen to have anonymous access turned on in Elasticsearch do you?

[byteandbit (bog)]

Hmm I think we have?!

Here is our ES config:

cluster.name=csv-test
discovery.seed_hosts=es-cluster-0.elasticsearch
cluster.initial_master_nodes=es-cluster-0
ES_JAVA_OPTS=-Xms512m -Xmx512m
xpack.security.enabled=true
xpack.security.http.ssl.enabled=true
xpack.security.http.ssl.keystore.path=certs/http.p12
xpack.security.http.ssl.client_authentication=optional
xpack.security.authc.api_key.enabled=true
xpack.security.authc.token.enabled=false
xpack.security.authc.anonymous.username=agent
xpack.security.authc.anonymous.roles=superuser
ELASTIC_USERNAME=elastic
node.store.allow_mmap=false
xpack.security.transport.ssl.enabled=true
xpack.security.transport.ssl.verification_mode=certificate
xpack.security.transport.ssl.keystore.path=certs/elastic-certificates.p12
xpack.security.transport.ssl.truststore.path=certs/elastic-certificates.p12

[TimV (Tim Vernum)]

That explains it then.

One of the surprising features of anonymous access in Elasticsearch is that the roles listed in xpack.security.authc.anonymous.roles are added to every user, not just the anonymous user.

It is more accurate to think of them as "global roles" rather than "anonymous roles". I'm afraid that you will not be able to implement role based access control while also granting the superuser role to every user.

[stephenb (Stephen Brown)]

@TimV Thanks I learn something new everyday, put that in my knowledge base.

[byteandbit (bog)]

Tanks Guys for the help.

I have disabled xpack.security.authc.anonymous.roles and now roles work as expected.