iSharkFly-Docs
/
opensearch-docs-cn
mirror of https://github.com/iSharkFly-Docs/opensearch-docs-cn
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Correct description of encryption functionality managed by Security (#2824) 

* fix#2810-crypt-at-rest

Signed-off-by: cwillum <cwmmoore@amazon.com>

* fix#2810-crypt-at-rest

Signed-off-by: cwillum <cwmmoore@amazon.com>

* fix#2810-crypt-at-rest

Signed-off-by: cwillum <cwmmoore@amazon.com>

* fix#2810-crypt-at-rest

Signed-off-by: cwillum <cwmmoore@amazon.com>

* fix#2810-crypt-at-rest

Signed-off-by: cwillum <cwmmoore@amazon.com>

---------

Signed-off-by: cwillum <cwmmoore@amazon.com>
This commit is contained in:
Chris Moore 2023-02-15 12:53:26 -08:00 committed by GitHub
parent 07ba1f1e48
commit f3833a0fe8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 5 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
_security/index.md
View File

@ -27,12 +27,14 @@ The following topics provide a general description of the features that define s
### Encryption
Encryption protects both data at rest and in transit. At rest, encryption secures sensitive data stored in a cluster. Some examples of stored data include indexes, logs, swap files, automated snapshots, and all data in the application directory.
Encryption typically addresses the protection of data both at rest and in transit. OpenSearch Security is responsible for managing encryption in transit.
Encryption in transit encrypts data moving to, from, and within the cluster. OpenSearch uses the TLS protocol, which covers both client-to-node encryption (the REST layer) and node-to-node encryption (the transport layer). This combination of in-transit encryption helps ensure that both requests to OpenSearch and the movement of data among different nodes are safe from tampering.
In transit, Security encrypts data moving to, from, and within the cluster. OpenSearch uses the TLS protocol, which covers both client-to-node encryption (the REST layer) and node-to-node encryption (the transport layer). This combination of in-transit encryption helps ensure that both requests to OpenSearch and the movement of data among different nodes are safe from tampering.
You can find out more about configuring TLS in the [Configuring TLS certificates]({{site.url}}{{site.baseurl}}/security/configuration/tls/) section.
Encryption at rest, on the other hand, protects data stored in the cluster, including indexes, logs, swap files, automated snapshots, and all data in the application directory. This type of encryption is managed by the operating system on each OpenSearch node. For information about enabling encryption at rest, see [Encryption at rest]({{site.url}}{{site.baseurl}}/troubleshoot/index/#encryption-at-rest).
### Authentication
Authentication is used to validate the identity of users and works by verifying an end user’s credentials against a backend configuration. These credentials can be a simple name and password, a JSON web token, or a TLS certificate. Once the authentication domain extracts those credentials from a user’s request, it can check their validity against the authentication backend.

2
_troubleshoot/index.md
View File

@ -60,7 +60,7 @@ The operating system for each OpenSearch node handles encryption of data at rest
cryptsetup luksFormat --key-file <key> <partition>
```
For full documentation on the command, see [the Linux man page](https://man7.org/linux/man-pages/man8/cryptsetup.8.html).
For full documentation about the command, see [cryptsetup(8) — Linux manual page](https://man7.org/linux/man-pages/man8/cryptsetup.8.html).
{% comment %}
## Beats