[DOCS] Merges duplicate pages for PKI realms (#49206)

This commit is contained in:
Lisa Cawley 2019-11-19 10:29:20 -08:00 committed by lcawl
parent c6a8913c38
commit c4c8a7a43c
4 changed files with 29 additions and 49 deletions

View File

@ -986,4 +986,13 @@ See:
* {packetbeat-ref}/securing-beats.html[{packetbeat}]
* {winlogbeat-ref}/securing-beats.html[{winlogbeat}]
[role="exclude",id="configuring-pki-realm"]
=== Configuring a PKI realm
See <<pki-realm>>.
[role="exclude",id="pki-settings"]
==== PKI realm settings
See <<ref-pki-settings>>.

View File

@ -1,30 +1,15 @@
[role="xpack"]
[[configuring-pki-realm]]
=== Configuring a PKI realm
You can configure {es} to use Public Key Infrastructure (PKI) certificates to
authenticate users. This requires clients connecting directly to {es} to
present X.509 certificates. The certificates must first be accepted for
authentication on the SSL/TLS layer on {es}. Only then they are optionally
further validated by a PKI realm.
Users may also use PKI certificates to authenticate to {kib}, however this
requires some <<pki-realm-for-proxied-clients,additional configuration>>. On
{es}, this configuration enables {kib} to act as a proxy for SSL/TLS
authentication and to submit the client certificates to {es} for further
validation by a PKI realm.
For more general information, see <<pki-realm>>.
[float]
[role="xpack"]
[[pki-realm-for-direct-clients]]
==== PKI authentication for clients connecting directly to {es}
To use PKI in {es}, you configure a PKI realm, enable client authentication on
the desired network layers (transport or http), and map the Distinguished Name
(DN) from the Subject field in the user certificate to roles by using the
<<security-api-role-mapping,role-mapping API>> or the role-mapping file.
the desired network layers (transport or http), and map the Distinguished Names
(DNs) from the Subject field in the user certificates to roles. You create the
mappings in a role mapping file or use the role mappings API.
If you want the same users to also be authenticated using certificates when they
connect to {kib}, you must configure the {es} PKI realm to
<<pki-realm-for-proxied-clients,allow delegation>> and to
{kibana-ref}/kibana-authentication.html#pki-authentication[enable PKI authentication in {kib}].
You can also use a combination of PKI and username/password authentication. For
example, you can enable SSL/TLS on the transport layer and define a PKI realm to
@ -216,8 +201,6 @@ alternative to role mapping.
--
[float]
[role="xpack"]
[[pki-realm-for-proxied-clients]]
==== PKI authentication for clients connecting to {kib}
@ -288,4 +271,3 @@ PUT /_security/role_mapping/direct_pki_only
<1> only when this metadata field is set (it is *not* `null`) the user has been
authenticated in the delegation scenario.

View File

@ -2,26 +2,16 @@
[[pki-realm]]
=== PKI user authentication
You can configure {stack} {security-features} to use Public Key Infrastructure
(PKI) certificates to authenticate users in {es}. This requires clients to
present X.509 certificates.
You can configure {es} to use Public Key Infrastructure (PKI) certificates to
authenticate users. This requires clients connecting directly to {es} to
present X.509 certificates. The certificates must first be accepted for
authentication on the SSL/TLS layer on {es}. Only then they are optionally
further validated by a PKI realm. See <<pki-realm-for-direct-clients>>.
You can use PKI certificates to authenticate users in {es} as well as {kib}.
You can also use PKI certificates to authenticate to {kib}, however this
requires some additional configuration. On {es}, this configuration enables {kib}
to act as a proxy for SSL/TLS authentication and to submit the client
certificates to {es} for further validation by a PKI realm. See
<<pki-realm-for-proxied-clients>>.
To use PKI in {es}, you configure a PKI realm, enable client authentication on
the desired network layers (transport or http), and map the Distinguished Names
(DNs) from the user certificates to roles. You create the mappings in a <<pki-role-mapping, role
mapping file>> or use the {ref}/security-api-put-role-mapping.html[create role mappings API]. If you want the same users to also be
authenticated using certificates when they connect to {kib}, you must configure the {es} PKI
realm to
{ref}/configuring-pki-realm.html#pki-realm-for-proxied-clients[allow
delegation] and to
{kibana-ref}/kibana-authentication.html#pki-authentication[enable PKI
authentication in {kib}].
See also {ref}/configuring-pki-realm.html[Configuring a PKI realm].
[[pki-settings]]
==== PKI realm settings
See {ref}/security-settings.html#ref-pki-settings[PKI realm settings].
include::configuring-pki-realm.asciidoc[]

View File

@ -77,7 +77,7 @@ your subscription. For more information, see https://www.elastic.co/subscription
** <<kerberos-realm,Kerberos realms>>
** <<ldap-realm,LDAP realms>>
** <<native-realm,Native realms>>
** <<configuring-pki-realm,PKI realms>>
** <<pki-realm,PKI realms>>
** <<saml-realm,SAML realms>>
. Set up roles and users to control access to {es}.
@ -139,7 +139,6 @@ To walk through the configuration of {security-features} in {es}, {kib}, {ls}, a
include::securing-communications/separating-node-client-traffic.asciidoc[]
include::authentication/configuring-active-directory-realm.asciidoc[]
include::authentication/configuring-pki-realm.asciidoc[]
include::reference/files.asciidoc[]
include::fips-140-compliance.asciidoc[]