Not able to curl the index with username and its defined role

Search Guard
1

Greetings everyone,

We are facing below issues while configuring SearchGaurd.

Environment details:

OS: Ubuntu:14.04
Java; 1.8
ES: 5.6.8
SearchGaurd: 5-5.6.8-19
Cerebro: 0.7.3

Use-case:

Indexes : client1 & client2

Users: user1/2/3/4 and admin

We want to assign below permissions:

user1 can have an access only to client1 index (both read/write)
user2 can have an access only to client2 index (both read/write)
user3 can have an access only to client1 index (only read)
user4 can have an access only to client2 index (only read)
admin user can have an access to both the indexes (both read/write)

Below are the entries we have made:

file: sg_internal_users.yml

user1:
hash: $2a$12$i9OlhTub5HYc3sgUJD24QeEQPXPCr1CHz8EGB4KEHKZdaq4fWE8iW
#password is: demo1
roles:

  • sg_client1_read
  • sg_client1_write

user2:
hash: $2a$12$Hrzo.FfsyXx6KxhqLZhlPeB62rKlTeBorWnzJCzp7c5HjeLTq07Yy
#password is: demo2
roles:
- sg_client2_read
- sg_client2_write

user3:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: demo3
roles:

  • sg_client1_read

user4:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: demo4
roles:

  • sg_client2_read

admin:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: admin
roles:

  • sg_client1_read
  • sg_client1_write
  • sg_client2_read
  • sg_client2_write
···

###########################

file: sg_roles.yml

Read/Monitor/CRUD on all the indices and cluster wide

sg_our_admin:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
indices:
‘*’:
- CRUD

#Read client1 indices only
sg_client1_read:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client1:
'’:
- INDICES_MONITOR
- INDICES_ALL
- RO

#Read client2 indices only
sg_client2_read:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client2:
'’:
- INDICES_MONITOR
- INDICES_ALL
- RO

#Write client1 indices only
sg_client1_write:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client1:
'’:
- INDICES_MONITOR
- INDICES_ALL
- WRITE

#Write client2 indices only
sg_client2_write:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client2:
'’:
- INDICES_MONITOR
- INDICES_ALL
- WRITE

#############################

file: sg_roles_mapping.yml

Role Mappings

sg_our_admin:
users:
- admin

sg_client1_read:
users:
- user1
- user3

sg_client2_read:
users:
- user2
- user4

sg_client1_write:
users:
- user1

sg_client2_write:
users:
- user2

We reload the SearchGaurd config using sgadmin.sh script and it is loading all the roles and mappings successfully. But the moment we try to curl the specific index with respective username and password we are getting an error as:

type":“security_exception”,“reason”:"no permissions for [indices:monitor/stats]

Though we have provided the roles related to monitor (CLUSTER_MONITOR and INDICES_MONITOR). We are not clear how to achieve this.

Can one illuminate us on this and enlighten us if we are approaching it in wrong manner?

We have couple of doubts that:

  • Is there a convention to assign roles with ‘sg_’ as prefix or we can go by any name?
  • What is tenant for and what is its role?

Thank you in adcance!

2

Can you pls attach all of your sg_*.yml files (as files) and post the curl command you are executing along with the full response

Your questions:

* Is there a convention to assign roles with 'sg_' as prefix or we can go by any name?

can be any name

* What is tenant for and what is its role?

tenants are a kibana specific thing, i think you can just ignore them at the moment.
see Kibana Multitenancy | Security for Elasticsearch | Search Guard

···

Am 23.04.2018 um 06:46 schrieb Sahil Modgill <modgill.s30@gmail.com>:

Greetings everyone,

We are facing below issues while configuring SearchGaurd.

Environment details:

OS: Ubuntu:14.04
Java; 1.8
ES: 5.6.8
SearchGaurd: 5-5.6.8-19
Cerebro: 0.7.3

Use-case:

Indexes : client1 & client2

Users: user1/2/3/4 and admin

We want to assign below permissions:

user1 can have an access only to client1 index (both read/write)
user2 can have an access only to client2 index (both read/write)
user3 can have an access only to client1 index (only read)
user4 can have an access only to client2 index (only read)
admin user can have an access to both the indexes (both read/write)

Below are the entries we have made:

file: sg_internal_users.yml

user1:
hash: $2a$12$i9OlhTub5HYc3sgUJD24QeEQPXPCr1CHz8EGB4KEHKZdaq4fWE8iW
#password is: demo1
roles:
   - sg_client1_read
   - sg_client1_write
   
user2:
  hash: $2a$12$Hrzo.FfsyXx6KxhqLZhlPeB62rKlTeBorWnzJCzp7c5HjeLTq07Yy
  #password is: demo2
  roles:
    - sg_client2_read
    - sg_client2_write
   
user3:
  hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
  #password is: demo3
  roles:
   - sg_client1_read

user4:
  hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
  #password is: demo4
  roles:
   - sg_client2_read

admin:
  hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
  #password is: admin
  roles:
   - sg_client1_read
   - sg_client1_write
   - sg_client2_read
   - sg_client2_write

###########################

file: sg_roles.yml

# Read/Monitor/CRUD on all the indices and cluster wide
sg_our_admin:
  cluster:
    - CLUSTER_MONITOR
    - CLUSTER_COMPOSITE_OPS_RO
  indices:
    '*':
      - CRUD

#Read client1 indices only
sg_client1_read:
  cluster:
    - CLUSTER_MONITOR
    - CLUSTER_COMPOSITE_OPS_RO
    - INDICES_MONITOR
  indices:
    '?monitor*':
      '*':
        - INDICES_ALL
    client1:
      '*':
        - INDICES_MONITOR
        - INDICES_ALL
        - RO

#Read client2 indices only
sg_client2_read:
  cluster:
    - CLUSTER_MONITOR
    - CLUSTER_COMPOSITE_OPS_RO
    - INDICES_MONITOR
  indices:
    '?monitor*':
      '*':
        - INDICES_ALL
    client2:
      '*':
        - INDICES_MONITOR
        - INDICES_ALL
        - RO

#Write client1 indices only
sg_client1_write:
  cluster:
    - CLUSTER_MONITOR
    - CLUSTER_COMPOSITE_OPS_RO
    - INDICES_MONITOR
  indices:
    '?monitor*':
      '*':
        - INDICES_ALL
    client1:
      '*':
        - INDICES_MONITOR
        - INDICES_ALL
        - WRITE

#Write client2 indices only
sg_client2_write:
  cluster:
    - CLUSTER_MONITOR
    - CLUSTER_COMPOSITE_OPS_RO
    - INDICES_MONITOR
  indices:
    '?monitor*':
      '*':
        - INDICES_ALL
    client2:
      '*':
        - INDICES_MONITOR
        - INDICES_ALL
        - WRITE

#############################

file: sg_roles_mapping.yml

# Role Mappings

sg_our_admin:
  users:
    - admin

sg_client1_read:
  users:
    - user1
    - user3

sg_client2_read:
  users:
    - user2
    - user4

sg_client1_write:
  users:
    - user1

sg_client2_write:
  users:
    - user2

We reload the SearchGaurd config using sgadmin.sh script and it is loading all the roles and mappings successfully. But the moment we try to curl the specific index with respective username and password we are getting an error as:

type":"security_exception","reason":"no permissions for [indices:monitor/stats]

Though we have provided the roles related to monitor (CLUSTER_MONITOR and INDICES_MONITOR). We are not clear how to achieve this.

Can one illuminate us on this and enlighten us if we are approaching it in wrong manner?

We have couple of doubts that:

* Is there a convention to assign roles with 'sg_' as prefix or we can go by any name?
* What is tenant for and what is its role?

Thank you in adcance!

