/
enforce-keyfile-access-control-in-existing-sharded-cluster-no-downtime.txt
281 lines (198 loc) · 10.5 KB
/
enforce-keyfile-access-control-in-existing-sharded-cluster-no-downtime.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
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
==============================================================
Update Sharded Cluster to Keyfile Authentication (No Downtime)
==============================================================
.. default-domain:: mongodb
.. contents:: On this page
:local:
:backlinks: none
:depth: 1
:class: singlecol
Overview
--------
.. important::
The following procedure applies to sharded clusters using MongoDB
3.4 or later.
Earlier versions of MongoDB do not support no-downtime upgrade. For
sharded clusters using earlier versions of MongoDB, see
:doc:`/tutorial/enforce-keyfile-access-control-in-existing-sharded-cluster`.
A MongoDB sharded cluster can enforce :ref:`user authentication
<authentication>` as well as :ref:`internal authentication
<inter-process-auth>` of its components to secure against unauthorized
access.
The following tutorial describes a procedure using
:setting:`security.transitionToAuth` to transition an existing sharded
cluster to enforce authentication without incurring downtime.
Before you attempt this tutorial, please familiarize yourself with the
contents of this document.
Considerations
--------------
Cloud Manager and Ops Manager
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you are using Cloud Manager or Ops Manager to manage your deployment,
refer to *Configure Access Control for MongoDB Deployments*
in the :mms-docs:`Cloud Manager manual
</tutorial/edit-host-authentication-credentials>`
or :opsmgr:`Ops Manager manual
</tutorial/edit-host-authentication-credentials>` to enforce authentication.
IP Binding
~~~~~~~~~~~
.. include:: /includes/fact-default-bind-ip-change.rst
Internal and Client Authentication Mechanisms
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This tutorial configures authentication using
:ref:`authentication-scram` for client authentication and a
:ref:`keyfile <internal-auth-keyfile>` for internal authentication.
Refer to the :ref:`authentication` documentation for a complete list of
available client and internal authentication mechanisms.
Architecture
~~~~~~~~~~~~
This tutorial assumes that each shard replica set, as well as the config
server replica set, can elect a new :term:`primary` after stepping down its
existing primary.
A replica set can elect a primary only if both of the following conditions are
true:
- A majority of voting replica set members are available after stepping down
the :term:`primary`.
- There is at least one available :term:`secondary` member that is not
:ref:`delayed <replica-set-delayed-members>`, :ref:`hidden
<replica-set-hidden-members>`, or :ref:`Priority 0
<replica-set-secondary-only-members>`.
Minimum number of ``mongos`` instances
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ensure your sharded cluster has at least two mongos instances
available. This tutorial requires restarting each :binary:`~bin.mongos` in
the cluster. If your sharded cluster has only one :binary:`~bin.mongos`
instance, this results in downtime during the period that the
:binary:`~bin.mongos` is offline.
.. _security-shardcluster-nodowntime-enable-access-control:
Enforce Keyfile Access Control on an Existing Sharded Cluster
-------------------------------------------------------------
Create and Distribute the Keyfile
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. include:: /includes/extracts/keyfile-intro-sharded-cluster.rst
.. code-block:: shell
openssl rand -base64 755 > <path-to-keyfile>
chmod 400 <path-to-keyfile>
.. include:: /includes/extracts/keyfile-distribution-sharded-cluster.rst
For more information on using keyfiles for internal authentication, refer to
:ref:`internal-auth-keyfile`.
.. _security-shardcluster-nodowntime-adminusers-clientusers:
Configure Sharded Cluster Admin User and Client Users
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You must connect to a :binary:`~bin.mongos` to complete the steps in this
section. The users created in these steps are cluster-level users and
cannot be used for accessing individual shard replica sets.
.. include:: /includes/steps/enable-authentication-in-shardcluster-nodowntime-uac.rst
Transition Each ``mongos`` Instance to Enforce Authentication
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. include:: /includes/steps/enable-authentication-in-shardcluster-nodowntime-transition-mongos.rst
At the end of this section, all :binary:`~bin.mongos` instances in the
sharded cluster are running with :setting:`security.transitionToAuth`
and :setting:`security.keyFile` internal authentication.
Transition Config Server Replica Set Members to Enforce Authentication
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. include:: /includes/steps/enable-authentication-in-shardcluster-nodowntime-transition-config.rst
At the end of this section, all :binary:`~bin.mongod` instances in the config
server replica set is running with :setting:`security.transitionToAuth` and
:setting:`security.keyFile` internal authentication.
Transition Each Shard Replica Set Members to Enforce Authentication
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Create the shard-local administrator
++++++++++++++++++++++++++++++++++++
In a sharded cluster that enforces authentication, each shard replica
set should have its own :ref:`shard-local administrator
<shard-local-users>`. You cannot use a shard-local administrator for
one shard to access another shard or the sharded cluster.
Connect to the :term:`primary` member of each shard replica set and create a
user with the :method:`db.createUser()` method, assigning it the following
roles:
- :authrole:`clusterAdmin` on the ``admin`` database
- :authrole:`userAdmin` roles on the ``admin`` database
.. tip::
.. include:: /includes/extracts/4.2-changes-passwordPrompt.rst
.. code-block:: javascript
admin = db.getSiblingDB("admin")
admin.createUser(
{
user: "admin",
pwd: passwordPrompt(), // or cleartext password
roles: [
{ role: "clusterAdmin", db: "admin" },
{ role: "userAdmin", db: "admin" }
]
}
)
At the completion of this tutorial, if you want to connect to the shard
to perform maintenance operation that require direct connection to a
shard, you must authenticate as the shard-local administrator.
.. note::
Direct connections to a shard should only be for shard-specific
maintenance and configuration. In general, clients should connect to
the sharded cluster through the :binary:`~bin.mongos`.
Procedure
+++++++++
Transitioning one shard replica set at a time, repeat these steps for
each shard replica set in the sharded cluster.
.. include:: /includes/steps/enable-authentication-in-shardcluster-nodowntime-transition-shards.rst
At this point in the tutorial, every component of the sharded cluster is
running with ``--transitionToAuth`` and :setting:`security.keyFile`
internal authentication. The sharded cluster has at least one administrative
user, and each shard replica set has a shard-local administrative user.
The remaining sections involve taking the sharded cluster out of the
transition state to fully enforce authentication.
Restart Each ``mongos`` Instance without ``transitionToAuth``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. important::
At the end of this section, clients must specify authentication
credentials to connect to the sharded cluster. Update clients to specify
authentication credentials *before* completing this section to avoid loss of
connectivity.
To complete the transition to fully enforcing authentication in the
sharded cluster, you must restart each :binary:`~bin.mongos` instance without
the :setting:`security.transitionToAuth` setting.
.. include:: /includes/steps/enable-authentication-in-shardcluster-nodowntime-auth-mongos.rst
At the end of this section, all :binary:`~bin.mongos` instances enforce client
authentication and :setting:`security.keyFile` internal authentication.
Restart Each Config Server Replica Set Member without ``transitionToAuth``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. important::
At the end of this step, clients must specify authentication credentials to
connect to the config server replica set. Update clients to specify
authentication credentials *before* completing this section to avoid loss of
connectivity.
To complete the transition to fully enforcing authentication in the
sharded cluster, you must restart each :binary:`~bin.mongod` instance without
the :setting:`security.transitionToAuth` setting.
.. include:: /includes/steps/enable-authentication-in-shardcluster-nodowntime-auth-config.rst
At the end of this section, all :binary:`~bin.mongod` instances in the config
server replica set enforce client authentication and
:setting:`security.keyFile` internal authentication.
Restart Each Member in Each Shard Replica Set without ``transitionToAuth``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. important::
At the end of this step, clients must specify authentication credentials to
connect to the shard replica set. Update clients to specify authentication
credentials *before* completing this section to avoid loss of connectivity.
To complete the transition to fully enforcing authentication in the sharded
cluster, you must restart every member of every shard replica set in the
sharded cluster without the :setting:`security.transitionToAuth` setting.
Transitioning one shard replica set at a time, repeat these steps for
each shard replica set in the sharded cluster.
.. include:: /includes/steps/enable-authentication-in-shardcluster-nodowntime-auth-shard.rst
At the end of this section, all :binary:`~bin.mongos` and :binary:`~bin.mongod`
instances in the sharded cluster enforce client authentication and
:setting:`security.keyFile` internal authentication. Clients can only connect
to the sharded cluster by using the configured client authentication mechanism.
Additional components can only join the cluster by specifying the correct
keyfile.
x.509 Certificate Internal Authentication
-----------------------------------------
MongoDB supports x.509 certificate authentication for use with a secure TLS/SSL
connection. Sharded cluster members and replica set members can use x.509
certificates to verify their membership to the cluster or the replica set
instead of using :ref:`internal-auth-keyfile`.
For details on using x.509 certificates for internal authentication, see
:doc:`/tutorial/configure-x509-member-authentication`.
:doc:`/tutorial/upgrade-keyfile-to-x509` describes how to upgrade a
deployment's internal auth mechanism from keyfile-based authentication to x.509
certificate-based auth.