copy edit

Author: kaitlynmichael

content/operate/kubernetes/security/configuration-secrets.md

@@ -9,88 +9,68 @@ title: Store configuration in Kubernetes Secrets
 weight: 96
 ---
 
-When using Redis Enterprise for Kubernetes, you can store certain configuration items in Kubernetes Secrets. This approach has the advantage that updates to these Secrets, once configured, are read immediately by the operator and propagated to the Redis Enterprise Cluster (REC).
+You can store Redis Enterprise configuration items in Kubernetes Secrets for automatic updates and secure management. When you update these Secrets, the operator immediately reads the changes and propagates them to the Redis Enterprise Cluster (REC).
 
 ## License configuration
 
-Redis Enterprise clusters require a valid license to operate. You can apply licenses using Kubernetes Secrets or by embedding them directly in the cluster specification. This section covers how to determine your cluster's FQDN for licensing purposes and demonstrates both methods for license configuration.
+Redis Enterprise clusters require a valid license. You can apply licenses using Kubernetes Secrets (recommended) or embed them directly in the cluster specification.
 
 ### Determine your cluster FQDN
 
-For licensing purposes, you need to know your Redis Enterprise cluster's fully qualified domain name (FQDN). In Kubernetes, the REC's FQDN is the fully qualified name of the REC API service and follows this format:
+To configure licensing, you need your Redis Enterprise cluster's fully qualified domain name (FQDN). Use this format: `<REC-name>.<namespace>.svc.cluster.local`
 
-```
-<REC name>.<namespace>.svc.cluster.local
-```
-
-For example, if a REC is named `my-rec` and is deployed in the namespace `my-ns`, the FQDN will be `my-rec.my-ns.svc.cluster.local`.
-
-### Method 1: Using a Kubernetes Secret (Recommended)
+For example: `my-rec.my-ns.svc.cluster.local`
 
-You can set the license in the REC through the `licenseSecretName` YAML property.
+### Use a Kubernetes Secret (recommended)
 
-1. Add your raw license to a text file (for example, `license.txt`).
-
-2. Execute the following command to create the Secret (in this example called `rec-license`) with a key called `license`:
+1. Create a secret from your license file:
 
     ```sh
     kubectl -n <namespace> create secret generic rec-license --from-file=license=./license.txt
     ```
 
-3. Edit the REC definition and add the property `licenseSecretName: rec-license`. This will be immediately read by the Operator.
-
-    ```sh
-    kubectl edit rec <rec-name>
-    ```
-
-    Add the following to the spec:
+2. Add the secret reference to your REC specification:
 
     ```yaml
     spec:
       licenseSecretName: rec-license
     ```
 
-### Method 2: Direct license in REC specification
+### Embed license directly in REC specification
 
-Alternatively, you can specify the license key string directly in the REC YAML:
+Alternatively, you can embed the license directly in the REC YAML:
 
 ```yaml
 spec:
   nodes: 3
   license: |
     ----- LICENSE START -----
     eai14c/y6XNVykffDQSPUsHKcmpgOFUlmyTBDUEZEz+GLbXAgQFOmxcdbR9J
-    ...remaining license key content... 
-    ----- LICENSE END -----    
+    ...remaining license key content...
+    ----- LICENSE END -----
 ```
 
 {{<note>}}
-Pay attention to the indentation and spaces in the file and make sure the pipe symbol (`|`) is included after `license:`.
+You must include the pipe symbol (`|`) after `license:` and maintain proper indentation.
 {{</note>}}
 
 ## TLS certificate configuration
 
-TLS certificates are essential for securing communication between clients and Redis Enterprise databases, as well as between internal cluster components. This section explains how to store client certificates for mutual TLS authentication and how to configure certificates for different Redis Enterprise services using Kubernetes Secrets.
+You can store TLS certificates in Kubernetes Secrets to secure communication between clients and Redis Enterprise databases.
 
 ### Client certificates for mTLS
 
-Here's how to set a client certificate for mutual TLS (mTLS).
-
-1. Create a Secret called `client-cert-secret` with a property named `cert` using the following command:
+1. Create a secret with your client certificate:
 
     ```sh
     kubectl -n <namespace> create secret generic client-cert-secret --from-file=cert=<path-to-cert>
     ```
 
-2. Add this secret to the relevant Redis Enterprise Database (REDB) using the `clientAuthenticationCertificates` property as documented in [Add client certificates]({{< relref "/operate/kubernetes/security/add-client-certificates" >}}).
-
-{{<note>}}
-At the time of writing (November 14, 2023), the public documentation describes creating the secret directly in YAML. This approach has the disadvantage that it requires the user to ensure the certificate is correctly encoded to base64. This can be done using a command like `cat my-cert.pem | openssl base64`. Then paste the output into the YAML source file.
-{{</note>}}
+2. Add the secret to your REDB using the `clientAuthenticationCertificates` property. See [Add client certificates]({{< relref "/operate/kubernetes/security/add-client-certificates" >}}) for details.
 
-### Certificates for different services
+### Service certificates
 
-The notes above were valid for a client certificate. If you want to create a secret for proxy, API, or other services, they expect different keys:
+To configure certificates for proxy, API, or other services, create secrets with certificate and key files:
 
 ```sh
 kubectl create secret generic <secret-name> \
@@ -101,11 +81,11 @@ kubectl create secret generic <secret-name> \
 
 ## Best practices
 
-- Store sensitive configuration items like licenses and certificates in Secrets rather than directly in YAML files
-- Use the `--from-file` option when creating secrets to avoid manual base64 encoding
-- Ensure secrets are created in the same namespace as your REC or REDB resources
-- Use descriptive names for your secrets to make them easy to identify and manage
-- Regularly rotate certificates and update the corresponding secrets
+- Store sensitive configuration in Secrets rather than directly in YAML files
+- Use `--from-file` to avoid manual base64 encoding
+- Create secrets in the same namespace as your REC or REDB resources
+- Use descriptive secret names for easy identification
+- Regularly rotate certificates and update secrets
 
 ## See also