You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/operate/kubernetes/active-active/global-config.md
+85-3Lines changed: 85 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -48,7 +48,6 @@ The [REAADB API reference]({{<relref "/operate/kubernetes/reference/redis_enterp
48
48
49
49
This section edits the secrets under the REAADB `.spec.globalConfigurations` section. For more information and all available fields, see the [REAADB API reference]({{<relref "/operate/kubernetes/reference/redis_enterprise_active_active_database_api">}}).
50
50
51
-
52
51
1. On an existing participating cluster, generate a YAML file containing the database secret with the relevant data.
53
52
54
53
This example shoes a secret named `my-db-secret` with the password `my-password` encoded in base 64.
@@ -87,7 +86,7 @@ This section edits the secrets under the REAADB `.spec.globalConfigurations` sec
87
86
88
87
1. On each other participating cluster, check the secret status.
89
88
90
-
``sh
89
+
```sh
91
90
kubectl get reaadb <reaadb-name> -o=jsonpath='{.status.secretsStatus}'
92
91
```
93
92
@@ -103,4 +102,87 @@ This section edits the secrets under the REAADB `.spec.globalConfigurations` sec
103
102
kubectl apply -f <db-secret-file>
104
103
```
105
104
106
-
1. Repeat the previous two steps on every participating cluster.
105
+
1. Repeat the previous two steps on every participating cluster.
106
+
107
+
## Configure role permissions
108
+
109
+
You can configure role-based access control (RBAC) permissions forActive-Active databases using the `rolesPermissions` fieldin the REAADB `.spec.globalConfigurations` section. The role permissions configuration is propagated across all participating clusters, but the underlying roles and Redis ACLs must be manually created on each cluster.
110
+
111
+
{{<note>}}You must manually create the specified roles and Redis ACLs on all participating clusters before configuring role permissions. The operator only propagates the role permissions configuration—it does not create the underlying roles and ACLs. If roles or ACLs are missing on any cluster, the operator will log errors until they are manually created.{{</note>}}
112
+
113
+
### Prerequisites
114
+
115
+
Before configuring role permissions:
116
+
117
+
1. Manually create the required roles and Redis ACLs on all participating clusters using the Redis Enterprise admin console or REST API.
118
+
2. Ensure role and ACL names match exactly across all clusters (names are case-sensitive).
119
+
3. Verify that roles and ACLs are properly configured on each cluster.
120
+
121
+
{{<warning>}}The operator does not automatically create or synchronize roles and ACLs across clusters. You are responsible for manually creating identical roles and ACLs on each participating cluster.{{</warning>}}
122
+
123
+
### Add role permissions to REAADB
124
+
125
+
1. Create or update your REAADB custom resource to include `rolesPermissions`in the global configurations.
126
+
127
+
Example REAADB with role permissions:
128
+
129
+
```yaml
130
+
apiVersion: app.redislabs.com/v1alpha1
131
+
kind: RedisEnterpriseActiveActiveDatabase
132
+
metadata:
133
+
name: reaadb-boeing
134
+
spec:
135
+
globalConfigurations:
136
+
databaseSecretName: <my-secret>
137
+
memorySize: 200MB
138
+
shardCount: 3
139
+
rolesPermissions:
140
+
- role: <role-name>
141
+
acl: <acl-name>
142
+
type: redis-acl
143
+
participatingClusters:
144
+
- name: rerc-ohare
145
+
- name: rerc-reagan
146
+
```
147
+
148
+
Replace `<role-name>` and `<acl-name>` with the exact names of your Redis Enterprise role and ACL.
149
+
150
+
2. Apply the REAADB custom resource:
151
+
152
+
```sh
153
+
kubectl apply -f <reaadb-file>
154
+
```
155
+
156
+
Alternatively, patch an existing REAADB to add role permissions:
3. Verify the REAADB status shows `active` and `Valid`:
164
+
165
+
```sh
166
+
kubectl get reaadb <reaadb-name>
167
+
168
+
NAME STATUS SPEC STATUS GLOBAL CONFIGURATIONS REDB LINKED REDBS
169
+
reaadb-boeing active Valid
170
+
```
171
+
172
+
4. Check the operator logs to confirm role permissions are applied:
173
+
174
+
```sh
175
+
kubectl logs -l name=redis-enterprise-operator
176
+
```
177
+
178
+
Look for log messages indicating "patching local BDB roles permissions" on each participating cluster.
179
+
180
+
### Troubleshooting role permissions
181
+
182
+
If you encounter issues with role permissions:
183
+
184
+
- **Missing role or ACL errors**: Manually create the specified roles and ACLs on all participating clusters with exact name matches. The operator cannot create these automatically.
185
+
- **Permission propagation failures**: Verify that the roles and ACLs are properly configured and accessible on each cluster. Remember that you must manually create identical roles and ACLs on every participating cluster.
186
+
- **Case sensitivity issues**: Verify that role and ACL names match exactly, including capitalization, across all clusters.
187
+
188
+
For more details on the `rolesPermissions` field structure, see the [REAADB API reference]({{<relref "/operate/kubernetes/reference/redis_enterprise_active_active_database_api#specglobalconfigurationsrolespermissions">}}).
0 commit comments