OpenSearch/qa/sql/security/roles.yml

read_all:
  indices:
    - names: test
      privileges: [read]
    - names: bort
      privileges: [read]

read_nothing:

read_something_else:
  indices:
    - names: something_that_isnt_test
      privileges: [read]

read_test_a:
  indices:
    - names: test
      privileges: [read]
      field_security:
        grant: [a]

read_test_a_and_b:
  indices:
    - names: test
      privileges: [read]
      field_security:
        grant: ["*"]
        except: [c]

read_test_without_c_3:
  indices:
    - names: test
      privileges: [read]
      query: |
        {
          "bool": {
            "must_not": [
              {
                "match": {
                  "c": 3
                }
              }
            ]
          }
        }

read_bort:
  indices:
    - names: bort
      privileges: [read]
Integrate sql's metadata with security (elastic/x-pack-elasticsearch#2446) This integrates SQL's metadata calls with security by creating `SqlIndicesAction` and routing all of SQL's metadata calls through it. Since it does know up from which indices it is working against it can be an `IndicesRequest.Replaceable` and integrate with the existing security infrastructure for filtering indices. This request is implemented fairly similarly to the `GetIndexAction` with the option to read from the master or from a local copy of cluster state. Currently SQL forces it to run on the local copy because the request doesn't properly support serialization. I'd like to implement that in a followup. Original commit: elastic/x-pack-elasticsearch@15f95128207f1272e7cc71c383ebe7c30efdd89b 2017-09-08 10:59:47 -04:00			`read_all:`
Sql security take 1 (elastic/x-pack-elasticsearch#2106) Add some basic security testing/integration. The good news: 1. Basic security now works. Users without access to an index can't run sql queries against it. Without this change they could. 2. Document level security works! At least so far as I can tell. The work left to do: 1. Field level security doesn't work properly. I mean, it kind of works in that the field's values don't leak but it just looks like they all have null values. 2. We will need to test scrolling. 3. I've only added tests for the rest sql action. I'll need to add tests for jdbc and the CLI as well. 4. I've only added tests for `SELECT` and have ignored stuff like `DESCRIBE` and `SHOW TABLES`. Original commit: elastic/x-pack-elasticsearch@b9909bbda01d625e7f58d77dc967b160c9d9c7a0 2017-07-27 17:40:14 -04:00			`indices:`
			`- names: test`
			`privileges: [read]`
Integrate sql's metadata with security (elastic/x-pack-elasticsearch#2446) This integrates SQL's metadata calls with security by creating `SqlIndicesAction` and routing all of SQL's metadata calls through it. Since it does know up from which indices it is working against it can be an `IndicesRequest.Replaceable` and integrate with the existing security infrastructure for filtering indices. This request is implemented fairly similarly to the `GetIndexAction` with the option to read from the master or from a local copy of cluster state. Currently SQL forces it to run on the local copy because the request doesn't properly support serialization. I'd like to implement that in a followup. Original commit: elastic/x-pack-elasticsearch@15f95128207f1272e7cc71c383ebe7c30efdd89b 2017-09-08 10:59:47 -04:00			`- names: bort`
			`privileges: [read]`
Sql security take 1 (elastic/x-pack-elasticsearch#2106) Add some basic security testing/integration. The good news: 1. Basic security now works. Users without access to an index can't run sql queries against it. Without this change they could. 2. Document level security works! At least so far as I can tell. The work left to do: 1. Field level security doesn't work properly. I mean, it kind of works in that the field's values don't leak but it just looks like they all have null values. 2. We will need to test scrolling. 3. I've only added tests for the rest sql action. I'll need to add tests for jdbc and the CLI as well. 4. I've only added tests for `SELECT` and have ignored stuff like `DESCRIBE` and `SHOW TABLES`. Original commit: elastic/x-pack-elasticsearch@b9909bbda01d625e7f58d77dc967b160c9d9c7a0 2017-07-27 17:40:14 -04:00
			`read_nothing:`

			`read_something_else:`
			`indices:`
			`- names: something_that_isnt_test`
			`privileges: [read]`

			`read_test_a:`
			`indices:`
			`- names: test`
			`privileges: [read]`
			`field_security:`
			`grant: [a]`

			`read_test_a_and_b:`
			`indices:`
			`- names: test`
			`privileges: [read]`
			`field_security:`
			`grant: ["*"]`
			`except: [c]`

			`read_test_without_c_3:`
			`indices:`
			`- names: test`
			`privileges: [read]`
			`query: \|`
			`{`
			`"bool": {`
			`"must_not": [`
			`{`
			`"match": {`
			`"c": 3`
			`}`
			`}`
			`]`
			`}`
			`}`
Integrate sql's metadata with security (elastic/x-pack-elasticsearch#2446) This integrates SQL's metadata calls with security by creating `SqlIndicesAction` and routing all of SQL's metadata calls through it. Since it does know up from which indices it is working against it can be an `IndicesRequest.Replaceable` and integrate with the existing security infrastructure for filtering indices. This request is implemented fairly similarly to the `GetIndexAction` with the option to read from the master or from a local copy of cluster state. Currently SQL forces it to run on the local copy because the request doesn't properly support serialization. I'd like to implement that in a followup. Original commit: elastic/x-pack-elasticsearch@15f95128207f1272e7cc71c383ebe7c30efdd89b 2017-09-08 10:59:47 -04:00
			`read_bort:`
			`indices:`
			`- names: bort`
			`privileges: [read]`