Create user have read only permission ( query via dev tools )

Currently. I’m stuck on creating a user for a developer used for the query which has read-only permission.

read-only role:

  • Cluster permission
cluster_composite_ops_ro
cluster_monitor
indices:admin/template/get
  • Index Permission:
  • Pattern: * ( i want give user for all user can read everything from es )
  • index permission: read / get /search

Those setting is good and prevent no info log related to lack of permission on ODFE Log.
But somehow user still can delete index by query:

DELETE index_name

Version: 7.8.0 and 7.10.2

Update: I tried to create index custom-like

security-auditlog-2021.03.01_test

and can not delete it
but other index patterns, it can delete it as well. So what is different here :smiley:

Hi,

have you checked View roles and identities in Kibana? Maybe another roles is attached to your user that has this permission.

Regards
Clifford

Hi there, thanks for the reply.
I create it by the api ( user, role and mapping ) so i’m
sure there is no another role is attached to my user :smiley:

PUT _opendistro/_security/api/internalusers/readonly
{
  "password": "randompassword",
  "backend_roles": ["readonly"]
}

PUT _opendistro/_security/api/roles/readonly
{
  "cluster_permissions": [
    "cluster_composite_ops_ro",
    "indices:admin/template/get",
    "cluster:monitor/health",
    "cluster:monitor/state"
  ],
  "index_permissions": [
    {
      "index_patterns": [
        "*"
      ],
      "dls": "",
      "fls": [],
      "masked_fields": [],
      "allowed_actions": [
        "read",
        "indices_monitor",
        "indices:admin/mappings/get",
        "indices:admin/aliases/get",
        "indices:admin/template/get"
      ]
    }
  ],
    "tenant_permissions": [
    {
      "tenant_patterns": [
        "global_tenant"
      ],
      "allowed_actions": [
        "kibana_all_read"
      ]
    }
  ]
}

@BlackMetalz Just tried your version set up and exact API calls and not able to delete any indices.

Can you check View roles and identities in Kibana as per note from clsa and make sure the only see the below:

Screenshot 2021-04-08 at 12.16.15

1 Like

Hi there, thanks for the reply. I forgot to show/include the part mapping role.

PUT _opendistro/_security/api/rolesmapping/readonly
{
  "backend_roles" : [ "readonly" ],
  "hosts" : [ "*" ],
  "users" : [ "readonly" ]
}

This mapping ensures that the user is mapped to this role, but it doesn’t make it exclusive, so the user can also be mapped to other roles (in error), giving him/her the ability to delete the indices, therefore you need to check which roles the user is mapped to after login.

1 Like

Seem like it happens in some specific conditions.

Step I re-procedure:

  1. Create user readonly in existing cluster like query above
  2. Use user admin to create a new index like:
PUT analytics_item_url_test
  1. log in to a new user and use Delete query
DELETE analytics_item_url_test

then that index is gone.

my odfe config:

cluster.name: es-data-analytics
node.name: "es-70-253"
node.master: True
node.data: False
node.ingest: False
path.data: /data/odfe/data
path.logs: /data/odfe/logs
bootstrap.memory_lock: false
network.host: 0.0.0.0
http.port: 9200
discovery.seed_hosts: ['10.3.70.253', '10.3.68.36', '10.3.70.96', '10.3.70.241', '10.3.69.153', '10.3.70.234', '10.3.71.223', '10.3.70.155']
cluster.initial_master_nodes: ['es-70-253', 'es-68-36', 'es-70-96']
discovery.zen.minimum_master_nodes: 2
path.repo: /path/data/test

######## End of Elasticsearch Config ###########

######## Start OpenDistro for Elasticsearch Security Demo Configuration ########
# WARNING: revise all the lines below before you go into production
opendistro_security.ssl.transport.pemcert_filepath: esnode.pem
opendistro_security.ssl.transport.pemkey_filepath: esnode-key.pem
opendistro_security.ssl.transport.pemtrustedcas_filepath: root-ca.pem
opendistro_security.ssl.transport.enforce_hostname_verification: false
opendistro_security.ssl.http.enabled: false
opendistro_security.ssl.http.pemcert_filepath: esnode.pem
opendistro_security.ssl.http.pemkey_filepath: esnode-key.pem
opendistro_security.ssl.http.pemtrustedcas_filepath: root-ca.pem
opendistro_security.allow_unsafe_democertificates: true
opendistro_security.allow_default_init_securityindex: true
opendistro_security.authcz.admin_dn:
  - CN=kirk,OU=client,O=client,L=test, C=de

opendistro_security.audit.type: internal_elasticsearch
# Make Security audit log to monthly for save shards
opendistro_security.audit.config.index: "'security-auditlog-'YYYY.MM"
opendistro_security.enable_snapshot_restore_privilege: true
opendistro_security.check_snapshot_restore_write_privileges: true
opendistro_security.restapi.roles_enabled: ["all_access", "security_rest_api_access"]
cluster.routing.allocation.disk.threshold_enabled: false
######## End OpenDistro for Elasticsearch Security Demo Configuration ########

And yeah in test cluster I’m not able to delete index thought.
Still investigate what was that :frowning:

@BlackMetalz when you log in as new user and able to delete indices, can you check what roles the user is mapped to via View roles and identities in Kibana

