From dc5d4120b9c5dca611ac24efd1e9b9388a50690e Mon Sep 17 00:00:00 2001 From: Kaitlyn Michael Date: Mon, 14 Apr 2025 15:30:01 -0500 Subject: [PATCH 1/6] enable privileged mode --- .../security/enable-privileged-mode.md | 116 ++++++++++++++++++ 1 file changed, 116 insertions(+) create mode 100644 content/operate/kubernetes/security/enable-privileged-mode.md diff --git a/content/operate/kubernetes/security/enable-privileged-mode.md b/content/operate/kubernetes/security/enable-privileged-mode.md new file mode 100644 index 0000000000..76a179e376 --- /dev/null +++ b/content/operate/kubernetes/security/enable-privileged-mode.md @@ -0,0 +1,116 @@ +--- +categories: +- docs +- operate +- kubernetes +description: Enable adding additional capabilities to the security context for the Redis Enterprise container by editing the `allowPrivilegeEscalation` field in the REC. +linkTitle: Enable privileged mode +title: Enable privileged mode +weight: 98 +--- + +[Security settings for Kubernetes pods](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) are configured in the [`SecurityContext`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#securitycontext-v1-core). The `allowPrivilegeEscalation` field controls if a container can gain more privileges than its parent process. + +If `allowPrivilegeEscalation` is set to `true` the container can have additional [Linux capabilities](https://man7.org/linux/man-pages/man7/capabilities.7.html) (such as `SYS_RESOURCE`) and is considered to be running in **privileged mode**. + +Redis Enterprise for Kubernetes 7.22.0-6 introduces the ability to run in **unprivileged mode**, where all capabilities are dropped from the Redis Enterprise container and `allowPrivilegeEscalation` is set to `false`. All other security-related settings remain the same as in privileged mode. Unprivileged mode is the default for installations and upgrades of the Redis Enterprise operator for versions 7.22.0-6 and later. + +## Default behavior + +**Unprivileged mode** is the default for installations and upgrades of the Redis Enterprise operator for versions 7.22.0-6 and later. This default behavior is in effect if REC spec has `allowAutoAdjustment` set to `false` or removed. + +The REC security context will look like this in unprivileged mode: + +```yaml +securityContext: + allowPrivilegeEscalation: false + capabilities: + drop: + - ALL + privileged: false + readOnlyRootFilesystem: false +``` + +## Enable privileged mode + +To allow the Redis Enterprise container additional capabilities, you can enable **privileged mode**. Note that changing the following value on a running cluster will trigger a rolling update. + +To enable **privileged mode**, set `allowAutoAdjustment` to `true`. + +```yaml +spec: + securityContext: + resourceLimits: + allowAutoAdjustment: true +``` + +In privileged mode, the security context should look like this: + +```yaml +securityContext: + allowPrivilegeEscalation: true + capabilities: + add: + - SYS_RESOURCE + drop: + - ALL + privileged: false + readOnlyRootFilesystem: false +``` + +OpenShift users upgrading to 7.22.0-6 need to make changes to your existing SCC (security context constraint). + +## OpenShift Upgrades + +If running in **unprivileged mode**, remove the custom `redis-enterprise-scc-v2` and disconnect it from the REC service account after completing your upgrade. + +If running in **privileged mode**, manually reapply the [security context constraints (SCC)](https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html) file ([`scc.yaml`]({{< relref "/operate/kubernetes/deployment/openshift/openshift-cli#deploy-the-operator" >}})) and bind it to your service account. + +```sh +oc apply -f openshift/scc.yaml +``` + +```sh +oc adm policy add-scc-to-user redis-enterprise-scc-v2 \ + system:serviceaccount:: +``` + +## New OpenShift installations + +New installations of Redis Enterprise for Kubernetes 7.22.0-6 and later automatically run in **unprivileged mode**, using a built-in `nonroot-v2-SCC` which is less permissive and more secure. + +To enable **privileged mode** after installation, apply and grant permissions to the `redis-enterprise-scc-v2` SCC. + +1. Apply the file `scc.yaml` file. + + {{}} +Do not edit this file. + {{}} + + ```sh + oc apply -f openshift/scc.yaml + ``` + + You should receive the following response: + + ```sh + securitycontextconstraints.security.openshift.io "redis-enterprise-scc-v2" configured + ``` + +1. Provide the operator permissions for the pods. + + ```sh + oc adm policy add-scc-to-user redis-enterprise-scc-v2 \ + system:serviceaccount:: + ``` + +## SYS_RESOURCE + +The `SYS_RESOURCE` capability may be required if processes in the container need to raise resource limits, such as the maximum number of open file descriptors. + +Some Redis Enterprise processes require the ability to open at least 100,000 file descriptors. If the default limit is lower and the container lacks the `SYS_RESOURCE` capability, the process may fail repeatedly, rendering the cluster unusable. To use unprivileged mode, configure your Kubernetes worker nodes to ensure a default file descriptor limit of at least 100,000. + +If you are already running a Redis Enterprise Cluster on Kubernetes, your worker nodes are likely configured correctly. In this case, it is safe to upgrade the operator and use unprivileged mode. + +Based on our testing, all major cloud providers configure Kubernetes worker nodes with file descriptor limits well above the required minimum. These setups are compatible with unprivileged mode. The only known exception is clusters created with [Kubespray](hhttps://kubespray.io/#/), which sets default file descriptor limits below the required 100,000. If you use Kubespray with default settings, you must run the operator in privileged mode. + From d3d7a6076f57155f448b503c7d4db2c6f4d5ffa9 Mon Sep 17 00:00:00 2001 From: Kaitlyn Michael Date: Mon, 14 Apr 2025 15:32:43 -0500 Subject: [PATCH 2/6] copy edits --- .../kubernetes/security/enable-privileged-mode.md | 11 +++++------ content/operate/kubernetes/upgrade/upgrade-olm.md | 2 +- 2 files changed, 6 insertions(+), 7 deletions(-) diff --git a/content/operate/kubernetes/security/enable-privileged-mode.md b/content/operate/kubernetes/security/enable-privileged-mode.md index 76a179e376..a467cb3c06 100644 --- a/content/operate/kubernetes/security/enable-privileged-mode.md +++ b/content/operate/kubernetes/security/enable-privileged-mode.md @@ -60,11 +60,11 @@ securityContext: OpenShift users upgrading to 7.22.0-6 need to make changes to your existing SCC (security context constraint). -## OpenShift Upgrades +## OpenShift upgrades -If running in **unprivileged mode**, remove the custom `redis-enterprise-scc-v2` and disconnect it from the REC service account after completing your upgrade. +If running in **unprivileged mode**, remove the custom `redis-enterprise-scc-v2` SCC and unbind it from the REC service account after completing your upgrade. -If running in **privileged mode**, manually reapply the [security context constraints (SCC)](https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html) file ([`scc.yaml`]({{< relref "/operate/kubernetes/deployment/openshift/openshift-cli#deploy-the-operator" >}})) and bind it to your service account. +If running in **privileged mode**, manually reapply the [security context constraints (SCC)](https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html) file ([`scc.yaml`]({{< relref "/operate/kubernetes/deployment/openshift/openshift-cli#deploy-the-operator" >}})) and rebind it to the REC service account. ```sh oc apply -f openshift/scc.yaml @@ -81,7 +81,7 @@ New installations of Redis Enterprise for Kubernetes 7.22.0-6 and later automati To enable **privileged mode** after installation, apply and grant permissions to the `redis-enterprise-scc-v2` SCC. -1. Apply the file `scc.yaml` file. +1. Apply the `scc.yaml` file. {{}} Do not edit this file. @@ -108,9 +108,8 @@ Do not edit this file. The `SYS_RESOURCE` capability may be required if processes in the container need to raise resource limits, such as the maximum number of open file descriptors. -Some Redis Enterprise processes require the ability to open at least 100,000 file descriptors. If the default limit is lower and the container lacks the `SYS_RESOURCE` capability, the process may fail repeatedly, rendering the cluster unusable. To use unprivileged mode, configure your Kubernetes worker nodes to ensure a default file descriptor limit of at least 100,000. +Some Redis Enterprise processes require the ability to open at least 100,000 file descriptors. If the default limit is lower and the container lacks the `SYS_RESOURCE` capability, the process may fail repeatedly, rendering the cluster unusable. To use unprivileged mode, configure your Kubernetes worker nodes to ensure a default file descriptor limit of at least 100,000. If you are already running a Redis Enterprise Cluster on Kubernetes, your worker nodes are likely configured correctly. In this case, it is safe to upgrade the operator and use unprivileged mode. Based on our testing, all major cloud providers configure Kubernetes worker nodes with file descriptor limits well above the required minimum. These setups are compatible with unprivileged mode. The only known exception is clusters created with [Kubespray](hhttps://kubespray.io/#/), which sets default file descriptor limits below the required 100,000. If you use Kubespray with default settings, you must run the operator in privileged mode. - diff --git a/content/operate/kubernetes/upgrade/upgrade-olm.md b/content/operate/kubernetes/upgrade/upgrade-olm.md index 6082ddcd08..a3a882f495 100644 --- a/content/operate/kubernetes/upgrade/upgrade-olm.md +++ b/content/operate/kubernetes/upgrade/upgrade-olm.md @@ -75,7 +75,6 @@ You can monitor the upgrade from the **Installed Operators** page. A new Redis E ## Reapply the SCC - If you are using OpenShift, you must manually reappply the [security context constraints (SCC)](https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html) file ([`scc.yaml`]({{< relref "/operate/kubernetes/deployment/openshift/openshift-cli#deploy-the-operator" >}})) and bind it to your service account. ```sh @@ -86,6 +85,7 @@ oc apply -f openshift/scc.yaml oc adm policy add-scc-to-user redis-enterprise-scc-v2 \ system:serviceaccount:: ``` + ## Upgrade the Redis Enterprise Cluster {{}} From 1e4479da784a54eeef67d485328c72832838be92 Mon Sep 17 00:00:00 2001 From: Kaitlyn Michael Date: Mon, 14 Apr 2025 15:45:07 -0500 Subject: [PATCH 3/6] change SCC steps in install and upgrade --- .../deployment/openshift/openshift-cli.md | 40 ++----------------- .../openshift/openshift-operatorhub.md | 34 ++-------------- .../kubernetes/upgrade/openshift-cli.md | 17 ++------ .../operate/kubernetes/upgrade/upgrade-olm.md | 15 ++----- 4 files changed, 14 insertions(+), 92 deletions(-) diff --git a/content/operate/kubernetes/deployment/openshift/openshift-cli.md b/content/operate/kubernetes/deployment/openshift/openshift-cli.md index 18d17e819e..16b8f03859 100644 --- a/content/operate/kubernetes/deployment/openshift/openshift-cli.md +++ b/content/operate/kubernetes/deployment/openshift/openshift-cli.md @@ -68,45 +68,11 @@ Changes to the `openshift.bundle.yaml` file can cause unexpected results. DO NOT modify or delete the StatefulSet created during the deployment process. Doing so could destroy your Redis Enterprise cluster (REC). {{}} -## Install security context constraint +## Security context constraints -The Redis Enterprise pods must run in OpenShift with privileges set in a [Security Context Constraint](https://docs.openshift.com/container-platform/4.4/authentication/managing-security-context-constraints.html#security-context-constraints-about_configuring-internal-oauth). This grants the pod various rights, such as the ability to change system limits or run as a particular user. +Upgrades to versions 7.22.0-6 and later run in **unprivileged mode** without any additional permissions or capabilities. If you don't specifally require additional capabilities, we recommend you maintain the default unprivileged mode, as its more secure. After upgrading, remove the existing `redis-enterprise-scc-v2` SCC and unbind it from the REC service account. -1. Apply the file `scc.yaml` file. - - {{}} -Do not edit this file. - {{}} - - ```sh - oc apply -f openshift/scc.yaml - ``` - - You should receive the following response: - - ```sh - securitycontextconstraints.security.openshift.io "redis-enterprise-scc-v2" configured - ``` - - Releases before 6.4.2-6 use the earlier version of the SCC, named `redis-enterprise-scc`. - -1. Provide the operator permissions for the pods. - - ```sh - oc adm policy add-scc-to-user redis-enterprise-scc-v2 \ - system:serviceaccount:: - ``` - - {{}} -If you are using version 6.2.18-41 or earlier, add additional permissions for your cluster. - -```sh -oc adm policy add-scc-to-user redis-enterprise-scc \ -system:serviceaccount::redis-enterprise-operator -``` -{{}} - - You can check the name of your project using the `oc project` command. To replace the project name, use `oc edit project myproject`. Replace `rec` with the name of your Redis Enterprise cluster, if different. +To enable privileged mode, see [Enable privileged mode > OpenShift upgrades]({{}}). ## Create a Redis Enterprise cluster custom resource diff --git a/content/operate/kubernetes/deployment/openshift/openshift-operatorhub.md b/content/operate/kubernetes/deployment/openshift/openshift-operatorhub.md index a555456efc..57763b9f39 100644 --- a/content/operate/kubernetes/deployment/openshift/openshift-operatorhub.md +++ b/content/operate/kubernetes/deployment/openshift/openshift-operatorhub.md @@ -43,39 +43,11 @@ To see which version of Redis Enterprise for Kubernetes supports your OpenShift {{}}DO NOT modify or delete the StatefulSet created during the deployment process. Doing so could destroy your Redis Enterprise cluster (REC).{{}} -## Install security context constraint +## Security context constraints -The Redis Enterprise pods must run in OpenShift with privileges set in a [Security Context Constraint](https://docs.openshift.com/container-platform/4.4/authentication/managing-security-context-constraints.html#security-context-constraints-about_configuring-internal-oauth). This grants the pod various rights, such as the ability to change system limits or run as a particular user. +Upgrades to versions 7.22.0-6 and later run in **unprivileged mode** without any additional permissions or capabilities. If you don't specifally require additional capabilities, we recommend you maintain the default unprivileged mode, as its more secure. After upgrading, remove the existing `redis-enterprise-scc-v2` SCC and unbind it from the REC service account. -{{}} - Before creating any clusters, install the security context constraint (SCC) for the operator in [scc.yaml](https://github.com/RedisLabs/redis-enterprise-k8s-docs/blob/master/openshift/scc.yaml). -{{}} - -You only need to install the SCC once, but you must not delete it. - -1. Select the project you'll be using or create a new project. - -1. Download [`scc.yaml`](https://github.com/RedisLabs/redis-enterprise-k8s-docs/blob/master/openshift/scc.yaml). - -1. Apply the file to install the security context constraint. - - ```sh - oc apply -f scc.yaml - ``` - -After the install, the OperatorHub automatically uses the constraint for Redis Enterprise node pods. - -{{< note >}} -If you are using the recommended RedisEnterpriseCluster name of `rec`, the SCC is automatically bound to the RedisEnterpriseCluster after install. - -If you choose a different name for the RedisEnterpriseCluster, or override the default service account name, you must manually bind the SCC to the RedisEnterpriseCluster’s service account: - - ```sh - oc adm policy add-scc-to-user redis-enterprise-scc-v2 \ - system:serviceaccount:: - ``` - -{{< /note >}} +To enable privileged mode, see [Enable privileged mode > OpenShift upgrades]({{}}). ## Create Redis Enterprise custom resources diff --git a/content/operate/kubernetes/upgrade/openshift-cli.md b/content/operate/kubernetes/upgrade/openshift-cli.md index dc90753b54..0603590f39 100644 --- a/content/operate/kubernetes/upgrade/openshift-cli.md +++ b/content/operate/kubernetes/upgrade/openshift-cli.md @@ -128,22 +128,13 @@ redis-enterprise-operator 1/1 1 1 0m36s We recommend upgrading the REC as soon as possible after updating the operator. After the operator upgrade completes, the operator suspends the management of the REC and its associated REDBs, until the REC upgrade completes. {{< /warning >}} -### Reapply the SCC +## Security context constraints -If you are using OpenShift, you will also need to manually reapply the [security context constraints](https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html) file ([`scc.yaml`]({{< relref "/operate/kubernetes/deployment/openshift/openshift-cli#deploy-the-operator" >}})) and bind it to your service account. +Upgrades to versions 7.22.0-6 and later run in **unprivileged mode** without any additional permissions or capabilities. If you don't specifally require additional capabilities, we recommend you maintain the default unprivileged mode, as its more secure. After upgrading, remove the existing `redis-enterprise-scc-v2` SCC and unbind it from the REC service account. -```sh -oc apply -f openshift/scc.yaml -``` - -```sh -oc adm policy add-scc-to-user redis-enterprise-scc-v2 \ - system:serviceaccount:: -``` - -If you are upgrading from operator version 6.4.2-6 or before, see the ["after upgrading"](#after-upgrading) section to delete the old SCC and role binding after all clusters are running 6.4.2-6 or later. +To enable privileged mode, see [Enable privileged mode > OpenShift upgrades]({{}}). -## Upgrade the Redis Enterprise Cluster +## Upgrade the Redis Enterprise cluster {{}} Verify your license is valid before upgrading. Invalid licenses will cause the upgrade to fail. diff --git a/content/operate/kubernetes/upgrade/upgrade-olm.md b/content/operate/kubernetes/upgrade/upgrade-olm.md index a3a882f495..65ca380514 100644 --- a/content/operate/kubernetes/upgrade/upgrade-olm.md +++ b/content/operate/kubernetes/upgrade/upgrade-olm.md @@ -73,20 +73,13 @@ Use `kubectl get rec` and verify the `LICENSE STATE` is valid on your REC before You can monitor the upgrade from the **Installed Operators** page. A new Redis Enterprise Operator will appear in the list, with the status "Installing". OpenShift will delete the old operator, showing the "Cannot update" status during deletion. -## Reapply the SCC +## Security context constraints -If you are using OpenShift, you must manually reappply the [security context constraints (SCC)](https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html) file ([`scc.yaml`]({{< relref "/operate/kubernetes/deployment/openshift/openshift-cli#deploy-the-operator" >}})) and bind it to your service account. +Upgrades to versions 7.22.0-6 and later run in **unprivileged mode** without any additional permissions or capabilities. If you don't specifally require additional capabilities, we recommend you maintain the default unprivileged mode, as its more secure. After upgrading, remove the existing `redis-enterprise-scc-v2` SCC and unbind it from the REC service account. -```sh -oc apply -f openshift/scc.yaml -``` - -```sh -oc adm policy add-scc-to-user redis-enterprise-scc-v2 \ - system:serviceaccount:: -``` +To enable privileged mode, see [Enable privileged mode > OpenShift upgrades]({{}}). -## Upgrade the Redis Enterprise Cluster +## Upgrade the Redis Enterprise cluster {{}} Verify your license is valid before upgrading. Invalid licenses will cause the upgrade to fail. From 934dbbdabf6f1be189b842bdcfb7ef47447ebafc Mon Sep 17 00:00:00 2001 From: Kaitlyn Michael Date: Mon, 14 Apr 2025 15:45:14 -0500 Subject: [PATCH 4/6] clean up old files --- .../old-getting-started-openshift-crdb.md | 224 ------------ .../deployment/openshift/old-index.md | 344 ------------------ 2 files changed, 568 deletions(-) delete mode 100644 content/operate/kubernetes/deployment/openshift/old-getting-started-openshift-crdb.md delete mode 100644 content/operate/kubernetes/deployment/openshift/old-index.md diff --git a/content/operate/kubernetes/deployment/openshift/old-getting-started-openshift-crdb.md b/content/operate/kubernetes/deployment/openshift/old-getting-started-openshift-crdb.md deleted file mode 100644 index 46abb524a6..0000000000 --- a/content/operate/kubernetes/deployment/openshift/old-getting-started-openshift-crdb.md +++ /dev/null @@ -1,224 +0,0 @@ ---- -Title: Getting Started with Active-Active (CRDB) on OpenShift with Route-Based Ingress -alwaysopen: false -categories: -- docs -- operate -- kubernetes -description: null -draft: true -hidden: true -weight: $weight ---- -In this guide, we'll set up an [Active-Active database]({{< relref "/operate/rs/databases/active-active/_index.md" >}}) -(formerly known as CRDB) deployment with Active-Active replication -spanning across two Redis Enterprise clusters over OpenShift, using Redis Enterprise Operator -and OpenShift Route. - -## Overview - -An Active-Active deployment requires connectivity between different Kubernetes clusters. -A router is the most common way to allow such external access. A [router] -(https://docs.openshift.com/container-platform/3.5/architecture/core_concepts/routes.html#architecture-core-concepts-routes) -is configured to accept requests external to the cluster and proxy them into the -cluster based on how the route is configured. Routes are limited to HTTP/HTTPS(SNI)/TLS(SNI), -which covers web applications. - -Typically, a Kubernetes cluster administrator configures a [DNS wildcard entry] -(https://docs.openshift.com/container-platform/3.9/install_config/install/prerequisites.html#prereq-dns) -that resolves to an OpenShift Container Platform node that is running -the OpenShift router. - -The default router in OpenShift is HAProxy, which is a free, fast, and reliable solution -offering high availability, load balancing, and proxying for TCP and HTTP-based applications. - -The Redis Enterprise Operator uses the routes mechanism to expose 2 inter-cluster services: -the Redis Enterprise Cluster API service and the DB service that exposes the Active-Active database. -Both services are used during the creation and management of an Active-Active deployment. -The routes are configured with TLS passthrough. - -{{< note >}} -Routes should have unique hostnames across a Kubernetes cluster. -{{< /note >}} - -## Steps for creating an Active-Active deployment with Service Broker - -Before you create an Active-Active deployment with Service Broker, you must create a cluster -using the REC custom resource, with a Service Broker deployment as covered in -[Getting Started with Kubernetes and Openshift]({{< relref "/operate/platforms/openshift/_index.md" >}}), while noting the following: - -1. Make sure you use the latest versions of the deployment files available on GitHub. -1. Deploy nodes with at least 6GB of RAM in order to accommodate the Active-Active database plan's 5GB database size. -1. Make sure you follow the instructions to deploy the Redis Enterprise Service Broker. - -The peerClusters section in the spec is used for creating an Active-Active with the Service Broker. - -{{< note >}} -This is only relevant for OpenShift deployments, which support Service Brokers natively. -{{< /note >}} - -Copy this section of the REC spec and modify it for your environment. To apply it -to every cluster that will participate in the Active-Active database deployment, edit the cluster yaml file -and apply it using `kubectl apply -f `: - -```yaml - activeActive: - apiIngressUrl: api1.cluster1. - dbIngressSuffix: -cluster1. - method: openShiftRoute - - peerClusters: - - apiIngressUrl: api2.cluster2. - authSecret: cluster2_secret - dbIngressSuffix: -cluster2. - fqdn: ..svc.cluster.local - - apiIngressUrl: api3.cluster3. - authSecret: cluster2_secret - dbIngressSuffix: -cluster3. - fqdn: ..svc.cluster.local -``` - -This block is added to the Service Broker config map when the REC spec changes, and -it triggers a restart of the Service Broker pod to pass the peer clusters configuration -to the service broker. Once the Service Broker pod restarts, you can select the -Active-Active database plan from the OS service catalog UI. - -The elements of the section are: - -- **apiIngressUrl** - The OpenShift hostname that is created using OpenShift route. - -- **dbIngressSuffix** - The suffix of the db route name. The resulting host is -``. This is used by the Redis Enterprise Syncer to -sync data between the databases. - -- **fqdn** - The FQDN of the Kubernetes cluster where the pattern is `. -.svc.cluster.local`. (Remember that the RS cluster name is set in the REC spec). - -- **authSecret** - The Kubernetes secret name that contains the username and password -to access this cluster. - -We need to create a secret to reference from authSecret based on the cluster admin credentials -that were automatically created when the clusters were created. To do this, -repeat the following process for each of the clusters involved: - -1. Login to the OpenShift cluster where your Redis Enterprise Cluster (REC) resides. -1. To find the secret that holds the REC credentials, run: `kubectl get secrets` - - From the secrets listed, you’ll find one that is named after your REC and - of type Opaque, like this: - - ```sh - redis-enterprise-cluster Opaque 3 1d - ``` - -1. Copy the hashed password and username from the file and create a yaml file -with that information in the following format: - - ```yaml - apiVersion: v1 - kind: Secret - metadata: - name: crdb1-cred - type: Opaque - data: - password: NWhYRWU2OWQ= - username: YWRtaW5AYWNtZS5jb20= - ``` - -1. Deploy the newly created secret yaml file in the other clusters: - - ```sh - $ kubectl create -f crdb1-secret.yaml - ``` - - A typical response looks like: - - ``` - secret/crdb1-cred created - ``` - -1. Repeat the process for the other clusters until each cluster has a secret -with the credentials of the other clusters. - -After applying the update cluster deployment file, the Service Broker is redeployed -to apply the changes to the config map. - -Now, proceed to the Openshift web console. - -1. From the left menu, select a project that holds one of your configured clusters and -then select **Add to Project > Browse Catalog**. - - {{< image filename="/images/rs/openshift-crdb-catalog.png" >}} - -1. Find the **Redis Enterprise [Project Name:Cluster Name]** tile and double-click it to start the wizard. - - {{< image filename="/images/rs/openshift-crdb-information.png" >}} - -1. Click **Next** in the Information step. - - {{< image filename="/images/rs/openshift-crdb-plan.png" >}} - -1. Then, to deploy an Active-Active database on the clusters you’ve previously configured, -select the **geo-distributed-redis** plan radio button and click **Next**. - - {{< image filename="/images/rs/openshift-crdb-configuration.png" >}} - -1. Click **Next** on the Configuration step, choose a binding option in the Binding step, -and click **Create**. - - {{< image filename="/images/rs/openshift-crdb-binding.png" >}} - -The Active-Active database connected databases are now created with the specified binding, if you selected a binding. - -{{< image filename="/images/rs/openshift-crdb-results.png" >}} - -You can view the binding by following the link to the secret. - -{{< image filename="/images/rs/openshift-crdb-secret.png" >}} - -## Validating Active-Active database deployment - -To do a basic validation test of database replication: - -1. Connect to one of the cluster pods using the following command: - - ```sh - oc exec -it -0 bash - ``` - -1. At the prompt, launch the redis CLI: - - ```sh - $ redis-cli -h -p -a - ``` - -1. Set some values and verify they have been set: - - ```sh - > set keymaster Vinz - OK - > set gatekeeper Zuul - OK - > get keymaster - "Vinz" - > get gatekeeper - "Zuul" - ``` - -1. Now, exit the CLI and the pod execution environment and login to the synched database -on the other cluster. - - ```sh - oc exec -it -0 bash - $redis-cli -h -p -a - ``` - -1. Retrieve the values you previously set or continue manipulating key:value pairs -and observe the 2-way synchronization, for example: - - ```sh - > get keymaster - "Vinz" - > get gatekeeper - "Zuul" - ``` diff --git a/content/operate/kubernetes/deployment/openshift/old-index.md b/content/operate/kubernetes/deployment/openshift/old-index.md deleted file mode 100644 index f746b5a427..0000000000 --- a/content/operate/kubernetes/deployment/openshift/old-index.md +++ /dev/null @@ -1,344 +0,0 @@ ---- -Title: Redis Enterprise Software deployment for Kubernetes with OpenShift -alwaysopen: false -categories: -- docs -- operate -- kubernetes -description: Redis Enterprise is supported on OpenShift Kubernetes cluster deployments - via an operator. -draft: true -hidden: true -hideListLinks: false -weight: 60 ---- - -Redis Enterprise is supported on OpenShift Kubernetes cluster deployments via -an operator. The operator is a software component that runs in your -deployment namespace and facilitates deploying and managing -Redis Enterprise clusters. - - - -{{% comment %}} -These are the steps required to set up a Redis Enterprise Software -Cluster with OpenShift. - -Prerequisites: - -1. An [OpenShift cluster installed](https://docs.openshift.com/container-platform/4.8/installing/index.html) at version 4.6 or higher, with at least three nodes (each meeting the [minimum requirements for a development installation]({{< relref "/operate/rs/installing-upgrading/hardware-requirements.md" >}}) -1. The [kubectl package installed](https://kubernetes.io/docs/tasks/tools/install-kubectl/) at version 1.9 or higher -1. The [OpenShift cli installed](https://docs.openshift.com/container-platform/4.8/cli_reference/openshift_cli/getting-started-cli.html) - -## Step 1: Login - -- Log in to your OpenShift account as a super admin (so you have access to all the default projects). -- Create a new project, fill in the name and other details for the project, and click **Create**. - - {{< image filename="/images/rs/getting-started-kubernetes-openshift-image1.png" >}} - -- Click on “admin” (upper right corner) and then “Copy Login.” - - {{< image filename="/images/rs/getting-started-kubernetes-openshift-image4.png" >}} - -- Paste the *login* command into your shell; it should look something like this: - - ```sh - oc login https://your-cluster.acme.com –token=your$login$token - ``` - -- Next, verify that you are using the newly created project. Type: - - ```sh - oc project - ``` - -This will shift to your project rather than the default project (you can verify the project you’re currently using with the *oc project* command). - -## Step 2: Get deployment files - -Clone this repository, which contains the deployment files: - -```sh -git clone https://github.com/RedisLabs/redis-enterprise-k8s-docs -``` - - - -Specifically for the custom resource (cr) yaml file, you may also download and edit one of the files in the [example folder.](https://github.com/RedisLabs/redis-enterprise-k8s-docs/tree/master/examples) - -## Step 3: Prepare your yaml files - -Let’s look at each yaml file to see what requires editing: - -- [scc.yaml](https://raw.githubusercontent.com/RedisLabs/redis-enterprise-k8s-docs/master/openshift/scc.yaml) - - The scc ([Security Context Constraint](https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html)) yaml defines the cluster’s security context constraints, which we will apply to our project later on. We strongly recommend **not** changing anything in this yaml file. - - Apply the file: - - ```sh - oc apply -f scc.yaml - ``` - - You should receive the following response: - - ```sh - securitycontextconstraints.security.openshift.io “redis-enterprise-scc” configured - ``` - - Now you need to bind the scc to your project by typing: - - ```sh - oc adm policy add-scc-to-group redis-enterprise-scc system:serviceaccounts:your_project_name - ``` - - (If you do not remember your project name, run “oc project”) - -- [openshift.bundle.yaml](https://github.com/RedisLabs/redis-enterprise-k8s-docs/blob/master/openshift.bundle.yaml) - - - The bundle file includes several declarations: - - 1. rbac (Role-Based Access Control) defines who can access which resources. The Operator application requires these definitions to deploy and manage the entire Redis Enterprise deployment (all cluster resources within a namespace). These include declaration of rules, role and rolebinding. - 1. crd declaration, creating a [CustomResourceDefinition](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#customresourcedefinitions) for your Redis Enterprise Cluster resource. This provides another API resource to be handled by the k8s API server and managed by the operator we will deploy next - 1. operator deployment declaration, creates the operator deployment, which is responsible for managing the k8s deployment and lifecycle of a Redis Enterprise Cluster. Among many other responsibilities, it creates a [stateful set](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) that runs the Redis Enterprise nodes, as pods. The yaml contains the latest image tag representing the latest Operator version available. - - This yaml should be applied as-is, without changes. To apply it: - - ```sh - kubectl apply -f openshift.bundle.yaml - ``` - - You should receive the following response: - - ```sh - role.rbac.authorization.k8s.io/redis-enterprise-operator created - serviceaccount/redis-enterprise-operator created - rolebinding.rbac.authorization.k8s.io/redis-enterprise-operator created - customresourcedefinition.apiextensions.k8s.io/redisenterpriseclusters.app.redislabs.com configured - deployment.apps/redis-enterprise-operator created - ``` - -1. Now, verify that your redis-enterprise-operator deployment is running: - - ```sh - kubectl get deployment -l name=redis-enterprise-operator - ``` - - A typical response will look like this: - - ```sh - NAME READY UP-TO-DATE AVAILABLE AGE - redis-enterprise-operator 1/1 1 1 0m36s - ``` - - - - [sb_rbac.yaml](https://raw.githubusercontent.com/RedisLabs/redis-enterprise-k8s-docs/master/openshift/sb_rbac.yaml) - - If you’re deploying a service broker, also apply the sb_rbac.yaml file. The sb_rbac (Service Broker Role-Based Access Control) yaml defines the access permissions of the Redis Enterprise Service Broker. - - We strongly recommend **not** changing anything in this yaml file. - - To apply it, run: - - ```sh - kubectl apply -f sb_rbac.yaml - ``` - - You should receive the following response: - - ```sh - clusterrole.rbac.authorization.k8s.io/redis-enterprise-operator-sb configured - clusterrolebinding.rbac.authorization.k8s.io/redis-enterprise-operator configured - ``` --> - - - -- The [rec_rhel.yaml](https://github.com/RedisLabs/redis-enterprise-k8s-docs/blob/master/openshift/rec_rhel.yaml) defines the configuration of the newly created resource: Redis Enterprise Cluster. This yaml could be renamed your_cluster_name.yaml to keep things tidy, but this isn’t a mandatory step. - - This yaml can be edited to the required use case, however, the sample provided can be used for test/dev and quick start purposes. Here are the main fields you may review and edit: - - - name: “your_cluster_name” (e.g. “demo-cluster”) - - nodes: number_of_nodes_in_the_cluster (Must be an uneven number of at least 3 or greater—[here’s why](https://redislabs.com/redis-enterprise/technology/highly-available-redis/)) - - uiServiceType: service_type - - Service type value can be either ClusterIP or LoadBalancer. This is an optional configuration based on [k8s service types](https://kubernetes.io/docs/tutorials/kubernetes-basics/expose/expose-intro/). The default is ClusterIP. - - - storageClassName: “gp2“ - - This specifies the [StorageClass](https://kubernetes.io/docs/concepts/storage/storage-classes/) used for your nodes’ persistent disks. For example, AWS uses “gp2” as a default, GKE uses “standard” and Azure uses "default"). - - - redisEnterpriseNodeResources: The [compute resources](https://docs.openshift.com/enterprise/3.2/dev_guide/compute_resources.html#dev-compute-resources) required for each node. - - limits – specifies the max resources for a Redis node - - requests – specifies the minimum resources for a Redis node - - For example: - - ```sh - limits - cpu: “4000m” - memory: 4Gi - requests - - cpu: “4000m” - memory: 4Gi - ``` - - The default (if unspecified) is 4 cores (4000m) and 4GB (4Gi). - - {{< note >}} -Resource limits should equal requests ([Learn why](https://github.com/RedisLabs/redis-enterprise-k8s-docs/blob/master/topics.md#guaranteed-quality-of-service)). - {{< /note >}} - - - serviceBrokerSpec – - - enabled: \ - - This specifies [persistence](https://redislabs.com/redis-features/persistence) for the Service Broker with an “enabled/disabled” flag. The default is “false.” - - persistentSpec: - storageClassName: “gp2“ - - - redisEnterpriseImageSpec: This configuration controls the Redis Enterprise version used, and where it is fetched from. This is an optional field. The Operator will automatically use the matching RHEL image version for the release. - - [imagePullPolicy](https://docs.openshift.com/enterprise/3.0/architecture/core_concepts/builds_and_image_streams.html#image-pull-policy): - IfNotPresent - Repository: redislabs/redis - versionTag: 5.2.10-22 - - The version tag, as it appears on your repository (e.g. on [DockerHub](https://hub.docker.com/r/redislabs/redis/)). - -## Step 4: Create your cluster - -Once you have your_cluster_name yaml set, you need to apply it to create your Redis Enterprise Cluster: - -```sh -kubectl apply -f your_cluster_name.yaml -``` - -Run kubectl get rec and verify that creation was successful (rec is a shortcut for “RedisEnterpriseClusters”). - -You should receive a response similar to the following: - -```sh -NAME AGE - -Your_cluster_name 17s -``` - -Your Cluster will be ready shortly, typically within a few minutes. - -To check the cluster status, type the following: - -```sh -kubectl get pod -``` - -You should receive a response similar to the following: - -| | | | | | -| ---------------------------------- | ----- | ------- | -------- | --- | -| NAME | READY | STATUS | RESTARTS | AGE | -| your_cluster_name-0 | 2/2 | Running | 0 | 1m | -| your_cluster_name-1 | 2/2 | Running | 0 | 1m | -| your_cluster_name-2 | 2/2 | Running | 0 | 1m | -| your_cluster_name-controller-x-x | 1/1 | Running | 0 | 1m | -| Redis-enterprise-operator-x-x | 1/1 | Running | 0 | 5m | - -Next, create your databases. - -## Step 5: Create a database - -In order to create your database, we will log in to the Redis Enterprise UI. - -- First, apply port forwarding to your Cluster: - - ```sh - kubectl port-forward your_cluster_name-0 8443:8443 - ``` - - {{< note >}} -- your_cluster_name-0 is one of your cluster pods. You may consider running the port-forward command in the background. -- The Openshift UI provides tools for creating additional routing options, including external routes. These are covered in [RedHat Openshift documentation](https://docs.openshift.com/container-platform/3.11/dev_guide/routes.html). - {{< /note >}} - - Next, create your database. - -- Open a browser window and navigate to localhost:8443 - - {{< image filename="/images/rs/getting-started-kubernetes-openshift-image5.png" >}} - -- In order to retrieve your password, navigate to the OpenShift management console, select your project name, go to Resources-\>Secrets-\>your_cluster_name -- Retrieve your password by selecting “Reveal Secret.” - - {{< warning >}} -Do not change the default admin user password in the Redis Enterprise admin console. -Changing the admin password impacts the proper operation of the K8s deployment. - {{< /warning >}} - - {{< image filename="/images/rs/getting-started-kubernetes-openshift-image3.png" >}} - -- Follow the interface’s [instructions to create your database]({{< relref "/operate/rs/administering/creating-databases/_index.md" >}}). - -{{< note >}} -In order to conduct the Ping test through Telnet, you can create a new route to the newly created database port in the same way as described above for the UI port. After you create your database, go to the Openshift management console, select your project name and go to Applications-\>Services. You will see two newly created services representing the database along with their IP and port information, similar to the screenshot below. -{{< /note >}} - -{{< image filename="/images/rs/getting-started-kubernetes-openshift-image6.png" >}} - -{{% /comment %}} From fdaf254df0d5a228eaa9e8f9d2479fa124df1692 Mon Sep 17 00:00:00 2001 From: Kaitlyn Michael Date: Mon, 14 Apr 2025 16:05:31 -0500 Subject: [PATCH 5/6] openshift upgrade remove scc --- .../operate/kubernetes/security/enable-privileged-mode.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/content/operate/kubernetes/security/enable-privileged-mode.md b/content/operate/kubernetes/security/enable-privileged-mode.md index a467cb3c06..c827cf2511 100644 --- a/content/operate/kubernetes/security/enable-privileged-mode.md +++ b/content/operate/kubernetes/security/enable-privileged-mode.md @@ -64,6 +64,14 @@ OpenShift users upgrading to 7.22.0-6 need to make changes to your existing SCC If running in **unprivileged mode**, remove the custom `redis-enterprise-scc-v2` SCC and unbind it from the REC service account after completing your upgrade. +```sh +oc delete scc/redis-enterprise-scc-v2 +``` + +```sh +oc adm policy remove-scc-from-user redis-enterprise-scc-v2 -z +``` + If running in **privileged mode**, manually reapply the [security context constraints (SCC)](https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html) file ([`scc.yaml`]({{< relref "/operate/kubernetes/deployment/openshift/openshift-cli#deploy-the-operator" >}})) and rebind it to the REC service account. ```sh From a3aaed3e3092818e481c457275ed6835630c45bf Mon Sep 17 00:00:00 2001 From: Kaitlyn Michael <76962844+kaitlynmichael@users.noreply.github.com> Date: Tue, 15 Apr 2025 12:05:49 -0500 Subject: [PATCH 6/6] Apply suggestions from code review --- .../operate/kubernetes/security/enable-privileged-mode.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/operate/kubernetes/security/enable-privileged-mode.md b/content/operate/kubernetes/security/enable-privileged-mode.md index c827cf2511..31ecba4f74 100644 --- a/content/operate/kubernetes/security/enable-privileged-mode.md +++ b/content/operate/kubernetes/security/enable-privileged-mode.md @@ -3,7 +3,7 @@ categories: - docs - operate - kubernetes -description: Enable adding additional capabilities to the security context for the Redis Enterprise container by editing the `allowPrivilegeEscalation` field in the REC. +description: Enable adding additional capabilities to the security context for the Redis Enterprise container by enabling `allowAutoAdjustment`. linkTitle: Enable privileged mode title: Enable privileged mode weight: 98 @@ -44,7 +44,7 @@ spec: allowAutoAdjustment: true ``` -In privileged mode, the security context should look like this: +Allowing automatic resource limit adjustment will result in the security context looking like this: ```yaml securityContext: @@ -72,7 +72,7 @@ oc delete scc/redis-enterprise-scc-v2 oc adm policy remove-scc-from-user redis-enterprise-scc-v2 -z ``` -If running in **privileged mode**, manually reapply the [security context constraints (SCC)](https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html) file ([`scc.yaml`]({{< relref "/operate/kubernetes/deployment/openshift/openshift-cli#deploy-the-operator" >}})) and rebind it to the REC service account. +If running in **privileged mode**, manually reapply the [security context constraints (SCC)](https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html) file ([`scc.yaml`]({{< relref "/operate/kubernetes/deployment/openshift/openshift-cli#deploy-the-operator" >}})). ```sh oc apply -f openshift/scc.yaml @@ -85,7 +85,7 @@ oc adm policy add-scc-to-user redis-enterprise-scc-v2 \ ## New OpenShift installations -New installations of Redis Enterprise for Kubernetes 7.22.0-6 and later automatically run in **unprivileged mode**, using a built-in `nonroot-v2-SCC` which is less permissive and more secure. +New installations of Redis Enterprise for Kubernetes 7.22.0-6 and later automatically run in **unprivileged mode**, using a built-in `nonroot-v2` which is less permissive and more secure. To enable **privileged mode** after installation, apply and grant permissions to the `redis-enterprise-scc-v2` SCC.