--
You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com.
To post to this group, send email to search-guard@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/812440ed-c6e0-401e-9423-a2c29bed95e3%40googlegroups.com\.
For more options, visit https://groups.google.com/d/optout\.

3

Can you pls attach all of your sg_*.yml files (as files) and post the curl command you are executing along with the full response

Files attached to this message.

Snapshot:
$ curl -k -u user1:demo1 https://master3:9200/_cat/indices?v

As per the roles we have assigned user1 should have an access (read/write) to client1 index but we are getting below error:

Please review and highlight our mistakes if we are making any.

Thanks for your patience and concern!

sg_internal_users.yml (755 Bytes)

sg_roles.yml (1.25 KB)

sg_roles_mapping.yml (234 Bytes)

···

On Monday, April 23, 2018 at 1:33:02 PM UTC+5:30, Search Guard wrote:

Your questions:

  • Is there a convention to assign roles with ‘sg_’ as prefix or we can go by any name?

can be any name

  • What is tenant for and what is its role?

tenants are a kibana specific thing, i think you can just ignore them at the moment.

see https://docs.search-guard.com/latest/kibana-multi-tenancy#kibana-multitenancy

Am 23.04.2018 um 06:46 schrieb Sahil Modgill modgi...@gmail.com:

Greetings everyone,

We are facing below issues while configuring SearchGaurd.

Environment details:

OS: Ubuntu:14.04

Java; 1.8

ES: 5.6.8

SearchGaurd: 5-5.6.8-19

Cerebro: 0.7.3

Use-case:

Indexes : client1 & client2

Users: user1/2/3/4 and admin

We want to assign below permissions:

user1 can have an access only to client1 index (both read/write)

user2 can have an access only to client2 index (both read/write)

user3 can have an access only to client1 index (only read)

user4 can have an access only to client2 index (only read)

admin user can have an access to both the indexes (both read/write)

Below are the entries we have made:

file: sg_internal_users.yml

user1:

hash: $2a$12$i9OlhTub5HYc3sgUJD24QeEQPXPCr1CHz8EGB4KEHKZdaq4fWE8iW

#password is: demo1

roles:

  • sg_client1_read
  • sg_client1_write

user2:

hash: $2a$12$Hrzo.FfsyXx6KxhqLZhlPeB62rKlTeBorWnzJCzp7c5HjeLTq07Yy

#password is: demo2

roles:

- sg_client2_read

- sg_client2_write

user3:

hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq

#password is: demo3

roles:

  • sg_client1_read

user4:

hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq

#password is: demo4

roles:

  • sg_client2_read

admin:

hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq

#password is: admin

roles:

  • sg_client1_read
  • sg_client1_write
  • sg_client2_read
  • sg_client2_write

###########################

file: sg_roles.yml

Read/Monitor/CRUD on all the indices and cluster wide

sg_our_admin:

cluster:

- CLUSTER_MONITOR

- CLUSTER_COMPOSITE_OPS_RO

indices:

'*':

  - CRUD

#Read client1 indices only

sg_client1_read:

cluster:

- CLUSTER_MONITOR

- CLUSTER_COMPOSITE_OPS_RO

- INDICES_MONITOR

indices:

'?monitor*':

  '*':

    - INDICES_ALL

client1:

  '*':

    - INDICES_MONITOR

    - INDICES_ALL

    - RO

#Read client2 indices only

sg_client2_read:

cluster:

- CLUSTER_MONITOR

- CLUSTER_COMPOSITE_OPS_RO

- INDICES_MONITOR

indices:

'?monitor*':

  '*':

    - INDICES_ALL

client2:

  '*':

    - INDICES_MONITOR

    - INDICES_ALL

    - RO

#Write client1 indices only

sg_client1_write:

cluster:

- CLUSTER_MONITOR

- CLUSTER_COMPOSITE_OPS_RO

- INDICES_MONITOR

indices:

'?monitor*':

  '*':

    - INDICES_ALL

client1:

  '*':

    - INDICES_MONITOR

    - INDICES_ALL

    - WRITE

#Write client2 indices only

sg_client2_write:

cluster:

- CLUSTER_MONITOR

- CLUSTER_COMPOSITE_OPS_RO

- INDICES_MONITOR

indices:

'?monitor*':

  '*':

    - INDICES_ALL

client2:

  '*':

    - INDICES_MONITOR

    - INDICES_ALL

    - WRITE

#############################

file: sg_roles_mapping.yml

Role Mappings

sg_our_admin:

users:

- admin

sg_client1_read:

users:

- user1

- user3

sg_client2_read:

users:

- user2

- user4

sg_client1_write:

users:

- user1

sg_client2_write:

users:

- user2

We reload the SearchGaurd config using sgadmin.sh script and it is loading all the roles and mappings successfully. But the moment we try to curl the specific index with respective username and password we are getting an error as:

type":“security_exception”,“reason”:"no permissions for [indices:monitor/stats]

Though we have provided the roles related to monitor (CLUSTER_MONITOR and INDICES_MONITOR). We are not clear how to achieve this.

Can one illuminate us on this and enlighten us if we are approaching it in wrong manner?

We have couple of doubts that:

  • Is there a convention to assign roles with ‘sg_’ as prefix or we can go by any name?
  • What is tenant for and what is its role?

Thank you in adcance!

–
You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.

To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.

To post to this group, send email to search...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/812440ed-c6e0-401e-9423-a2c29bed95e3%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

4

you missed to add sg_config.yml as well as sg_action_groups.yml. We need them to help you.

···

Am 23.04.2018 um 12:52 schrieb Sahil Modgill <modgill.s30@gmail.com>:

On Monday, April 23, 2018 at 1:33:02 PM UTC+5:30, Search Guard wrote:
Can you pls attach all of your sg_*.yml files (as files) and post the curl command you are executing along with the full response

Files attached to this message.

Snapshot:
$ curl -k -u user1:demo1 https://master3:9200/_cat/indices?v

As per the roles we have assigned user1 should have an access (read/write) to client1 index but we are getting below error:

Please review and highlight our mistakes if we are making any.

Thanks for your patience and concern!

Your questions:
> * Is there a convention to assign roles with 'sg_' as prefix or we can go by any name?

can be any name

> * What is tenant for and what is its role?

tenants are a kibana specific thing, i think you can just ignore them at the moment.
see Kibana Multitenancy | Security for Elasticsearch | Search Guard

> Am 23.04.2018 um 06:46 schrieb Sahil Modgill <modgi...@gmail.com>:
>
> Greetings everyone,
>
> We are facing below issues while configuring SearchGaurd.
>
> Environment details:
>
> OS: Ubuntu:14.04
> Java; 1.8
> ES: 5.6.8
> SearchGaurd: 5-5.6.8-19
> Cerebro: 0.7.3
>
> Use-case:
>
> Indexes : client1 & client2
>
> Users: user1/2/3/4 and admin
>
> We want to assign below permissions:
>
> user1 can have an access only to client1 index (both read/write)
> user2 can have an access only to client2 index (both read/write)
> user3 can have an access only to client1 index (only read)
> user4 can have an access only to client2 index (only read)
> admin user can have an access to both the indexes (both read/write)
>
> Below are the entries we have made:
>
> file: sg_internal_users.yml
>
> user1:
> hash: $2a$12$i9OlhTub5HYc3sgUJD24QeEQPXPCr1CHz8EGB4KEHKZdaq4fWE8iW
> #password is: demo1
> roles:
> - sg_client1_read
> - sg_client1_write
>
> user2:
> hash: $2a$12$Hrzo.FfsyXx6KxhqLZhlPeB62rKlTeBorWnzJCzp7c5HjeLTq07Yy
> #password is: demo2
> roles:
> - sg_client2_read
> - sg_client2_write
>
> user3:
> hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
> #password is: demo3
> roles:
> - sg_client1_read
>
> user4:
> hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
> #password is: demo4
> roles:
> - sg_client2_read
>
> admin:
> hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
> #password is: admin
> roles:
> - sg_client1_read
> - sg_client1_write
> - sg_client2_read
> - sg_client2_write
>
> ###########################
>
> file: sg_roles.yml
>
> # Read/Monitor/CRUD on all the indices and cluster wide
> sg_our_admin:
> cluster:
> - CLUSTER_MONITOR
> - CLUSTER_COMPOSITE_OPS_RO
> indices:
> '*':
> - CRUD
>
> #Read client1 indices only
> sg_client1_read:
> cluster:
> - CLUSTER_MONITOR
> - CLUSTER_COMPOSITE_OPS_RO
> - INDICES_MONITOR
> indices:
> '?monitor*':
> '*':
> - INDICES_ALL
> client1:
> '*':
> - INDICES_MONITOR
> - INDICES_ALL
> - RO
>
> #Read client2 indices only
> sg_client2_read:
> cluster:
> - CLUSTER_MONITOR
> - CLUSTER_COMPOSITE_OPS_RO
> - INDICES_MONITOR
> indices:
> '?monitor*':
> '*':
> - INDICES_ALL
> client2:
> '*':
> - INDICES_MONITOR
> - INDICES_ALL
> - RO
>
> #Write client1 indices only
> sg_client1_write:
> cluster:
> - CLUSTER_MONITOR
> - CLUSTER_COMPOSITE_OPS_RO
> - INDICES_MONITOR
> indices:
> '?monitor*':
> '*':
> - INDICES_ALL
> client1:
> '*':
> - INDICES_MONITOR
> - INDICES_ALL
> - WRITE
>
> #Write client2 indices only
> sg_client2_write:
> cluster:
> - CLUSTER_MONITOR
> - CLUSTER_COMPOSITE_OPS_RO
> - INDICES_MONITOR
> indices:
> '?monitor*':
> '*':
> - INDICES_ALL
> client2:
> '*':
> - INDICES_MONITOR
> - INDICES_ALL
> - WRITE
>
> #############################
>
> file: sg_roles_mapping.yml
>
> # Role Mappings
>
> sg_our_admin:
> users:
> - admin
>
> sg_client1_read:
> users:
> - user1
> - user3
>
> sg_client2_read:
> users:
> - user2
> - user4
>
> sg_client1_write:
> users:
> - user1
>
> sg_client2_write:
> users:
> - user2
>
>
> We reload the SearchGaurd config using sgadmin.sh script and it is loading all the roles and mappings successfully. But the moment we try to curl the specific index with respective username and password we are getting an error as:
>
> type":"security_exception","reason":"no permissions for [indices:monitor/stats]
>
> Though we have provided the roles related to monitor (CLUSTER_MONITOR and INDICES_MONITOR). We are not clear how to achieve this.
>
> Can one illuminate us on this and enlighten us if we are approaching it in wrong manner?
>
> We have couple of doubts that:
>
> * Is there a convention to assign roles with 'sg_' as prefix or we can go by any name?
> * What is tenant for and what is its role?
>
> Thank you in adcance!
>
> --
> You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.
> To post to this group, send email to search...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/812440ed-c6e0-401e-9423-a2c29bed95e3%40googlegroups.com\.
> For more options, visit https://groups.google.com/d/optout\.

--
You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com.
To post to this group, send email to search-guard@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/f525a082-8ff9-4631-ba0f-ad2c2a7da803%40googlegroups.com\.
For more options, visit https://groups.google.com/d/optout\.
<sg_internal_users.yml><sg_roles.yml><sg_roles_mapping.yml>

5

Greetings SearchGaurd,

My apologies for missing out those file. Reason for not sharing because we haven’t modified or made any changes in those files. Do we need to? I might be sound weird but we didn’t find any thing which needs to be changed as relevant to our requriement. This is purely my understanding and I could be wrong on this. Please illuminate me on this.
And, for your reference I have added the respective files.
Thanks!

sg_action_groups.yml (1.47 KB)

sg_config.yml (9.34 KB)

···

On Monday, April 23, 2018 at 7:01:02 PM UTC+5:30, Search Guard wrote:

you missed to add sg_config.yml as well as sg_action_groups.yml. We need them to help you.

Am 23.04.2018 um 12:52 schrieb Sahil Modgill modgi...@gmail.com:

On Monday, April 23, 2018 at 1:33:02 PM UTC+5:30, Search Guard wrote:

Can you pls attach all of your sg_*.yml files (as files) and post the curl command you are executing along with the full response

Files attached to this message.

Snapshot:

$ curl -k -u user1:demo1 https://master3:9200/_cat/indices?v

As per the roles we have assigned user1 should have an access (read/write) to client1 index but we are getting below error:

Please review and highlight our mistakes if we are making any.

Thanks for your patience and concern!

Your questions:

  • Is there a convention to assign roles with ‘sg_’ as prefix or we can go by any name?

can be any name

  • What is tenant for and what is its role?

tenants are a kibana specific thing, i think you can just ignore them at the moment.
see https://docs.search-guard.com/latest/kibana-multi-tenancy#kibana-multitenancy

Am 23.04.2018 um 06:46 schrieb Sahil Modgill modgi...@gmail.com:

Greetings everyone,

We are facing below issues while configuring SearchGaurd.

Environment details:

OS: Ubuntu:14.04
Java; 1.8
ES: 5.6.8
SearchGaurd: 5-5.6.8-19
Cerebro: 0.7.3

Use-case:

Indexes : client1 & client2

Users: user1/2/3/4 and admin

We want to assign below permissions:

user1 can have an access only to client1 index (both read/write)
user2 can have an access only to client2 index (both read/write)
user3 can have an access only to client1 index (only read)
user4 can have an access only to client2 index (only read)
admin user can have an access to both the indexes (both read/write)

Below are the entries we have made:

file: sg_internal_users.yml

user1:
hash: $2a$12$i9OlhTub5HYc3sgUJD24QeEQPXPCr1CHz8EGB4KEHKZdaq4fWE8iW
#password is: demo1
roles:

  • sg_client1_read
  • sg_client1_write

user2:
hash: $2a$12$Hrzo.FfsyXx6KxhqLZhlPeB62rKlTeBorWnzJCzp7c5HjeLTq07Yy
#password is: demo2
roles:
- sg_client2_read
- sg_client2_write

user3:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: demo3
roles:

  • sg_client1_read

user4:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: demo4
roles:

  • sg_client2_read

admin:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: admin
roles:

  • sg_client1_read
  • sg_client1_write
  • sg_client2_read
  • sg_client2_write

###########################

file: sg_roles.yml

Read/Monitor/CRUD on all the indices and cluster wide

sg_our_admin:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
indices:
‘*’:
- CRUD

#Read client1 indices only
sg_client1_read:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client1:
'’:
- INDICES_MONITOR
- INDICES_ALL
- RO

#Read client2 indices only
sg_client2_read:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client2:
'’:
- INDICES_MONITOR
- INDICES_ALL
- RO

#Write client1 indices only
sg_client1_write:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client1:
'’:
- INDICES_MONITOR
- INDICES_ALL
- WRITE

#Write client2 indices only
sg_client2_write:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client2:
'’:
- INDICES_MONITOR
- INDICES_ALL
- WRITE

#############################

file: sg_roles_mapping.yml

Role Mappings

sg_our_admin:
users:
- admin

sg_client1_read:
users:
- user1
- user3

sg_client2_read:
users:
- user2
- user4

sg_client1_write:
users:
- user1

sg_client2_write:
users:
- user2

We reload the SearchGaurd config using sgadmin.sh script and it is loading all the roles and mappings successfully. But the moment we try to curl the specific index with respective username and password we are getting an error as:

type":“security_exception”,“reason”:"no permissions for [indices:monitor/stats]

Though we have provided the roles related to monitor (CLUSTER_MONITOR and INDICES_MONITOR). We are not clear how to achieve this.

Can one illuminate us on this and enlighten us if we are approaching it in wrong manner?

We have couple of doubts that:

  • Is there a convention to assign roles with ‘sg_’ as prefix or we can go by any name?
  • What is tenant for and what is its role?

Thank you in adcance!

–
You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.
To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.
To post to this group, send email to search...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/812440ed-c6e0-401e-9423-a2c29bed95e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.

To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.

To post to this group, send email to search...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/f525a082-8ff9-4631-ba0f-ad2c2a7da803%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

<sg_internal_users.yml><sg_roles.yml><sg_roles_mapping.yml>

6

Greetings SearchGaurd,

Have you had time to look into the configs which I have shared? Please let us know.

Thank you for time and concern!

···

On Tuesday, April 24, 2018 at 9:56:48 AM UTC+5:30, Sahil Modgill wrote:

Greetings SearchGaurd,

My apologies for missing out those file. Reason for not sharing because we haven’t modified or made any changes in those files. Do we need to? I might be sound weird but we didn’t find any thing which needs to be changed as relevant to our requriement. This is purely my understanding and I could be wrong on this. Please illuminate me on this.
And, for your reference I have added the respective files.
Thanks!

On Monday, April 23, 2018 at 7:01:02 PM UTC+5:30, Search Guard wrote:

you missed to add sg_config.yml as well as sg_action_groups.yml. We need them to help you.

Am 23.04.2018 um 12:52 schrieb Sahil Modgill modgi...@gmail.com:

On Monday, April 23, 2018 at 1:33:02 PM UTC+5:30, Search Guard wrote:

Can you pls attach all of your sg_*.yml files (as files) and post the curl command you are executing along with the full response

Files attached to this message.

Snapshot:

$ curl -k -u user1:demo1 https://master3:9200/_cat/indices?v

As per the roles we have assigned user1 should have an access (read/write) to client1 index but we are getting below error:

Please review and highlight our mistakes if we are making any.

Thanks for your patience and concern!

Your questions:

  • Is there a convention to assign roles with ‘sg_’ as prefix or we can go by any name?

can be any name

  • What is tenant for and what is its role?

tenants are a kibana specific thing, i think you can just ignore them at the moment.
see https://docs.search-guard.com/latest/kibana-multi-tenancy#kibana-multitenancy

Am 23.04.2018 um 06:46 schrieb Sahil Modgill modgi...@gmail.com:

Greetings everyone,

We are facing below issues while configuring SearchGaurd.

Environment details:

OS: Ubuntu:14.04
Java; 1.8
ES: 5.6.8
SearchGaurd: 5-5.6.8-19
Cerebro: 0.7.3

Use-case:

Indexes : client1 & client2

Users: user1/2/3/4 and admin

We want to assign below permissions:

user1 can have an access only to client1 index (both read/write)
user2 can have an access only to client2 index (both read/write)
user3 can have an access only to client1 index (only read)
user4 can have an access only to client2 index (only read)
admin user can have an access to both the indexes (both read/write)

Below are the entries we have made:

file: sg_internal_users.yml

user1:
hash: $2a$12$i9OlhTub5HYc3sgUJD24QeEQPXPCr1CHz8EGB4KEHKZdaq4fWE8iW
#password is: demo1
roles:

  • sg_client1_read
  • sg_client1_write

user2:
hash: $2a$12$Hrzo.FfsyXx6KxhqLZhlPeB62rKlTeBorWnzJCzp7c5HjeLTq07Yy
#password is: demo2
roles:
- sg_client2_read
- sg_client2_write

user3:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: demo3
roles:

  • sg_client1_read

user4:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: demo4
roles:

  • sg_client2_read

admin:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: admin
roles:

  • sg_client1_read
  • sg_client1_write
  • sg_client2_read
  • sg_client2_write

###########################

file: sg_roles.yml

Read/Monitor/CRUD on all the indices and cluster wide

sg_our_admin:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
indices:
‘*’:
- CRUD

#Read client1 indices only
sg_client1_read:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client1:
'’:
- INDICES_MONITOR
- INDICES_ALL
- RO

#Read client2 indices only
sg_client2_read:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client2:
'’:
- INDICES_MONITOR
- INDICES_ALL
- RO

#Write client1 indices only
sg_client1_write:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client1:
'’:
- INDICES_MONITOR
- INDICES_ALL
- WRITE

#Write client2 indices only
sg_client2_write:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client2:
'’:
- INDICES_MONITOR
- INDICES_ALL
- WRITE

#############################

file: sg_roles_mapping.yml

Role Mappings

sg_our_admin:
users:
- admin

sg_client1_read:
users:
- user1
- user3

sg_client2_read:
users:
- user2
- user4

sg_client1_write:
users:
- user1

sg_client2_write:
users:
- user2

We reload the SearchGaurd config using sgadmin.sh script and it is loading all the roles and mappings successfully. But the moment we try to curl the specific index with respective username and password we are getting an error as:

type":“security_exception”,“reason”:"no permissions for [indices:monitor/stats]

Though we have provided the roles related to monitor (CLUSTER_MONITOR and INDICES_MONITOR). We are not clear how to achieve this.

Can one illuminate us on this and enlighten us if we are approaching it in wrong manner?

We have couple of doubts that:

  • Is there a convention to assign roles with ‘sg_’ as prefix or we can go by any name?
  • What is tenant for and what is its role?

Thank you in adcance!

–
You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.
To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.
To post to this group, send email to search...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/812440ed-c6e0-401e-9423-a2c29bed95e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.

To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.

To post to this group, send email to search...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/f525a082-8ff9-4631-ba0f-ad2c2a7da803%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

<sg_internal_users.yml><sg_roles.yml><sg_roles_mapping.yml>

7

Just to make 100% sure - Kibana is not involved here, right?

Next, can you please try to access this endpoint with your user1 / demo1 and post the output here:

https://:9200/_searchguard/authinfo

Among other information this will print out all SG roles assigned to user1, so we can be 100% sure what roles the user hase.

Next, when you execute the failing curl command, can you please look at the Elasticsearch logs. You should find something like:

No index-level perm match for …

``

Or:

No cluser-level perm match for …

``

This will shed some light on what actual permission is missing, and on what level.

Thanks!

···

On Tuesday, April 24, 2018 at 10:33:15 PM UTC-7, Sahil Modgill wrote:

Greetings SearchGaurd,

Have you had time to look into the configs which I have shared? Please let us know.

Thank you for time and concern!

On Tuesday, April 24, 2018 at 9:56:48 AM UTC+5:30, Sahil Modgill wrote:

Greetings SearchGaurd,

My apologies for missing out those file. Reason for not sharing because we haven’t modified or made any changes in those files. Do we need to? I might be sound weird but we didn’t find any thing which needs to be changed as relevant to our requriement. This is purely my understanding and I could be wrong on this. Please illuminate me on this.
And, for your reference I have added the respective files.
Thanks!

On Monday, April 23, 2018 at 7:01:02 PM UTC+5:30, Search Guard wrote:

you missed to add sg_config.yml as well as sg_action_groups.yml. We need them to help you.

Am 23.04.2018 um 12:52 schrieb Sahil Modgill modgi...@gmail.com:

On Monday, April 23, 2018 at 1:33:02 PM UTC+5:30, Search Guard wrote:

Can you pls attach all of your sg_*.yml files (as files) and post the curl command you are executing along with the full response

Files attached to this message.

Snapshot:

$ curl -k -u user1:demo1 https://master3:9200/_cat/indices?v

As per the roles we have assigned user1 should have an access (read/write) to client1 index but we are getting below error:

Please review and highlight our mistakes if we are making any.

Thanks for your patience and concern!

Your questions:

  • Is there a convention to assign roles with ‘sg_’ as prefix or we can go by any name?

can be any name

  • What is tenant for and what is its role?

tenants are a kibana specific thing, i think you can just ignore them at the moment.
see https://docs.search-guard.com/latest/kibana-multi-tenancy#kibana-multitenancy

Am 23.04.2018 um 06:46 schrieb Sahil Modgill modgi...@gmail.com:

Greetings everyone,

We are facing below issues while configuring SearchGaurd.

Environment details:

OS: Ubuntu:14.04
Java; 1.8
ES: 5.6.8
SearchGaurd: 5-5.6.8-19
Cerebro: 0.7.3

Use-case:

Indexes : client1 & client2

Users: user1/2/3/4 and admin

We want to assign below permissions:

user1 can have an access only to client1 index (both read/write)
user2 can have an access only to client2 index (both read/write)
user3 can have an access only to client1 index (only read)
user4 can have an access only to client2 index (only read)
admin user can have an access to both the indexes (both read/write)

Below are the entries we have made:

file: sg_internal_users.yml

user1:
hash: $2a$12$i9OlhTub5HYc3sgUJD24QeEQPXPCr1CHz8EGB4KEHKZdaq4fWE8iW
#password is: demo1
roles:

  • sg_client1_read
  • sg_client1_write

user2:
hash: $2a$12$Hrzo.FfsyXx6KxhqLZhlPeB62rKlTeBorWnzJCzp7c5HjeLTq07Yy
#password is: demo2
roles:
- sg_client2_read
- sg_client2_write

user3:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: demo3
roles:

  • sg_client1_read

user4:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: demo4
roles:

  • sg_client2_read

admin:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: admin
roles:

  • sg_client1_read
  • sg_client1_write
  • sg_client2_read
  • sg_client2_write

###########################

file: sg_roles.yml

Read/Monitor/CRUD on all the indices and cluster wide

sg_our_admin:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
indices:
‘*’:
- CRUD

#Read client1 indices only
sg_client1_read:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client1:
'’:
- INDICES_MONITOR
- INDICES_ALL
- RO

#Read client2 indices only
sg_client2_read:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client2:
'’:
- INDICES_MONITOR
- INDICES_ALL
- RO

#Write client1 indices only
sg_client1_write:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client1:
'’:
- INDICES_MONITOR
- INDICES_ALL
- WRITE

#Write client2 indices only
sg_client2_write:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client2:
'’:
- INDICES_MONITOR
- INDICES_ALL
- WRITE

#############################

file: sg_roles_mapping.yml

Role Mappings

sg_our_admin:
users:
- admin

sg_client1_read:
users:
- user1
- user3

sg_client2_read:
users:
- user2
- user4

sg_client1_write:
users:
- user1

sg_client2_write:
users:
- user2

We reload the SearchGaurd config using sgadmin.sh script and it is loading all the roles and mappings successfully. But the moment we try to curl the specific index with respective username and password we are getting an error as:

type":“security_exception”,“reason”:"no permissions for [indices:monitor/stats]

Though we have provided the roles related to monitor (CLUSTER_MONITOR and INDICES_MONITOR). We are not clear how to achieve this.

Can one illuminate us on this and enlighten us if we are approaching it in wrong manner?

We have couple of doubts that:

  • Is there a convention to assign roles with ‘sg_’ as prefix or we can go by any name?
  • What is tenant for and what is its role?

Thank you in adcance!

–
You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.
To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.
To post to this group, send email to search...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/812440ed-c6e0-401e-9423-a2c29bed95e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.

To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.

To post to this group, send email to search...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/f525a082-8ff9-4631-ba0f-ad2c2a7da803%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

<sg_internal_users.yml><sg_roles.yml><sg_roles_mapping.yml>

8

Hello,

I do not know wy my reply has been deleted. Not once but twice.

Is this the problem I am facing or a others are also facing? I only inserted the images (as snapshots) to my reply. But my reply has been deleted. :frowning:

Please update me.

Thanks!

···

On Monday, April 23, 2018 at 10:16:30 AM UTC+5:30, Sahil Modgill wrote:

Greetings everyone,

We are facing below issues while configuring SearchGaurd.

Environment details:

OS: Ubuntu:14.04
Java; 1.8
ES: 5.6.8
SearchGaurd: 5-5.6.8-19
Cerebro: 0.7.3

Use-case:

Indexes : client1 & client2

Users: user1/2/3/4 and admin

We want to assign below permissions:

user1 can have an access only to client1 index (both read/write)
user2 can have an access only to client2 index (both read/write)
user3 can have an access only to client1 index (only read)
user4 can have an access only to client2 index (only read)
admin user can have an access to both the indexes (both read/write)

Below are the entries we have made:

file: sg_internal_users.yml

user1:
hash: $2a$12$i9OlhTub5HYc3sgUJD24QeEQPXPCr1CHz8EGB4KEHKZdaq4fWE8iW
#password is: demo1
roles:

  • sg_client1_read
  • sg_client1_write

user2:
hash: $2a$12$Hrzo.FfsyXx6KxhqLZhlPeB62rKlTeBorWnzJCzp7c5HjeLTq07Yy
#password is: demo2
roles:
- sg_client2_read
- sg_client2_write

user3:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: demo3
roles:

  • sg_client1_read

user4:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: demo4
roles:

  • sg_client2_read

admin:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: admin
roles:

  • sg_client1_read
  • sg_client1_write
  • sg_client2_read
  • sg_client2_write

###########################

file: sg_roles.yml

Read/Monitor/CRUD on all the indices and cluster wide

sg_our_admin:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
indices:
‘*’:
- CRUD

#Read client1 indices only
sg_client1_read:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client1:
'’:
- INDICES_MONITOR
- INDICES_ALL
- RO

#Read client2 indices only
sg_client2_read:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client2:
'’:
- INDICES_MONITOR
- INDICES_ALL
- RO

#Write client1 indices only
sg_client1_write:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client1:
'’:
- INDICES_MONITOR
- INDICES_ALL
- WRITE

#Write client2 indices only
sg_client2_write:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client2:
'’:
- INDICES_MONITOR
- INDICES_ALL
- WRITE

#############################

file: sg_roles_mapping.yml

Role Mappings

sg_our_admin:
users:
- admin

sg_client1_read:
users:
- user1
- user3

sg_client2_read:
users:
- user2
- user4

sg_client1_write:
users:
- user1

sg_client2_write:
users:
- user2

We reload the SearchGaurd config using sgadmin.sh script and it is loading all the roles and mappings successfully. But the moment we try to curl the specific index with respective username and password we are getting an error as:

type":“security_exception”,“reason”:"no permissions for [indices:monitor/stats]

Though we have provided the roles related to monitor (CLUSTER_MONITOR and INDICES_MONITOR). We are not clear how to achieve this.

Can one illuminate us on this and enlighten us if we are approaching it in wrong manner?

We have couple of doubts that:

  • Is there a convention to assign roles with ‘sg_’ as prefix or we can go by any name?
  • What is tenant for and what is its role?

Thank you in adcance!

9

we do not delete messages (unless they are offending or otherwise illegal) so i think it must have been you or google probably

If you still have trouble you can also mail us directly, see floragunncom (Search Guard) · GitHub for the email address or open a issue on github.

···

On Wednesday, 25 April 2018 13:43:18 UTC+2, Sahil Modgill wrote:

Hello,

I do not know wy my reply has been deleted. Not once but twice.

Is this the problem I am facing or a others are also facing? I only inserted the images (as snapshots) to my reply. But my reply has been deleted. :frowning:

Please update me.

Thanks!

On Monday, April 23, 2018 at 10:16:30 AM UTC+5:30, Sahil Modgill wrote:

Greetings everyone,

We are facing below issues while configuring SearchGaurd.

Environment details:

OS: Ubuntu:14.04
Java; 1.8
ES: 5.6.8
SearchGaurd: 5-5.6.8-19
Cerebro: 0.7.3

Use-case:

Indexes : client1 & client2

Users: user1/2/3/4 and admin

We want to assign below permissions:

user1 can have an access only to client1 index (both read/write)
user2 can have an access only to client2 index (both read/write)
user3 can have an access only to client1 index (only read)
user4 can have an access only to client2 index (only read)
admin user can have an access to both the indexes (both read/write)

Below are the entries we have made:

file: sg_internal_users.yml

user1:
hash: $2a$12$i9OlhTub5HYc3sgUJD24QeEQPXPCr1CHz8EGB4KEHKZdaq4fWE8iW
#password is: demo1
roles:

  • sg_client1_read
  • sg_client1_write

user2:
hash: $2a$12$Hrzo.FfsyXx6KxhqLZhlPeB62rKlTeBorWnzJCzp7c5HjeLTq07Yy
#password is: demo2
roles:
- sg_client2_read
- sg_client2_write

user3:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: demo3
roles:

  • sg_client1_read

user4:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: demo4
roles:

  • sg_client2_read

admin:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: admin
roles:

  • sg_client1_read
  • sg_client1_write
  • sg_client2_read
  • sg_client2_write

###########################

file: sg_roles.yml

Read/Monitor/CRUD on all the indices and cluster wide

sg_our_admin:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
indices:
‘*’:
- CRUD

#Read client1 indices only
sg_client1_read:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client1:
'’:
- INDICES_MONITOR
- INDICES_ALL
- RO

#Read client2 indices only
sg_client2_read:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client2:
'’:
- INDICES_MONITOR
- INDICES_ALL
- RO

#Write client1 indices only
sg_client1_write:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client1:
'’:
- INDICES_MONITOR
- INDICES_ALL
- WRITE

#Write client2 indices only
sg_client2_write:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client2:
'’:
- INDICES_MONITOR
- INDICES_ALL
- WRITE

#############################

file: sg_roles_mapping.yml

Role Mappings

sg_our_admin:
users:
- admin

sg_client1_read:
users:
- user1
- user3

sg_client2_read:
users:
- user2
- user4

sg_client1_write:
users:
- user1

sg_client2_write:
users:
- user2

We reload the SearchGaurd config using sgadmin.sh script and it is loading all the roles and mappings successfully. But the moment we try to curl the specific index with respective username and password we are getting an error as:

type":“security_exception”,“reason”:"no permissions for [indices:monitor/stats]

Though we have provided the roles related to monitor (CLUSTER_MONITOR and INDICES_MONITOR). We are not clear how to achieve this.

Can one illuminate us on this and enlighten us if we are approaching it in wrong manner?

We have couple of doubts that:

  • Is there a convention to assign roles with ‘sg_’ as prefix or we can go by any name?
  • What is tenant for and what is its role?

Thank you in adcance!

10

looks like your “deleted” post were categorized as spam by google

···

On Wednesday, 25 April 2018 13:43:18 UTC+2, Sahil Modgill wrote:

Hello,

I do not know wy my reply has been deleted. Not once but twice.

Is this the problem I am facing or a others are also facing? I only inserted the images (as snapshots) to my reply. But my reply has been deleted. :frowning:

Please update me.

Thanks!

On Monday, April 23, 2018 at 10:16:30 AM UTC+5:30, Sahil Modgill wrote:

Greetings everyone,

We are facing below issues while configuring SearchGaurd.

Environment details:

OS: Ubuntu:14.04
Java; 1.8
ES: 5.6.8
SearchGaurd: 5-5.6.8-19
Cerebro: 0.7.3

Use-case:

Indexes : client1 & client2

Users: user1/2/3/4 and admin

We want to assign below permissions:

user1 can have an access only to client1 index (both read/write)
user2 can have an access only to client2 index (both read/write)
user3 can have an access only to client1 index (only read)
user4 can have an access only to client2 index (only read)
admin user can have an access to both the indexes (both read/write)

Below are the entries we have made:

file: sg_internal_users.yml

user1:
hash: $2a$12$i9OlhTub5HYc3sgUJD24QeEQPXPCr1CHz8EGB4KEHKZdaq4fWE8iW
#password is: demo1
roles:

  • sg_client1_read
  • sg_client1_write

user2:
hash: $2a$12$Hrzo.FfsyXx6KxhqLZhlPeB62rKlTeBorWnzJCzp7c5HjeLTq07Yy
#password is: demo2
roles:
- sg_client2_read
- sg_client2_write

user3:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: demo3
roles:

  • sg_client1_read

user4:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: demo4
roles:

  • sg_client2_read

admin:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: admin
roles:

  • sg_client1_read
  • sg_client1_write
  • sg_client2_read
  • sg_client2_write

###########################

file: sg_roles.yml

Read/Monitor/CRUD on all the indices and cluster wide

sg_our_admin:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
indices:
‘*’:
- CRUD

#Read client1 indices only
sg_client1_read:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client1:
'’:
- INDICES_MONITOR
- INDICES_ALL
- RO

#Read client2 indices only
sg_client2_read:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client2:
'’:
- INDICES_MONITOR
- INDICES_ALL
- RO

#Write client1 indices only
sg_client1_write:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client1:
'’:
- INDICES_MONITOR
- INDICES_ALL
- WRITE

#Write client2 indices only
sg_client2_write:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client2:
'’:
- INDICES_MONITOR
- INDICES_ALL
- WRITE

#############################

file: sg_roles_mapping.yml

Role Mappings

sg_our_admin:
users:
- admin

sg_client1_read:
users:
- user1
- user3

sg_client2_read:
users:
- user2
- user4

sg_client1_write:
users:
- user1

sg_client2_write:
users:
- user2

We reload the SearchGaurd config using sgadmin.sh script and it is loading all the roles and mappings successfully. But the moment we try to curl the specific index with respective username and password we are getting an error as:

type":“security_exception”,“reason”:"no permissions for [indices:monitor/stats]

Though we have provided the roles related to monitor (CLUSTER_MONITOR and INDICES_MONITOR). We are not clear how to achieve this.

Can one illuminate us on this and enlighten us if we are approaching it in wrong manner?

We have couple of doubts that:

  • Is there a convention to assign roles with ‘sg_’ as prefix or we can go by any name?
  • What is tenant for and what is its role?

Thank you in adcance!

11

Probably Google is the culprit behind this and considering my messages as SPAM.

My apologies for that!

···

On Wednesday, April 25, 2018 at 5:55:13 PM UTC+5:30, Search Guard wrote:

looks like your “deleted” post were categorized as spam by google

On Wednesday, 25 April 2018 13:43:18 UTC+2, Sahil Modgill wrote:

Hello,

I do not know wy my reply has been deleted. Not once but twice.

Is this the problem I am facing or a others are also facing? I only inserted the images (as snapshots) to my reply. But my reply has been deleted. :frowning:

Please update me.

Thanks!

On Monday, April 23, 2018 at 10:16:30 AM UTC+5:30, Sahil Modgill wrote:

Greetings everyone,

We are facing below issues while configuring SearchGaurd.

Environment details:

OS: Ubuntu:14.04
Java; 1.8
ES: 5.6.8
SearchGaurd: 5-5.6.8-19
Cerebro: 0.7.3

Use-case:

Indexes : client1 & client2

Users: user1/2/3/4 and admin

We want to assign below permissions:

user1 can have an access only to client1 index (both read/write)
user2 can have an access only to client2 index (both read/write)
user3 can have an access only to client1 index (only read)
user4 can have an access only to client2 index (only read)
admin user can have an access to both the indexes (both read/write)

Below are the entries we have made:

file: sg_internal_users.yml

user1:
hash: $2a$12$i9OlhTub5HYc3sgUJD24QeEQPXPCr1CHz8EGB4KEHKZdaq4fWE8iW
#password is: demo1
roles:

  • sg_client1_read
  • sg_client1_write

user2:
hash: $2a$12$Hrzo.FfsyXx6KxhqLZhlPeB62rKlTeBorWnzJCzp7c5HjeLTq07Yy
#password is: demo2
roles:
- sg_client2_read
- sg_client2_write

user3:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: demo3
roles:

  • sg_client1_read

user4:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: demo4
roles:

  • sg_client2_read

admin:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: admin
roles:

  • sg_client1_read
  • sg_client1_write
  • sg_client2_read
  • sg_client2_write

###########################

file: sg_roles.yml

Read/Monitor/CRUD on all the indices and cluster wide

sg_our_admin:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
indices:
‘*’:
- CRUD

#Read client1 indices only
sg_client1_read:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client1:
'’:
- INDICES_MONITOR
- INDICES_ALL
- RO

#Read client2 indices only
sg_client2_read:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client2:
'’:
- INDICES_MONITOR
- INDICES_ALL
- RO

#Write client1 indices only
sg_client1_write:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client1:
'’:
- INDICES_MONITOR
- INDICES_ALL
- WRITE

#Write client2 indices only
sg_client2_write:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client2:
'’:
- INDICES_MONITOR
- INDICES_ALL
- WRITE

#############################

file: sg_roles_mapping.yml

Role Mappings

sg_our_admin:
users:
- admin

sg_client1_read:
users:
- user1
- user3

sg_client2_read:
users:
- user2
- user4

sg_client1_write:
users:
- user1

sg_client2_write:
users:
- user2

We reload the SearchGaurd config using sgadmin.sh script and it is loading all the roles and mappings successfully. But the moment we try to curl the specific index with respective username and password we are getting an error as:

type":“security_exception”,“reason”:"no permissions for [indices:monitor/stats]

Though we have provided the roles related to monitor (CLUSTER_MONITOR and INDICES_MONITOR). We are not clear how to achieve this.

Can one illuminate us on this and enlighten us if we are approaching it in wrong manner?

We have couple of doubts that:

  • Is there a convention to assign roles with ‘sg_’ as prefix or we can go by any name?
  • What is tenant for and what is its role?

Thank you in adcance!

12

Just to make 100% sure - Kibana is not involved here, right?

No. Kibana is not involved.

Next, can you please try to access this endpoint with your user1 / demo1 and post the output here:

https://:9200/_searchguard/authinfo

Among other information this will print out all SG roles assigned to user1, so we can be 100% sure what roles the user hase.

Next, when you execute the failing curl command, can you please look at the Elasticsearch logs. You should find something like:

No index-level perm match for …

``

Or:

No cluser-level perm match for …

``

This will shed some light on what actual permission is missing, and on what level.

I executed the curl command but I didn’t find any thing closely related to the above error in ES logs.
Can you please validate our configs and try to re-produce the use-case (simple ones like ours) and if everything works fine then we can write a small doc on the same for newbies?
Please inform us.
Thanks

···

On Wednesday, April 25, 2018 at 11:35:48 AM UTC+5:30, Jochen Kressin wrote:

Thanks!

On Tuesday, April 24, 2018 at 10:33:15 PM UTC-7, Sahil Modgill wrote:

Greetings SearchGaurd,

Have you had time to look into the configs which I have shared? Please let us know.

Thank you for time and concern!

On Tuesday, April 24, 2018 at 9:56:48 AM UTC+5:30, Sahil Modgill wrote:

Greetings SearchGaurd,

My apologies for missing out those file. Reason for not sharing because we haven’t modified or made any changes in those files. Do we need to? I might be sound weird but we didn’t find any thing which needs to be changed as relevant to our requriement. This is purely my understanding and I could be wrong on this. Please illuminate me on this.
And, for your reference I have added the respective files.
Thanks!

On Monday, April 23, 2018 at 7:01:02 PM UTC+5:30, Search Guard wrote:

you missed to add sg_config.yml as well as sg_action_groups.yml. We need them to help you.

Am 23.04.2018 um 12:52 schrieb Sahil Modgill modgi...@gmail.com:

On Monday, April 23, 2018 at 1:33:02 PM UTC+5:30, Search Guard wrote:

Can you pls attach all of your sg_*.yml files (as files) and post the curl command you are executing along with the full response

Files attached to this message.

Snapshot:

$ curl -k -u user1:demo1 https://master3:9200/_cat/indices?v

As per the roles we have assigned user1 should have an access (read/write) to client1 index but we are getting below error:

Please review and highlight our mistakes if we are making any.

Thanks for your patience and concern!

Your questions:

  • Is there a convention to assign roles with ‘sg_’ as prefix or we can go by any name?

can be any name

  • What is tenant for and what is its role?

tenants are a kibana specific thing, i think you can just ignore them at the moment.
see https://docs.search-guard.com/latest/kibana-multi-tenancy#kibana-multitenancy

Am 23.04.2018 um 06:46 schrieb Sahil Modgill modgi...@gmail.com:

Greetings everyone,

We are facing below issues while configuring SearchGaurd.

Environment details:

OS: Ubuntu:14.04
Java; 1.8
ES: 5.6.8
SearchGaurd: 5-5.6.8-19
Cerebro: 0.7.3

Use-case:

Indexes : client1 & client2

Users: user1/2/3/4 and admin

We want to assign below permissions:

user1 can have an access only to client1 index (both read/write)
user2 can have an access only to client2 index (both read/write)
user3 can have an access only to client1 index (only read)
user4 can have an access only to client2 index (only read)
admin user can have an access to both the indexes (both read/write)

Below are the entries we have made:

file: sg_internal_users.yml

user1:
hash: $2a$12$i9OlhTub5HYc3sgUJD24QeEQPXPCr1CHz8EGB4KEHKZdaq4fWE8iW
#password is: demo1
roles:

  • sg_client1_read
  • sg_client1_write

user2:
hash: $2a$12$Hrzo.FfsyXx6KxhqLZhlPeB62rKlTeBorWnzJCzp7c5HjeLTq07Yy
#password is: demo2
roles:
- sg_client2_read
- sg_client2_write

user3:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: demo3
roles:

  • sg_client1_read

user4:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: demo4
roles:

  • sg_client2_read

admin:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: admin
roles:

  • sg_client1_read
  • sg_client1_write
  • sg_client2_read
  • sg_client2_write

###########################

file: sg_roles.yml

Read/Monitor/CRUD on all the indices and cluster wide

sg_our_admin:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
indices:
‘*’:
- CRUD

#Read client1 indices only
sg_client1_read:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client1:
'’:
- INDICES_MONITOR
- INDICES_ALL
- RO

#Read client2 indices only
sg_client2_read:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client2:
'’:
- INDICES_MONITOR
- INDICES_ALL
- RO

#Write client1 indices only
sg_client1_write:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client1:
'’:
- INDICES_MONITOR
- INDICES_ALL
- WRITE

#Write client2 indices only
sg_client2_write:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client2:
'’:
- INDICES_MONITOR
- INDICES_ALL
- WRITE

#############################

file: sg_roles_mapping.yml

Role Mappings

sg_our_admin:
users:
- admin

sg_client1_read:
users:
- user1
- user3

sg_client2_read:
users:
- user2
- user4

