elasticsearch/docs/reference/security/authorization/field-and-document-access-control.asciidoc

[role="xpack"]
[[field-and-document-access-control]]
=== Setting up field and document level security

You can control access to data within a data stream or index by adding field and document level
security permissions to a role.
<<field-level-security,Field level security permissions>> restrict access to
particular fields within a document.
<<document-level-security,Document level security permissions>> restrict access
to particular documents.

NOTE: Document and field level security is currently meant to operate with
read-only privileged accounts. Users with document and field level
security enabled for a data stream or index should not perform write operations.

A role can define both field and document level permissions on a per-index basis.
A role that doesn’t specify field level permissions grants access to ALL fields.
Similarly, a role that doesn't specify document level permissions grants access
to ALL documents in the index.

[IMPORTANT]
=====================================================================
When assigning users multiple roles, be careful that you don't inadvertently
grant wider access than intended. Each user has a single set of field level and
document level permissions per data stream or index. See <<multiple-roles-dls-fls>>.
=====================================================================

[[multiple-roles-dls-fls]]
==== Multiple roles with document and field level security

A user can have many roles and each role can define different permissions on the
same data stream or index. It is important to understand the behavior of document and field
level security in this scenario.

Document level security takes into account each role held by the user and
combines each document level security query for a given data stream or index with an "OR". This
means that only one of the role queries must match for a document to be returned.
For example, if a role grants access to an index without document level security
and another grants access with document level security, document level security
is not applied; the user with both roles has access to all of the documents in
the index.

Field level security takes into account each role the user has and combines
all of the fields listed into a single set for each data stream or index. For example, if a
role grants access to an index without field level security and another grants
access with field level security, field level security is not be applied for
that index; the user with both roles has access to all of the fields in the
index.

For example, let's say `role_a` grants access to only the `address` field of the
documents in `index1`; it doesn't specify any document restrictions. Conversely,
`role_b` limits access to a subset of the documents in `index1`; it doesn't
specify any field restrictions. If you assign a user both roles, `role_a` gives
the user access to all documents and `role_b` gives the user access to all
fields.

If you need to restrict access to both documents and fields, consider splitting
documents by index instead.

include::role-templates.asciidoc[]
include::set-security-user.asciidoc[]


[[ccx-apikeys-dls-fls]]
==== Field and document level security with Cross-cluster API keys

<<security-api-create-cross-cluster-api-key, Cross-Cluster API keys>> can be used to authenticate
requests to a remote cluster. The `search` parameter defines permissions for cross-cluster search.
The `replication` parameter defines permissions for cross-cluster replication.

`replication` does not support any field or document level security. `search` supports field and document level security.

For reasons similar to those described in <<multiple-roles-dls-fls,Multiple roles with document and field level security>>,
you can't create a single cross-cluster API key with both the `search` and `replication` parameters if the
`search` parameter has document or field level security defined.

If you need to use both of these parameters, and you need to define document or field level security for the `search` parameter,
create two separate cross-cluster API keys, one using the `search` parameter,
and one using the `replication` parameter. You will also need to set up two different
remote connections to the same cluster, with each named connection using the appropriate cross-cluster API key.