Elasticsearch、Kibana权限控制

http://blog.csdn.net/pistolove/article/details/53838138

1、官方文档：https://www.elastic.co/guide/en/x-pack/current/index.html

2、Install X-Pack into Elasticsearch

bin/elasticsearch-plugin install x-pack

3、Start Elasticsearch

bin/elasticsearch

4、Install X-Pack into Kibana

bin/kibana-plugin install x-pack

5、Start Kibana

bin/kibana

6、初始用户名密码

    Navigate to Kibana at http://localhost:8601/. Log in as the built-in elastic user with the password changeme. (说白了就是初始用户名为elastic，密码为changeme)

7、修改密码

    修改elasticsearch密码：

curl -XPUT -u elastic 'localhost:9200/_xpack/security/user/elastic/_password' -d '{
"password" : "elastic"
}'

1
2
3

    修改kibana密码：修改之前需要在kibana.yml中配置elasticsearch的用户名和密码后才能需改密码，否则会报错。

# If your Elasticsearch is protected with basic authentication, these settings provide
# the username and password that the Kibana server uses to perform maintenance on the Kibana
# index at startup. Your Kibana users still need to authenticate with Elasticsearch, which
# is proxied through the Kibana server.
elasticsearch.username: "elastic"
elasticsearch.password: "your password"

1
2
3
4
5
6

curl -XPUT -u elastic 'localhost:9200/_xpack/security/user/kibana/_password' -d '{
"password" : "kibana"
}'

1
2
3

8、角色控制

kibana_user

 and 

monitoring_user

 roles.

curl -XPOST -u elastic 'localhost:9200/_xpack/security/role/events_admin' -d '{
"indices" : [
{
"names" : [ "events*" ],
"privileges" : [ "all" ]
},
{
"names" : [ ".kibana*" ],
"privileges" : [ "manage", "read", "index" ]
}
]
}'

1
2
3
4
5
6
7
8
9
10
11
12

curl -XPOST -u elastic 'localhost:9200/_xpack/security/user/jack' -d '{
"password" : "123456",
"full_name" : "jack",
"email" : "jack@163.com",
"roles" : [ "events_admin" ]
}'

1
2
3
4
5
6

9、重置密码：https://www.elastic.co/guide/en/x-pack/current/security-api-users.html#security-api-reset-user-password

10、Enabling Anonymous Access

    Incoming requests are considered to be anonymous if no authentication token can be extracted from the incoming request. By default, anonymous requests are rejected and an authentication error is returned (status code 401). 

    To enable anonymous access, you assign one or more roles to anonymous users in the elasticsearch.yml configuration file. For example, the following configuration assigns anonymous users role1 and role2:

xpack.security.authc:
anonymous:
username: anonymous_user
roles: role1, role2
authz_exception: true

The username/principal of the anonymous user. Defaults to _es_anonymous_user if not specified.

1
2
3
4
5
6
7

    The roles to associate with the anonymous user. If no roles are specified, anonymous access is disabled—anonymous requests will be rejected and return an authentication error.

11、Adding Users

    To add a user, submit a PUT or POST request to the /xpack/security/user/ endpoint. A username must be at least 1 character long and no longer than 30 characters. The first character must be a letter (a-z or A-Z)
or an underscore (). Subsequent characters can be letters, underscores (_), digits (0-9), or any of the following symbols @, -, . or $.

