-
Notifications
You must be signed in to change notification settings - Fork 1.7k
/
Copy pathrotate-key-sharded-cluster.txt
266 lines (163 loc) · 6.42 KB
/
rotate-key-sharded-cluster.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
================================
Rotate Keys for Sharded Clusters
================================
.. default-domain:: mongodb
Sharded cluster members can use :ref:`keyfiles <internal-auth-keyfile>`
to authenticate each other as memers of the same deployment.
Starting in version 4.2, a :ref:`keyfile <internal-auth-keyfile>` can
contain multiple keys and membership authentication is established if
at least one key is common across members. This allows for rolling
upgrade of the keys without downtime.
The following tutorial steps through the process to update, without any
downtime, the key for a sharded cluster. [#exclude-encryption-keyfile]_
.. warning::
The example keys in this tutorial are for illustrative purposes
only. Do :red:`NOT` use for your deployment. Instead, generate a
keyfile using any method you choose (e.g. ``openssl rand -base64
756``, etc.).
Consider a sharded cluster where each member's keyfile contains the
following key:
.. figure:: /images/example-key1.png
:alt: Image of current key to replace.
:figwidth: 568px
The following procedure updates the sharded cluster members to use a
new key:
.. figure:: /images/example-key2.png
:alt: Image of new key.
:figwidth: 568px
.. [#exclude-encryption-keyfile]
This tutorial is not applicable to the :ref:`keyfile
<encrypt-local-key-mgmt>` used for the :doc:`MongoDB's encrypted
storage engine </core/security-encryption-at-rest>` local key
management. That :ref:`keyfile <encrypt-local-key-mgmt>` can only
contain a single key.
Procedure
---------
1. Modify the Keyfile to Include Old and New Keys
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Modify each member's keyfile to include both the old and new keys.
.. warning::
The example keys in this tutorial are for illustrative purposes
only. Do :red:`NOT` use for your deployment. Instead, generate a
keyfile using any method you choose (e.g. ``openssl rand -base64
756``, etc.).
You can specify multiple key strings as a sequence of key strings (optionally
enclosed in quotes):
.. figure:: /images/example-multiple-keys2.png
:alt: Image of multiple key string sequence.
:figwidth: 600px
1. Restart Each Member
~~~~~~~~~~~~~~~~~~~~~~
Once all the keyfiles contain both the old and new keys, restart each
member one at a time.
Config Servers
``````````````
**For each secondary of the config server replica set (CSRS)**,
connect :binary:`~bin.mongosh` to the member and:
a. Use the :method:`db.shutdownServer()` method to shut down the member:
.. code-block:: javascript
use admin
db.shutdownServer()
b. Restart the member.
**For the primary**, connect :binary:`~bin.mongosh` to the member and
a. Use :method:`rs.stepDown()` to step down the member:
.. code-block:: javascript
rs.stepDown()
#. Use the :method:`db.shutdownServer()` method to shut down the member:
.. code-block:: javascript
use admin
db.shutdownServer()
#. Restart the member.
Shard Replica Sets
``````````````````
**For each secondary member of the shard replica sets**, connect
:binary:`~bin.mongosh` to the member and:
a. Use the :method:`db.shutdownServer()` method to shut down the member:
.. code-block:: javascript
use admin
db.shutdownServer()
b. Restart the member.
**For the primary of each shard replica set**, connect
:binary:`~bin.mongosh` to the member and
a. Use :method:`rs.stepDown()` to step down the member:
.. code-block:: javascript
rs.stepDown()
#. Use the :method:`db.shutdownServer()` method to shut down the member:
.. code-block:: javascript
use admin
db.shutdownServer()
#. Restart the member.
``mongos`` Routers
``````````````````
**For each mongos/router instance**, connect
:binary:`~bin.mongosh` to the :binary:`~bin.mongos` instance and:
a. Use the :method:`db.shutdownServer()` method to shut down the member:
.. code-block:: javascript
use admin
db.shutdownServer()
b. Restart the member.
Once all members have been restarted, the members now accept either the
old or new key for membership authentication.
3. Update Keyfile Content to the New Key Only
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. warning::
The example keys in this tutorial are for illustrative purposes
only. Do :red:`NOT` use for your deployment. Instead, generate a
keyfile using any method you choose (e.g. ``openssl rand -base64
756``, etc.).
Modify each member's keyfile to include only the new password.
.. figure:: /images/example-key2.png
:alt: Image of new key.
:figwidth: 558px
4. Restart Each Member
~~~~~~~~~~~~~~~~~~~~~~
Once all the keyfiles contain the new key only, restart each member one
at a time.
Config Servers
``````````````
**For each secondary of the config server replica set (CSRS)**,
connect :binary:`~bin.mongosh` to the member and:
a. Use the :method:`db.shutdownServer()` method to shut down the member:
.. code-block:: javascript
use admin
db.shutdownServer()
b. Restart the member.
**For the primary**, connect :binary:`~bin.mongosh` to the member and
a. Use :method:`rs.stepDown()` to step down the member:
.. code-block:: javascript
rs.stepDown()
#. Use the :method:`db.shutdownServer()` method to shut down the member:
.. code-block:: javascript
use admin
db.shutdownServer()
#. Restart the member.
Shard Replica Sets
``````````````````
**For each secondary member of the shard replica sets**, connect
:binary:`~bin.mongosh` to the member and:
a. Use the :method:`db.shutdownServer()` method to shut down the member:
.. code-block:: javascript
use admin
db.shutdownServer()
b. Restart the member.
**For the primary of each shard replica set**, connect
:binary:`~bin.mongosh` to the member and
a. Use :method:`rs.stepDown()` to step down the member:
.. code-block:: javascript
rs.stepDown()
#. Use the :method:`db.shutdownServer()` method to shut down the member:
.. code-block:: javascript
use admin
db.shutdownServer()
#. Restart the member.
``mongos`` Routers
``````````````````
**For each mongos/router instance**, connect
:binary:`~bin.mongosh` to the :binary:`~bin.mongos` instance and:
a. Use the :method:`db.shutdownServer()` method to shut down the member:
.. code-block:: javascript
use admin
db.shutdownServer()
b. Restart the member.
Once all members have been restarted, the members now accept only the
new key for membership authentication.