Jira DOC-746: RS - Document INE and new rladmin settings.

content/rs/references/rladmin.md

@@ -591,6 +591,8 @@ rladmin tune db <db:id | name>
         [ syncer_monitoring <enabled | disabled> ]
         [ mtls_allow_weak_hashing <enabled | disabled> ]
         [ mtls_allow_outdated_cert <enabled | disabled> ]
+        [ mtls_allow_no_xkusage <enabled | disabled> ]
+        [ data_internode_encryption <enabled | disabled> ]
 ```
 
 | Optional Parameters | Description |
@@ -627,6 +629,8 @@ rladmin tune db <db:id | name>
 | syncer_monitoring | Enables syncer monitoring |
 | mtls_allow_weak_hashing | Enables weak hashing (less than 2048 bits) in mTLS connections |
 | mtls_allow_outdated_cert | Enables outdated certificates in mTLS connections |
+| mtls_allow_no_xkusage | Allows extended key checks to be skipped |
+| data_internode_encryption | Enables or disables [internode encryption]({{< relref "/rs/security/internode-encryption.md" >}}) for the database |
 
 | XADD behavior mode | Description |
 | - | - |
@@ -678,6 +682,8 @@ rladmin tune cluster
         [ default_concurrent_restore_actions <value> ]
         [ show_internals <enabled | disabled> ]
         [ expose_hostnames_for_all_suffixes <enabled | disabled> ]
+        [ redis_upgrade_policy <latest | major> ]
+        [ default_redis_version <value> ]
 ```
 
 | Optional Parameters | Description |
@@ -702,6 +708,8 @@ rladmin tune cluster
 | default_concurrent_restore_actions | Default number of concurrent actions during node restore from a snapshot (positive integer or "all") |
 | show_internals |  |
 | expose_hostnames_for_all_suffixes |  |
+| redis_upgrade_policy | The policy defines how Redis upgrades are handled when you upgrade Redis Enterprise Software.<br /><br />Supported values are `latest` (Limits Redis upgrades to the current minor Redis release (`.x`) \[_default as of v6.2.4_] and `major` (Limits Redis upgrades to the current major (`.0`) release). \[_effective default prior to v6.2.4_] |
+| default_redis_version <value> | The minimum version of Redis used when databases are created or upgraded.  Typically changed in conjunction with the `redis_upgrade_policy` setting.<br/><br/>  The value parameter should be a version number in form of "x.y" where _x_ represents the major version number and _y_ represents the minor version number.  The final value corresponds to the desired version of Redis. |
 
 Redis cluster watchdog supports two pre-configured profiles:
 -  `cloud` profile is suitable for common cloud environments. It has a higher tolerance for network jitter.
@@ -734,6 +742,9 @@ rladmin upgrade db <db:id | name>
 | force | Forces upgrade and skips warnings and confirmations |
 | and module | Clause that allows upgrade of BDB and specified Redis module in a single step with only one restart (can be specified multiple times) |
 
+As of v6.2.4, the default behavior for `upgrade db` has changed.  It is now controlled by a new parameter that sets the default upgrade policy used to create new databases and to upgrade ones already in the cluster.  To learn more, see [tune cluster default_redis_version](#tune).
+
+
 ### `verify`
 
 `rladmin verify balance` prints a cluster shard balance report.

content/rs/security/internode-encryption.md

@@ -0,0 +1,61 @@
+---
+title: Internode encryption
+linkTitle: Internode encryption
+description: Describes internode which improves the security of data in transit. 
+weight: 10
+alwaysopen: false
+categories: ["RS"]
+aliases: /rs/security/internode-encryption/
+         /rs/security/internode-encryption.md
+---
+As of v6.2.4, Redis Enterprise Software supports _internode encryption_, which encrypts internal communication between nodes. This improves the security of data as it travels within a cluster.
+
+By default, internode encryption is enabled for the control plane, which manages communications within the cluster.
+
+Internode encryption is also supported for the data plane, which encrypts communication used to replicate shards between nodes and proxy communication with shards located on different nodes.
+
+Internode encryption is disabled by default for individual databases in order to optimize for performance.  Encryption adds latency and overhead; the impact is measurable and varies according to the database. You can enable internode encryption for a database by changing its configuration settings.  This lets you choose when to favor performance and when to encrypt data.
+
+## Prerequisites
+
+Internode encryption requires certain prerequisites.  
+
+You need to:
+
+- Upgrade all nodes in the cluster to v6.2.4 or later.
+
+- Open port 3342 for the TLS channel used for encrypted communication.
+
+
+## Enable internode encryption for databases
+
+To enable internode encryption for a database, you need to enable the appropriate setting for each database you wish to encrypt.  There are several ways to do this:
+
+- Use the admin console to enable the internode encryption setting from the database configuration screen:
+
+    {{<image filename="images/rs/database-configuration-internode-encryption-edit.png" alt="The Internode encryption setting can be found on the Configuration tab of the Database settings." >}}{{< /image >}}
+
+-  Use the `rladmin` command-line utility to set the [data_internode_encryption]({{< relref "/rs/references/rladmin.md#tune" >}}) setting for the database:
+
+    ``` text
+    rladmin tune db <database_id> true
+    ``` 
+
+- Use the Redis Enterprise Software REST API to set the `data_internode_encryption` setting for the database.
+
+    ``` rest
+    put /v1/bdbs/${database_id}
+    { “data_internode_encryption” : true }
+    ```
+
+When you change the internode encryption setting for a database, all active remote client connections are disconnected.  This affects every connection outside the node.
+
+## Certificate authority and rotation
+
+Starting with v6.2.4, internode communication is managed, in part, by two certificates, one for the control plane and one for the data plane.  These certificates are signed by a private certificate authority (CA).  The CA is not exposed outside of the cluster, so it cannot be accessed by external processes or services.  In addition, each cluster generates a unique CA that is not used anywhere else.
+
+The private CA is generated when a cluster is created or upgraded to 6.2.4.  
+
+When nodes join the cluster, the cluster CA is used to generate certificates for the new node, one for each plane.  Certificates signed by the private CA are not shared between clusters and they're not exposed outside the cluster.
+
+All certificates signed by the internal CA are automatically rotated. Periodically, an internal process checks certificate expiration and generates new certificates when the existing ones are about to expire.  Alerts also monitor certificate expiration and are triggered when problems prevent certificates from being rotated.