Templates handling in indices rule
A ROR configuration for all examples below (click to expand)
```yaml readonlyrest: prompt_for_basic_auth: false access_control_rules: - name: "admin block" verbosity: error type: allow auth_key: admin:admin - name: "dev1 block" indices: ["idev1", "idev1_*"] auth_key: dev1:test - name: "dev2 block" indices: ["idev2", "idev2_*"] auth_key: dev2:test ```Index templates
An indices rule takes into consideration index patterns and aliases which are a part of a template definition. We should consider four types of template related requests:
Create an index template
The request will be allowed when all of following conditions are met: * a template with requested name does not exist (if it does, it's rather a template modification, than a creation), * all index patterns of the new, requested template are allowed, * all aliases of the new, requested template are allowed.
Example (click to expand)
Let's try to add an index template. We can see, using `admin` account, that there are no templates defined yet.$ curl -vk -u admin:admin "http://localhost:9200/_index_template?pretty"
HTTP/1.1 200 OK
content-type: application/json; charset=UTF-8
{
"index_templates" : [ ]
}
$ curl -vk -u dev1:test -XPUT "http://127.0.0.1:9200/_index_template/test?pretty" -H "Content-Type: application/json" -d \
'{
"index_patterns":["index*"],
"template": {
"aliases": {
"dev1_index": {},
"dev2_index": {}
}
}
}'
HTTP/1.1 403 Forbidden
content-type: application/json; charset=UTF-8
{
"error" : {
"root_cause" : [
{
"reason" : "forbidden",
"due_to" : ["OPERATION_NOT_ALLOWED"]
}
],
"reason" : "forbidden",
"due_to" : ["OPERATION_NOT_ALLOWED"],
"status" : 403
}
}
$ curl -vk -u dev1:test -XPUT "http://127.0.0.1:9200/_index_template/test?pretty" -H "Content-Type: application/json" -d \
'{
"index_patterns":["idev1_test*"],
"template": {
"aliases": {
"idev1": {},
"idev1_test": {}
}
}
}'
HTTP/1.1 200 OK
content-type: application/json; charset=UTF-8
{
"acknowledged" : true
}
Modify an index template
The request will be allowed when all of following conditions are met: * a template with requested name does exist, * all index patterns of the existing template are allowed, * all aliases of the existing template are allowed, * all index patterns of the requested template are allowed, * all aliases of the requested template are allowed.
Example (click to expand)
Let's assume the user `dev1` would like to modify the previously created template, because the index pattern is too detailed:$ curl -vk -u dev1:test -XPUT "http://127.0.0.1:9200/_index_template/test?pretty" -H "Content-Type: application/json" -d \
'{
"index_patterns":["idev*"],
"template": {
"aliases": {
"idev1": {},
"idev1_test": {}
}
}
}'
HTTP/1.1 403 Forbidden
content-type: application/json; charset=UTF-8
{
"error" : {
"root_cause" : [
{
"reason" : "forbidden",
"due_to" : ["OPERATION_NOT_ALLOWED"]
}
],
"reason" : "forbidden",
"due_to" : ["OPERATION_NOT_ALLOWED"],
"status" : 403
}
}
$ curl -vk -u dev1:test -XPUT "http://127.0.0.1:9200/_index_template/test?pretty" -H "Content-Type: application/json" -d \
'{
"index_patterns":["idev1_*"],
"template": {
"aliases": {
"idev1": {},
"idev1_test": {}
}
}
}'
HTTP/1.1 200 OK
content-type: application/json; charset=UTF-8
{
"acknowledged" : true
}
$ curl -vk -u admin:admin "http://127.0.0.1:9200/_index_template?pretty"
HTTP/1.1 200 OK
content-type: application/json; charset=UTF-8
{
"error" : {
"root_cause" : [
{
"reason" : "forbidden",
"due_to" : ["OPERATION_NOT_ALLOWED"]
}
],
"reason" : "forbidden",
"due_to" : ["OPERATION_NOT_ALLOWED"],
"status" : 403
}
}
$ curl -vk -u dev2:test -XPUT "http://127.0.0.1:9200/_index_template/test?pretty" -H "Content-Type: application/json" -d \
'{
"index_patterns":["idev2_*"],
"template": {
"aliases": {
"idev2": {},
"idev2_test": {}
}
}
}'
HTTP/1.1 403 Forbidden
content-type: application/json; charset=UTF-8
{
"error" : {
"root_cause" : [
{
"reason" : "forbidden",
"due_to" : ["OPERATION_NOT_ALLOWED"]
}
],
"reason" : "forbidden",
"due_to" : ["OPERATION_NOT_ALLOWED"],
"status" : 403
}
}
Delete an index template
The request will be allowed when template does not exist OR all of the following conditions are met: * a template with requested name does exist, * all index patterns of the existing template are allowed, * all aliases of the existing template are allowed.
Example (click to expand)
In the last section we wondered, if ROR will be able to block removing the template `temp` by the user `dev2`. Let's recall, that we proved that the user is not able to modify this template, because ROR considers that he doesn't have permissions to change/remove it.$ curl -vk -u dev2:test -XDELETE "http://127.0.0.1:9200/_index_template/test?pretty"
HTTP/1.1 403 Forbidden
content-type: application/json; charset=UTF-8
{
"error" : {
"root_cause" : [
{
"reason" : "forbidden",
"due_to" : ["OPERATION_NOT_ALLOWED"]
}
],
"reason" : "forbidden",
"due_to" : ["OPERATION_NOT_ALLOWED"],
"status" : 403
}
}
$ curl -vk -u dev1:test -XDELETE "http://127.0.0.1:9200/_index_template/test?pretty"
HTTP/1.1 200 OK
content-type: application/json; charset=UTF-8
{
"acknowledged" : true
}
Get index templates
At the moment ROR doesn't have templates rule (similar to
snapshots or repositories), which allows to restrict which
templates can be visible to the user (it is going to change in the
future). But the indices rule is enough to filter templates based
on index patterns in their definitions. An index template is
considered to be visible for a user, when the user has access to
AT LEAST ONE index pattern of the template's index pattern list.
ROR is going to show the template but to hide the information about not allowed index patterns and not allowed aliases.
Example (click to expand)
In previous sections we proved that ROR gets along with index templates adding, modifying and removing pretty well. Now, we'd like check what index templates are supposed to be visible for users. Let's assume we have 4 index templates:$ curl -vk -u admin:admin "http://127.0.0.1:9200/_index_template?pretty"
HTTP/1.1 200 OK
content-type: application/json; charset=UTF-8
{
"index_templates" : [
{
"name" : "t1",
"index_template" : {
"index_patterns" : ["i*"],
"template" : {
"aliases" : {
"idev2" : { },
"idev3" : { },
"idev1" : { }
}
},
"composed_of" : [ ]
}
},
{
"name" : "t2",
"index_template" : {
"index_patterns" : ["idev1_*"],
"template" : {
"aliases" : {
"admin_idev" : { },
"idev1" : { }
}
},
"composed_of" : [ ],
"priority" : 1
}
},
{
"name" : "t3",
"index_template" : {
"index_patterns" : ["idev2_*"],
"template" : {
"aliases" : {
"idev2" : { },
"admin_idev" : { }
}
},
"composed_of" : [ ],
"priority" : 1
}
},
{
"name" : "t4",
"index_template" : {
"index_patterns" : ["idev1_*", "idev2_*"],
"template" : {
"aliases" : {
"idev2" : { },
"admin_idev" : { },
"idev1" : { }
}
},
"composed_of" : [ ],
"priority" : 2
}
}
]
}
$ curl -vk -u dev1:test "http://127.0.0.1:9200/_index_template?pretty"
HTTP/1.1 200 OK
content-type: application/json; charset=UTF-8
{
"index_templates" : [
{
"name" : "t1",
"index_template" : {
"index_patterns" : ["i*"],
"template" : {
"aliases" : {
"idev1" : { }
}
},
"composed_of" : [ ]
}
},
{
"name" : "t2",
"index_template" : {
"index_patterns" : ["idev1_*"],
"template" : {
"aliases" : {
"idev1" : { }
}
},
"composed_of" : [ ],
"priority" : 1
}
},
{
"name" : "t4",
"index_template" : {
"index_patterns" : ["idev1_*"],
"template" : {
"aliases" : {
"idev1" : { }
}
},
"composed_of" : [ ],
"priority" : 2
}
}
]
}
Component templates
Component templates doesn't have index patterns but could have aliases. So, in this case, we should also consider four types of template related requests:
Create a component template
The request will be allowed when all of following conditions are met: * a template with requested name does not exist (if it does, it's rather a template modification, than a creation), * all aliases of the new, requested template are allowed.
Example (click to expand)
Unlike index templates, component templates don't have index patterns. But they still have aliases. So, their behaviour according to an aliases usage is quite similar, but there are several differences which are worth mentioning. Let's check if `dev1` user can create a component template:$ curl -vk -u dev1:test "http://localhost:9200/_component_template/ctemp1?pretty" -XPUT -H "Content-Type: application/json" -d \
'{
"template": {
"settings": {
"index.number_of_replicas": 0
},
"aliases": {
"idev1": {},
"idev2": {}
}
}
}'
HTTP/1.1 403 Forbidden
content-type: application/json; charset=UTF-8
{
"error" : {
"root_cause" : [
{
"reason" : "forbidden",
"due_to" : ["OPERATION_NOT_ALLOWED"]
}
],
"reason" : "forbidden",
"due_to" : ["OPERATION_NOT_ALLOWED"],
"status" : 403
}
}
$ curl -vk -u dev1:test "http://localhost:9200/_component_template/ctemp1?pretty" -XPUT -H "Content-Type: application/json" -d \
'{
"template": {
"settings": {
"index.number_of_replicas": 0
},
"aliases": {
"idev1": {}
}
}
}'
HTTP/1.1 200 OK
content-type: application/json; charset=UTF-8
{
"acknowledged" : true
}
Modify a component template
The request will be allowed when all of following conditions are met: * a template with requested name does exist, * all aliases of the existing template are allowed, * all aliases of the requested template are allowed.
Example (click to expand)
In the previous example, user `dev1` created the component template `ctemp1` with one alias `idev1`. Let's check if user `dev2` will be able to modify it:$ curl -vk -u dev2:test "http://localhost:9200/_component_template/ctemp1?pretty" -XPUT -H "Content-Type: application/json" -d \
'{
"template": {
"settings": {
"index.number_of_replicas": 0
},
"aliases": {
"idev2": {}
}
}
}'
HTTP/1.1 403 Forbidden
content-type: application/json; charset=UTF-8
{
"error" : {
"root_cause" : [
{
"reason" : "forbidden",
"due_to" : ["OPERATION_NOT_ALLOWED"]
}
],
"reason" : "forbidden",
"due_to" : ["OPERATION_NOT_ALLOWED"],
"status" : 403
}
}
Delete a component template
The request will be allowed when template does not exist OR all of the following conditions are met: * a template with requested name does exist, * all aliases of the existing template are allowed.
Example (click to expand)
If you read the previous example, you won't find anything interesting here. A component template can be removed only by someone whom ROR considers to have modification rights of the template. See that `dev2` is not able to remove `ctemp1`:$ curl -vk -u dev2:test -XDELETE "http://localhost:9200/_component_template/ctemp1?pretty"
HTTP/1.1 403 Forbidden
content-type: application/json; charset=UTF-8
{
"error" : {
"root_cause" : [
{
"reason" : "forbidden",
"due_to" : ["OPERATION_NOT_ALLOWED"]
}
],
"reason" : "forbidden",
"due_to" : ["OPERATION_NOT_ALLOWED"],
"status" : 403
}
}
Get component templates
At the moment there is no way to restrict which component templates can be visible to the user (it is going to change in the future - see a corresponding index template section). But ROR is going to hide the information about not allowed aliases of returned component templates.
Example (click to expand)
A careful reader can guess that ROR won't forbid showing component templates. But similar to indices templates, ROR will filter out aliases list depending on an aliases accessability of current user. Let's see an example:$ curl -vk -u admin:admin "http://localhost:9200/_component_template?pretty"
HTTP/1.1 200 OK
content-type: application/json; charset=UTF-8
{
"component_templates" : [
{
"name" : "ctemp2",
"component_template" : {
"template" : {
"settings" : {
"index" : {
"number_of_replicas" : "0"
}
},
"aliases" : {
"idev2" : { }
}
}
}
},
{
"name" : "ctemp1",
"component_template" : {
"template" : {
"settings" : {
"index" : {
"number_of_replicas" : "0"
}
},
"aliases" : {
"idev1" : { }
}
}
}
}
]
}
$ curl -vk -u dev1:test "http://localhost:9200/_component_template?pretty"
HTTP/1.1 200 OK
content-type: application/json; charset=UTF-8
{
"component_templates" : [
{
"name" : "ctemp2",
"component_template" : {
"template" : {
"settings" : {
"index" : {
"number_of_replicas" : "0"
}
},
"aliases" : { }
}
}
},
{
"name" : "ctemp1",
"component_template" : {
"template" : {
"settings" : {
"index" : {
"number_of_replicas" : "0"
}
},
"aliases" : {
"idev1" : { }
}
}
}
}
]
}
Troubleshooting
To figure out why the template is not returned or/and cannot be altered, you should enable a DEBUG log level and check your logs. ROR logs each step of template request handling in the indices rule, so detailed description should explain the given template is not allowed.