honeymoose/OpenSearch
1
0
Fork 0
mirror of https://github.com/honeymoose/OpenSearch.git synced 2025-02-23 05:15:04 +00:00
Code Issues Packages Projects Releases Wiki Activity
OpenSearch/qa/sql/security/roles.yml

61 lines
1.1 KiB
YAML
Raw Normal View History

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:
JDBC metadata integration with security (elastic/x-pack-elasticsearch#2806) I realized that we weren't running our DatabaseMetaData tests. One thing led to another and I made these changes: 1. Got the DatabaseMetaData tests running in all three of our QA projects. 2. Fixed the SecurityCatalogFilter to work with `SqlGetIndicesAction`. It worked before, but only for requests that were a `SqlAction` as well as `SqlGetIndicesAction`. 3. Added security test for the JDBC DatabaseMetaData requests. These mirror exactly the security tests that we use for `SHOW TABLES` and `DESCRIBE` but cover the JDBC actions. Original commit: elastic/x-pack-elasticsearch@7026d83c06d4c6a18132436516eda363bcaca14f
2017-10-30 23:22:12 +00:00
cluster:
- monitor # Used by JDBC's MetaData
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_something_else:
JDBC metadata integration with security (elastic/x-pack-elasticsearch#2806) I realized that we weren't running our DatabaseMetaData tests. One thing led to another and I made these changes: 1. Got the DatabaseMetaData tests running in all three of our QA projects. 2. Fixed the SecurityCatalogFilter to work with `SqlGetIndicesAction`. It worked before, but only for requests that were a `SqlAction` as well as `SqlGetIndicesAction`. 3. Added security test for the JDBC DatabaseMetaData requests. These mirror exactly the security tests that we use for `SHOW TABLES` and `DESCRIBE` but cover the JDBC actions. Original commit: elastic/x-pack-elasticsearch@7026d83c06d4c6a18132436516eda363bcaca14f
2017-10-30 23:22:12 +00:00
cluster:
- monitor # Used by JDBC's MetaData
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: something_that_isnt_test
privileges: [read]
read_test_a:
JDBC metadata integration with security (elastic/x-pack-elasticsearch#2806) I realized that we weren't running our DatabaseMetaData tests. One thing led to another and I made these changes: 1. Got the DatabaseMetaData tests running in all three of our QA projects. 2. Fixed the SecurityCatalogFilter to work with `SqlGetIndicesAction`. It worked before, but only for requests that were a `SqlAction` as well as `SqlGetIndicesAction`. 3. Added security test for the JDBC DatabaseMetaData requests. These mirror exactly the security tests that we use for `SHOW TABLES` and `DESCRIBE` but cover the JDBC actions. Original commit: elastic/x-pack-elasticsearch@7026d83c06d4c6a18132436516eda363bcaca14f
2017-10-30 23:22:12 +00:00
cluster:
- monitor # Used by JDBC's MetaData
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]
field_security:
grant: [a]
read_test_a_and_b:
JDBC metadata integration with security (elastic/x-pack-elasticsearch#2806) I realized that we weren't running our DatabaseMetaData tests. One thing led to another and I made these changes: 1. Got the DatabaseMetaData tests running in all three of our QA projects. 2. Fixed the SecurityCatalogFilter to work with `SqlGetIndicesAction`. It worked before, but only for requests that were a `SqlAction` as well as `SqlGetIndicesAction`. 3. Added security test for the JDBC DatabaseMetaData requests. These mirror exactly the security tests that we use for `SHOW TABLES` and `DESCRIBE` but cover the JDBC actions. Original commit: elastic/x-pack-elasticsearch@7026d83c06d4c6a18132436516eda363bcaca14f
2017-10-30 23:22:12 +00:00
cluster:
- monitor # Used by JDBC's MetaData
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]
field_security:
grant: ["*"]
except: [c]
read_test_without_c_3:
JDBC metadata integration with security (elastic/x-pack-elasticsearch#2806) I realized that we weren't running our DatabaseMetaData tests. One thing led to another and I made these changes: 1. Got the DatabaseMetaData tests running in all three of our QA projects. 2. Fixed the SecurityCatalogFilter to work with `SqlGetIndicesAction`. It worked before, but only for requests that were a `SqlAction` as well as `SqlGetIndicesAction`. 3. Added security test for the JDBC DatabaseMetaData requests. These mirror exactly the security tests that we use for `SHOW TABLES` and `DESCRIBE` but cover the JDBC actions. Original commit: elastic/x-pack-elasticsearch@7026d83c06d4c6a18132436516eda363bcaca14f
2017-10-30 23:22:12 +00:00
cluster:
- monitor # Used by JDBC's MetaData
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]
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:
JDBC metadata integration with security (elastic/x-pack-elasticsearch#2806) I realized that we weren't running our DatabaseMetaData tests. One thing led to another and I made these changes: 1. Got the DatabaseMetaData tests running in all three of our QA projects. 2. Fixed the SecurityCatalogFilter to work with `SqlGetIndicesAction`. It worked before, but only for requests that were a `SqlAction` as well as `SqlGetIndicesAction`. 3. Added security test for the JDBC DatabaseMetaData requests. These mirror exactly the security tests that we use for `SHOW TABLES` and `DESCRIBE` but cover the JDBC actions. Original commit: elastic/x-pack-elasticsearch@7026d83c06d4c6a18132436516eda363bcaca14f
2017-10-30 23:22:12 +00:00
cluster:
- monitor # Used by JDBC's MetaData
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
indices:
- names: bort
privileges: [read]
Reference in New Issue Copy Permalink