POST /_xpack/security/user/jacknich
{
"password": "j@rV1s",
"roles": [
"admin",
"other_role1"
],
"full_name": "Jack Nicholson",
"email": "jacknich@example.com",
"metadata": {
"intelligence": 7
},
"enabled": true
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14

    1、You must specify a password when adding a user. Passwords must be at least 6 characters long.

    2、You must assign at least one role to the user. The roles determine the user’s access permissions.

    3、The user’s full name. Optional.

    4、The user’s email address. Optional.

    5、Arbitrary metadata you want to associate with the user. Optional.

    6、Specifies whether the user should be enabled. Optional with a default of true.

12、Users控制(命令行)

（1）查询所有User：

curl -XGET -u elastic 'localhost:9200/_xpack/security/user'

1

（2）增加User：

curl -XPOST -u elastic 'localhost:9200/_xpack/security/user/demo' -d '{   "password" : "123456",   "full_name" : " demo",   "email" : “demo@163.com",  "roles" : [ "clicks_admin" ] }'

1

（3）查询具体User：

curl -XGET -u elastic 'localhost:9200/_xpack/security/user/demo'

1
2
3

（4）删除具体User：

curl -XDELETE -u elastic 'localhost:9200/_xpack/security/user/demo'

1
2
3

13、Roles控制(命令行)

（1）查询所有Roles：

curl -XGET -u elastic 'localhost:9200/_xpack/security/role'

1
2
3

（2）增加Roles：

curl -XPOST -u elastic 'localhost:9200/_xpack/security/role/clicks_admin' -d '{   "indices" : [     {       "names" : [ "events*" ],       "privileges" : [ "all" ]     },     {       "names" : [ ".kibana*" ],       "privileges" : [ "manage", "read", "index" ]     }   ] }’

1

（3）查询具体Roles：

curl -XGET -u elastic 'localhost:9200/_xpack/security/role/clicks_admin'

1
2
3

（4）删除具体Roles：

curl -XDELETE -u elastic 'localhost:9200/_xpack/security/role/clicks_admin'

1
2

14、Setting Up Field and Document Level Security

（1）Field Level Security

    To enable field level security, you specify the fields that each role can access as part of the indices permissions in a role definition. This binds field level security to a well defined set of indices (and potentially a set
of documents).

    The following role definition grants read access only to the category, @timestamp, and message fields in all the events-* indices.

{
"indices": [
{
"names": [ "events-*" ],
"privileges": [ "read" ],
"field_security" : {
"grant" : [ "category", "@timestamp", "message" ]
}
}
]
}

1
2
3
4
5
6
7
8
9
10
11

    You can also specify field expressions. For example, the following example grants read access to all fields starting with event_ prefix:

{
"indices" : [
{
"names" : [ "*" ],
"privileges" : [ "read" ],
"field_security" : {
"grant" : [ "event_*" ]
}
}
]
}

1
2
3
4
5
6
7
8
9
10
11

    Use the dot notations to refer to nested fields in more complex documents. For example, assuming the following document:

{
"customer": {
"handle": "Jim",
"email": "jim@mycompany.com",
"phone": "555-555-5555"
}
}

1
2
3
4
5
6
7

    The following role definition only allows access to the customer handle field:

{
"indices" : [
{
"names" : [ "*" ],
"privileges" : [ "read" ],
"field_security" : {
"grant" : [ "customer.handle" ]
}
}
]
}

1
2
3
4
5
6
7
8
9
10
11

    This is where wildcard support shines. For example, use customer.* to only enable read access to the customer data:

{
"indices" : [
{
"names" : [ "*" ],
"privileges" : [ "read" ],
"field_security" : {
"grant" : [ "customer.*" ]
}
}
]
}

1
2
3
4
5
6
7
8
9
10
11

    Similar to granting field permissions the permission to access fields can be denied with the following syntax:

{
"indices" : [
{
"names" : [ "*" ],
"privileges" : [ "read" ],
"field_security" : {
"grant" : [ "*"],
"except": [ "customer.handle" ]
}
}
]
}

1
2
3
4
5
6
7
8
9
10
11
12

    Absence of “field_security” in a role is equivalent to * access. Denied fields may only be provided if permission has been granted explicitly to other fields. The exceptions given must be a subset of the fields that permissions
have been granted to. Denied and granted fields defined implies access to all granted fields except those which match the pattern in denied fields. Example:

{
"indices" : [
{
"names" : [ "*" ],
"privileges" : [ "read" ],
"field_security" : {
"except": [ "customer.handle" ],
"grant" : [ "customer.*" ]
}
}
]
}

1
2
3
4
5
6
7
8
9
10
11
12

（2）Field Level Security and Roles

    When a user has several roles that specify field level permissions then the resulting field level permissions per index are the union of the individual role permissions. For example if these two roles are merged:

{
// role 1
...
"indices" : [
{
"names" : [ "*" ],
"privileges" : [ "read" ],
"field_security" : {
"grant": [ "a.*" ],
"except" : [ "a.b*" ]
}
}
]
}

{
// role 2
...
"indices" : [
{
"names" : [ "*" ],
"privileges" : [ "read" ],
"field_security" : {
"grant": [ "a.b*" ],
"except" : [ "a.b.c*" ]
}
}
]
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

    Then the resulting permission would be equal to:

{
// role 1 + role 2
...
"indices" : [
{
"names" : [ "*" ],
"privileges" : [ "read" ],
"field_security" : {
"grant": [ "a.*" ],
"except" : [ "a.b.c*" ]
}
}
]
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14

（3）Document Level Security

    The following role definition grants read access only to documents that belong to the click category within all the events-* indices.

{
"indices": [
{
"names": [ "events-*" ],
"privileges": [ "read" ],
"query": "{\"match\": {\"category\": \"click\"}}"
}
]
}

1
2
3
4
5
6
7
8
9

    For example, the following role grants read access to all indices, but restricts access to documents whose department_id equals 12.

{
"indices" : [
{
"names" : [ "*" ],
"privileges" : [ "read" ],
"query" : {
"term" : { "department_id" : 12 }
}
}
]
}

1
2
3
4
5
6
7
8
9
10
11

（4）Templating a Role Query

    For example, the following role query uses a template to insert the username of the current authenticated user:

{
"indices" : [
{
"names" : [ "my_index" ],
"privileges" : [ "read" ],
"query" : {
"template" : {
"inline" : {
"term" : { "acl.username" : "{{_user.username}}" }
}
}
}
}
]
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

    You can also access custom user metadata. For example, if you maintain a group_id in your user metadata, you can apply document level security based on the group.id field in your documents:

{
"indices" : [
{
"names" : [ "my_index" ],
"privileges" : [ "read" ],
"query" : {
"template" : {
"inline" : {
"term" : { "group.id" : "{{_user.metadata.group_id}}" }
}
}
}
}
]
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15