1 Like

Role section:




Role Mapping section:

I’m using odfe with 7.8 version :frowning:

When you are logged in as new user can you run this api call and paste the result?

GET _opendistro/_security/api/account
1 Like

Sorry for the late reply!
Wow. Now I see the real problem.

It has many other roles show below when call your api you told me above:

{
  "user_name" : "readonly",
  "is_reserved" : false,
  "is_hidden" : false,
  "is_internal_user" : true,
  "user_requested_tenant" : null,
  "backend_roles" : [
    "readonly"
  ],
  "custom_attribute_names" : [ ],
  "tenants" : {
    "readonly" : true,
    "global_tenant" : false
  },
  "roles" : [
    "analytics_user",
    "monitor_user",
    "own_index",
    "readonly",
    "vda_user"
  ]
}

The funny thing it hasn’t show that info in kibana or query like this ( maybe they are all the same ).

GET _opendistro/_security/api/roles/readonly
GET _opendistro/_security/api/rolesmapping/readonly
GET _opendistro/_security/api/internalusers/readonly

I’m trying to read more document about this.

I tried to delete user, role and mapping like this to re-create user with a hope those roles will gone from user but no luck

DELETE _opendistro/_security/api/internalusers/readonly
DELETE _opendistro/_security/api/roles/readonly
DELETE _opendistro/_security/api/rolesmapping/readonly

P/s: it makes no sense since roles will appear whenever new role is created

@BlackMetalz that would indicate that those roles:
“analytics_user”,
“monitor_user”,
“own_index”,
“vda_user”

Are mapped to every user, which gives you the added privileges.

You might want to examine the mapping on those roles with below command:

GET _opendistro/_security/api/rolesmapping/analytics_user … etc

“own_index” is ok, you can ignore that, just gives user privilege to index he/she creates.

Result of GET _opendistro/_security/api/rolesmapping/user…

{
  "vda_user" : {
    "hosts" : [
      "*"
    ],
    "users" : [
      "vda_user"
    ],
    "reserved" : false,
    "hidden" : false,
    "backend_roles" : [
      "vda_user"
    ],
    "and_backend_roles" : [ ]
  }
}

{
  "analytics_user" : {
    "hosts" : [
      "*"
    ],
    "users" : [
      "analytics_user"
    ],
    "reserved" : false,
    "hidden" : false,
    "backend_roles" : [
      "analytics_user"
    ],
    "and_backend_roles" : [ ]
  }
}

{
  "monitor_user" : {
    "hosts" : [
      "*"
    ],
    "users" : [
      "monitor_user"
    ],
    "reserved" : false,
    "hidden" : false,
    "backend_roles" : [
      "monitor_user"
    ],
    "and_backend_roles" : [ ]
  }
}


I’m pretty sure that role is not unique and not mapped to or mapped by other users. The API i used for mapping i told in the first beginning of conversation :smiley:

Is what is causing issues, if you remove this using role_mapping.yml file this should fix it.

If you have made changes using UI, You should export them first using securityadmin.sh, command below:

./path/to/elasticsearch/plugins/opendistro_security/tools/securityadmin.sh -cd /path/to/elasticsearch/plugins/opendistro_security/securityconfig/ -icl -nhnv -cacert /path/to/elasticsearch/config/root-ca.pem -cert /path/to/elasticsearch/config/kirk.pem -key /path/to/elasticsearch/config/kirk-key.pem -h localhost -r

This will save configuration files from the current set up on edfe security index in securityconfig/ folder (Dont forget to remove old configs). The role_mappings now need to be updated to remove the hosts: “*” setting.

Once updated don’t forget to upload the new setting using same command but without the trailing “-r” (retrieve):

./path/to/elasticsearch/plugins/opendistro_security/tools/securityadmin.sh -cd /path/to/elasticsearch/plugins/opendistro_security/securityconfig/ -icl -nhnv -cacert /path/to/elasticsearch/config/root-ca.pem -cert /path/to/elasticsearch/config/kirk.pem -key /path/to/elasticsearch/config/kirk-key.pem -h localhost

This will upload the updated config and you should be good to test (no restart required)

1 Like

What do you think do mapping role like this

PUT _opendistro/_security/api/rolesmapping/readonly
{
  "backend_roles" : [ "readonly" ],
  "users" : [ "readonly" ]
}

Query: GET _opendistro/_security/api/rolesmapping/readonly

Result:

{
  "readonly" : {
    "hosts" : [ ],
    "users" : [
      "readonly"
    ],
    "reserved" : false,
    "hidden" : false,
    "backend_roles" : [
      "readonly"
    ],
    "and_backend_roles" : [ ]
  }
}

I guess that is the same way, IDK, just guess :sweat_smile:

This will map the user to this role, but user can be (and is in your case) mapped to multiple roles, as a result different roles provide different privileges. Therefore to ensure you are only mapped to the roles you want, you need to correct mapping on the other roles.
As currently any user signing on, will automatically be mapped to those roles, regardless what other roles you are mapping them to.

1 Like

gonna do it soon as u said. :smiley:
I just tried to create a completely different user name. And issue still the same. :sweat:

Honestly this issue still give me a cancer :sweat: