username as ${user_name}

Search Guard
1

I have the following in my SG config:

role:

sg_ingress_user:

cluster:

- UNLIMITED

indices:

'${user_name}-*':

  '*':

    - UNLIMITED

mapping:

sg_ingress_user:

backendroles:

- ingress_user

internal user:

martin_test:

readonly: true

hash:

username: martin-test

roles:

- ingress_user

Above I have sanitised the username so the internal users will only have alphanumeric and underscore. So in this case martin-test becomes martin_test. I use the username field so I can allow the user to connect. So far so good.

The issue is the role. I am using “${user_name}-*” this seems to be the SG internal username i.e. the sanitised one, martin_test. However this is not what is expected to be used when sending a document into the ES cluster. e.g. This gets a write permission error:

curl

https:///martin-test-2019-01-30/_doc/1

What I would really like is to allow either index to be written to martin-test or martin_test e.g. update the role to:

sg_ingress_user:

cluster:

- UNLIMITED

indices:

'${user_name}-*':

  '*':

    - UNLIMITED

'${real_user_name}-*':

  '*':

    - UNLIMITED

Is there something like “real_user_name”?

2

There is nothing like "real_user_name" but why not configure:

martin-test:
  readonly: true
  hash: <pass hash>
  roles:
    - ingress_user

What is the reason for "sanitizing" to martin_test?

···

Am 30.01.2019 um 12:58 schrieb martin.lester.uk@gmail.com:

I have the following in my SG config:

role:

sg_ingress_user:
  cluster:
    - UNLIMITED
  indices:
    '${user_name}-*':
      '*':
        - UNLIMITED

mapping:

sg_ingress_user:
  backendroles:
    - ingress_user

internal user:

martin_test:
  readonly: true
  hash: <pass hash>
  username: martin-test
  roles:
    - ingress_user

Above I have sanitised the username so the internal users will only have alphanumeric and underscore. So in this case martin-test becomes martin_test. I use the username field so I can allow the user to connect. So far so good.

The issue is the role. I am using "${user_name}-*" this seems to be the SG internal username i.e. the sanitised one, martin_test. However this is not what is expected to be used when sending a document into the ES cluster. e.g. This gets a write permission error:

curl <details> https://<server>/martin-test/_doc/1 <data>

What I would really like is to allow either index to be written to martin-test or martin_test e.g. update the role to:

sg_ingress_user:
  cluster:
    - UNLIMITED
  indices:
    '${user_name}-*':
      '*':
        - UNLIMITED
    '${real_user_name}-*':
      '*':
        - UNLIMITED

Is there something like "real_user_name"?

--
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/a68cd809-0e90-4cc0-8d84-311182afa0e3%40googlegroups.com\.
For more options, visit https://groups.google.com/d/optout\.

3

Your suggestion would work in this case, but the more common case is when the username is also an email address.

e.g. martin-test@email.address

This is an illegal yaml definition (I think only because of the dot but other special characters will cause issues too), hence the reason i need to clean it in the first place and use martin_test_email_address.

I have created a simple RestApi to manipulate the internal users. This allows us to create users dynamically. Potentially we can clean the username at an earlier stage but cleaning the names that get used as the keys in the yaml seemed prudent.

Thanks for any suggestions.

4

Did you try

‘martin-test@email.address’:
readonly: true
hash:

roles:
- ingress_user

Should be working IMHO (at least with recent SG 6)

If not please file a feature request in github.

···

On Monday, 4 February 2019 13:05:26 UTC+1, martin.lester.uk@gmail.com wrote:

Your suggestion would work in this case, but the more common case is when the username is also an email address.

e.g. martin-test@email.address

This is an illegal yaml definition (I think only because of the dot but other special characters will cause issues too), hence the reason i need to clean it in the first place and use martin_test_email_address.

I have created a simple RestApi to manipulate the internal users. This allows us to create users dynamically. Potentially we can clean the username at an earlier stage but cleaning the names that get used as the keys in the yaml seemed prudent.

Thanks for any suggestions.

5

I haven’t tried it with quotes. I will give that a try. Thanks.

I am using SG6.4.0