SECURITY DEEP DIVE

Using Elastic Stack in production

With hand-crafted proxies, I
could break everything that I
built. I
can’t break X-
Pack Security.

2
x-pack: Security
Secure All the Way Down to the Field Level

CLUSTER INDEX DOCUMENT FIELD

3
x-pack: Security
“cluster1”

node1 node2

index1 index1
0 1

index2 index2
1 0

4
x-pack: Security
“cluster1”

node1 node2
PUT index1 index1 index1
GET index1
0 1

GET _cluster1 index2 index2

1 0

5
x-pack: Security
“cluster1”

node1 node2
PUT index1 index1 index1
GET index1
0 1

GET _cluster1 index2 index2

1 0
Index1
+ read
Audit Log x write

Index2
x read
x write

6
x-pack: Security
“cluster1”

node1 node2
PUT index1 GET index1
index1 index1
0 1 PUT index1
GET index1 x
GET _cluster1 index2 index2 GET index2
x
1 0
PUT index2 Index1
x + read
Audit Log x write

Index2
x read
x write

7
x-pack: Security
“cluster1”

node1 node2 TLS port 443

PUT index1 GET index1

index1 index1
0 1 PUT index1
GET index1 x
GET _cluster1 index2 index2 GET index2
x
1 0
PUT index2 Index1
x + read
Audit Log x write
Kibana
Index2
x read
Create users/roles x write
View users/roles

8
x-pack: Security
Document & field level security

{
“user_id”: 1234,
“email”: “joe@shack.com",
“financial”: “abc123”,
“engineering” “department”: ”engineer”
}
document level access
+ department:”engineer”

9
x-pack: Security
Document & field level security

{
“user_id”: 1234,
“email”: “joe@shack.com",
“financial”: “abc123”,
“engineering” “department”: ”engineer”
field level access }
- financial

10
x-pack: Security
Document & field level security

{
“user_id”: 1234,
“email”: “joe@shack.com",

“engineering” “department”: ”engineer”

field level access }
- financial

11
x-pack: Security
Document & field level security

{
“user_id”: 1234,
“email”: “joe@shack.com",
“admin”
“engineering” “department”: ”engineer”
}

12
x-pack: Security
Document & field level security
roles are provided by realms
• Native (default & recommended)
• File
• LDAP/AD/PKI
can be chained together {
“user_id”: 1234,
“email”: “joe@shack.com",
“admin”
“financial”: “abc123”,
“engineering” “department”: ”engineer”
}

13
x-pack: Security

14
x-pack: Security

Native realms
• default / preferred realm
• username & permissions
• cached (20 mins)
• API driven
• stored & distributed in the cluster

15
x-pack: Security
We’ve created some roles for you already

elastic
• a built-in superuser
• password “changeme”

kibana
• a built-in kibana admin
• ./kibana index
• password “changeme”
• kibana.yml contains server password

16
x-pack: Security
Secure All the Way Down to the Field Level

CLUSTER INDEX DOCUMENT FIELD

Platinum Subscription only

17
x-pack: Security
The following customer_care role grants read access to all
indices, but restricts access to documents whose
department_id equals 12

PUT /_xpack/security/role/customer_care
{
"cluster": ["all"],
"indices": [
{
"names": ["all"],
"privileges": ["read"],
"query":{"match": {"department_id": 12}}
}
]
}

18
x-pack: Security

What if a user has multiple roles?

• Document level security will take into account each role held by the user

• Combine each document level security query for a given index with an “OR”

• Only one of the role queries must match for a document to be returned

19
x-pack: Security
The following customer_care role grants read access to all
indices, but restricts access to fields: issue_id,
customer_email, customer_phone

PUT /_xpack/security/role/customer_care
{
"cluster": ["all"],
"indices": [
{
"names": ["all"],
"privileges": ["read"],
"fields": ["issue_id", “customer_email”, "customer_phone"]
}
]
}

20
x-pack: Security

You can also use wildcard field expressions *

PUT /_xpack/security/role/customer_care
{
"cluster": ["all"],
"indices": [
{
"names": ["all"],
"privileges": ["read"],
"fields": ["issue_id", “customer_*”]
}
]
}

21
x-pack: Security
Documents with more complex fields, containing JSON
objects, can be referenced using the dot notation

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

22
x-pack: Security
The following my_role role grants read access to all indices,
but restricts access to field: customer.handle

PUT /_xpack/security/role/my_role
{
"cluster": ["all"],
"indices": [
{
"names": ["all"],
"privileges": ["read"],
"fields": ["customer.handle"]
}
]
}

23
x-pack: Security

What if a user has multiple roles?

• Field level security will take into account each role held by the user

• Additive roles? - fields are combined into a single set for an index

• Override roles? - any role without field level security takes priority

24
x-pack: Security

Prevent Snooping, Tampering, and Sniffing

• Protect data as it travels within the cluster and via clients

• credit card numbers, email addresses, accounts
• SSL/TLS encryption to secure all Elastic Stack traffic
• node-to-node, HTTP and transport client
• IP filtering to prevent unapproved communication with a cluster

25
x-pack: Security
Need a Record of Who Did What and When?

• Complete record of all system and user activity - Security Compliance

• Audited events include:
• Authentication attempts
• Granted access
• Denied access
• Persisted and searchable within Elasticsearch (and/or log file)

26
x-pack: Security
Audit logging event types

• anonymous_access_denied: denied due to missing authentication token

• authentication_failed: the authentication token cannot be matched to know user
• authentication_failed [<realm>]: realm fails to present a valid authentication token
• access_denied: authenticated user does not have correct privileges to perform action
• access_granted: authenticated user with correct privilege performs an action
• tampered_request: request was detected to be tampered
• connection_granted: incoming tcp connection passed ip filtering for specific profile
• connection_denied: incoming tcp connection did not pass ip filtering for specific profile
27
For in-depth training on demand

https://www.elastic.co/training/x-pack-security

28
Security Lab