sg_client1_write:
users:
- user1

sg_client2_write:
users:
- user2

We reload the SearchGaurd config using sgadmin.sh script and it is loading all the roles and mappings successfully. But the moment we try to curl the specific index with respective username and password we are getting an error as:

type":“security_exception”,“reason”:"no permissions for [indices:monitor/stats]

Though we have provided the roles related to monitor (CLUSTER_MONITOR and INDICES_MONITOR). We are not clear how to achieve this.

Can one illuminate us on this and enlighten us if we are approaching it in wrong manner?

We have couple of doubts that:

  • Is there a convention to assign roles with ‘sg_’ as prefix or we can go by any name?
  • What is tenant for and what is its role?

Thank you in adcance!

–
You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.
To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.
To post to this group, send email to search...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/812440ed-c6e0-401e-9423-a2c29bed95e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.

To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.

To post to this group, send email to search...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/f525a082-8ff9-4631-ba0f-ad2c2a7da803%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

<sg_internal_users.yml><sg_roles.yml><sg_roles_mapping.yml>

13

can you pls post the contents of the missing screenshots as text?
(or as links to a image hosting service)

seems inline pics are are spam indicator for google here

···

On Wednesday, 25 April 2018 14:29:47 UTC+2, Sahil Sharma wrote:

On Wednesday, April 25, 2018 at 11:35:48 AM UTC+5:30, Jochen Kressin wrote:

Just to make 100% sure - Kibana is not involved here, right?

No. Kibana is not involved.

Next, can you please try to access this endpoint with your user1 / demo1 and post the output here:

https://:9200/_searchguard/authinfo

Among other information this will print out all SG roles assigned to user1, so we can be 100% sure what roles the user hase.

Next, when you execute the failing curl command, can you please look at the Elasticsearch logs. You should find something like:

No index-level perm match for …

``

Or:

No cluser-level perm match for …

``

This will shed some light on what actual permission is missing, and on what level.

I executed the curl command but I didn’t find any thing closely related to the above error in ES logs.
Can you please validate our configs and try to re-produce the use-case (simple ones like ours) and if everything works fine then we can write a small doc on the same for newbies?
Please inform us.
Thanks

Thanks!

On Tuesday, April 24, 2018 at 10:33:15 PM UTC-7, Sahil Modgill wrote:

Greetings SearchGaurd,

Have you had time to look into the configs which I have shared? Please let us know.

Thank you for time and concern!

On Tuesday, April 24, 2018 at 9:56:48 AM UTC+5:30, Sahil Modgill wrote:

Greetings SearchGaurd,

My apologies for missing out those file. Reason for not sharing because we haven’t modified or made any changes in those files. Do we need to? I might be sound weird but we didn’t find any thing which needs to be changed as relevant to our requriement. This is purely my understanding and I could be wrong on this. Please illuminate me on this.
And, for your reference I have added the respective files.
Thanks!

On Monday, April 23, 2018 at 7:01:02 PM UTC+5:30, Search Guard wrote:

you missed to add sg_config.yml as well as sg_action_groups.yml. We need them to help you.

Am 23.04.2018 um 12:52 schrieb Sahil Modgill modgi...@gmail.com:

On Monday, April 23, 2018 at 1:33:02 PM UTC+5:30, Search Guard wrote:

Can you pls attach all of your sg_*.yml files (as files) and post the curl command you are executing along with the full response

Files attached to this message.

Snapshot:

$ curl -k -u user1:demo1 https://master3:9200/_cat/indices?v

As per the roles we have assigned user1 should have an access (read/write) to client1 index but we are getting below error:

Please review and highlight our mistakes if we are making any.

Thanks for your patience and concern!

Your questions:

  • Is there a convention to assign roles with ‘sg_’ as prefix or we can go by any name?

can be any name

  • What is tenant for and what is its role?

tenants are a kibana specific thing, i think you can just ignore them at the moment.
see https://docs.search-guard.com/latest/kibana-multi-tenancy#kibana-multitenancy

Am 23.04.2018 um 06:46 schrieb Sahil Modgill modgi...@gmail.com:

Greetings everyone,

We are facing below issues while configuring SearchGaurd.

Environment details:

OS: Ubuntu:14.04
Java; 1.8
ES: 5.6.8
SearchGaurd: 5-5.6.8-19
Cerebro: 0.7.3

Use-case:

Indexes : client1 & client2

Users: user1/2/3/4 and admin

We want to assign below permissions:

user1 can have an access only to client1 index (both read/write)
user2 can have an access only to client2 index (both read/write)
user3 can have an access only to client1 index (only read)
user4 can have an access only to client2 index (only read)
admin user can have an access to both the indexes (both read/write)

Below are the entries we have made:

file: sg_internal_users.yml

user1:
hash: $2a$12$i9OlhTub5HYc3sgUJD24QeEQPXPCr1CHz8EGB4KEHKZdaq4fWE8iW
#password is: demo1
roles:

  • sg_client1_read
  • sg_client1_write

user2:
hash: $2a$12$Hrzo.FfsyXx6KxhqLZhlPeB62rKlTeBorWnzJCzp7c5HjeLTq07Yy
#password is: demo2
roles:
- sg_client2_read
- sg_client2_write

user3:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: demo3
roles:

  • sg_client1_read

user4:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: demo4
roles:

  • sg_client2_read

admin:
hash: $2a$12$3Sg2KO3FyWVU/KZQ8oSVS.B10J2It0ffWFTMgUQ/Y0OsWN8BWueiq
#password is: admin
roles:

  • sg_client1_read
  • sg_client1_write
  • sg_client2_read
  • sg_client2_write

###########################

file: sg_roles.yml

Read/Monitor/CRUD on all the indices and cluster wide

sg_our_admin:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
indices:
‘*’:
- CRUD

#Read client1 indices only
sg_client1_read:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client1:
'’:
- INDICES_MONITOR
- INDICES_ALL
- RO

#Read client2 indices only
sg_client2_read:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client2:
'’:
- INDICES_MONITOR
- INDICES_ALL
- RO

#Write client1 indices only
sg_client1_write:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client1:
'’:
- INDICES_MONITOR
- INDICES_ALL
- WRITE

#Write client2 indices only
sg_client2_write:
cluster:
- CLUSTER_MONITOR
- CLUSTER_COMPOSITE_OPS_RO
- INDICES_MONITOR
indices:
‘?monitor*’:
‘':
- INDICES_ALL
client2:
'’:
- INDICES_MONITOR
- INDICES_ALL
- WRITE

#############################

file: sg_roles_mapping.yml

Role Mappings

sg_our_admin:
users:
- admin

sg_client1_read:
users:
- user1
- user3

sg_client2_read:
users:
- user2
- user4

sg_client1_write:
users:
- user1

sg_client2_write:
users:
- user2

We reload the SearchGaurd config using sgadmin.sh script and it is loading all the roles and mappings successfully. But the moment we try to curl the specific index with respective username and password we are getting an error as:

type":“security_exception”,“reason”:"no permissions for [indices:monitor/stats]

Though we have provided the roles related to monitor (CLUSTER_MONITOR and INDICES_MONITOR). We are not clear how to achieve this.

Can one illuminate us on this and enlighten us if we are approaching it in wrong manner?

We have couple of doubts that:

  • Is there a convention to assign roles with ‘sg_’ as prefix or we can go by any name?
  • What is tenant for and what is its role?

Thank you in adcance!

–
You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.
To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.
To post to this group, send email to search...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/812440ed-c6e0-401e-9423-a2c29bed95e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.

To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.

To post to this group, send email to search...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/f525a082-8ff9-4631-ba0f-ad2c2a7da803%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

<sg_internal_users.yml><sg_roles.yml><sg_roles_mapping.yml>