-
Notifications
You must be signed in to change notification settings - Fork 1.7k
/
deploy-sharded-cluster-with-keyfile-access-control.txt
280 lines (186 loc) · 8.88 KB
/
deploy-sharded-cluster-with-keyfile-access-control.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
==================================================
Deploy Sharded Cluster with Keyfile Access Control
==================================================
.. default-domain:: mongodb
.. contents:: On this page
:local:
:backlinks: none
:depth: 3
:class: singlecol
Overview
--------
Enforcing access control on a :term:`sharded cluster` requires configuring:
- Security between components of the cluster using
:doc:`Internal Authentication</core/security-internal-authentication>`.
- Security between connecting clients and the cluster using
:doc:`User Access Controls</core/authorization>`.
For this tutorial, each member of the sharded cluster *must* use the same
internal authentication mechanism and settings. This means enforcing internal
authentication on each :binary:`~bin.mongos` and :binary:`~bin.mongod` in the cluster.
The following tutorial uses a :ref:`keyfile <internal-auth-keyfile>` to
enable internal authentication.
Enforcing internal authentication also enforces user access control. To
connect to the replica set, clients like the :binary:`~bin.mongo` shell need to
use a :doc:`user account</core/authorization>`. See
:ref:`security-shardClust-deploy-access-control`.
CloudManager and OpsManager
~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you are currently using or are planning to use Cloud Manager or
Ops Manager, consider using their built-in features for
deploying a :term:`sharded cluster` with access control enforced.
See ``Deploy a Sharded Cluster`` in the
:mms-docs:`Cloud Manager manual</tutorial/deploy-sharded-cluster>` or in the
:opsmgr:`Ops Manager manual</tutorial/deploy-sharded-cluster>`.
See ``Access Control for MongoDB Deployments`` in the
:mms-docs:`Cloud Manager manual</nav/security-enable-authentication>` or in the
:opsmgr:`Ops manager manual</nav/security-enable-authentication>`.
Considerations
--------------
Keyfile Security
~~~~~~~~~~~~~~~~
Keyfiles are bare-minimum forms of security and are best suited for testing or
development environments. For production environments we recommend using
:doc:`x.509 certificates</core/security-x.509>`.
.. _security-shardClust-deploy-access-control:
Access Control
~~~~~~~~~~~~~~
.. include:: /includes/internal-authentication-tutorials-access-control-consideration.rst
Users
~~~~~
.. include:: /includes/sharded-clusters-users.rst
This tutorial requires creating sharded cluster users, but includes
optional steps for adding shard-local users.
See the :doc:`/core/security-users` security documentation for more
information.
Operating System
~~~~~~~~~~~~~~~~
This tutorial uses the :binary:`~bin.mongod` and :binary:`~bin.mongos`
programs. Windows users should use the :binary:`~bin.mongod.exe` and
:binary:`~bin.mongos.exe` programs instead.
.. _security-shard-deploy-sharded-cluster-with-access-control:
Deploy Sharded Cluster with Keyfile Access Control
--------------------------------------------------
The following procedures involve creating a new sharded cluster that consists
of a :binary:`~bin.mongos`, the config servers, and two shards.
Create the Keyfile
~~~~~~~~~~~~~~~~~~
.. include:: /includes/extracts/keyfile-intro-sharded-cluster.rst
.. code-block:: shell
openssl rand -base64 756 > <path-to-keyfile>
chmod 400 <path-to-keyfile>
See :ref:`internal-auth-keyfile` for additional details and requirements
for using keyfiles.
Distribute the Keyfile
~~~~~~~~~~~~~~~~~~~~~~
.. include:: /includes/extracts/keyfile-distribution-sharded-cluster.rst
.. _deploy-auth-cluster-create-config-server-replica-set:
Create the Config Server Replica Set
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following steps deploys a config server replica set. To use the
deprecated mirrored config server deployment topology, see
:ref:`deploy-mirrored-config-servers` instead.
For a production deployment, deploys a config server replica set with at
least three members. For testing purposes, you can create a
single-member replica set.
.. include:: /includes/steps/deploy-sharded-cluster-config-server.rst
Once the config server replica set (CSRS) is initiated and up, proceed
to creating the shard replica sets.
Create the Shard Replica Sets
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For a production deployment, use a replica set with at least three
members. For testing purposes, you can create a single-member replica
set.
These steps include optional procedures for adding shard-local users.
Executing them now ensures that there are users available for each
shard to perform shard-level maintenance.
.. include:: /includes/steps/deploy-sharded-cluster-shard-replica.rst
Connect a ``mongos`` to the Sharded Cluster
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. include:: /includes/steps/deploy-sharded-cluster-connect.rst
Add Shards to the Cluster
~~~~~~~~~~~~~~~~~~~~~~~~~
To proceed, you must be connected to the :binary:`~bin.mongos` and
authenticated as the cluster administrator user for the sharded cluster.
.. note::
This is the cluster administrator for the sharded cluster and *not*
the shard-local cluster administrator.
To add each shard to the cluster, use the :method:`sh.addShard()`
method. If the shard is a replica set, specify the name of the replica
set and specify a member of the set. In production deployments, *all*
shards should be replica sets.
The following operation adds a single shard replica set to the cluster:
.. code-block:: javascript
sh.addShard( "<replSetName>/s1-mongo1.example.net:27017")
The following operation is an example of adding a standalone :binary:`~bin.mongod`
shard to the cluster:
.. code-block:: javascript
sh.addShard( "s1-mongo1.example.net:27017")
Repeat these steps until the cluster includes all shards. At this
point, the sharded cluster enforces access control for the cluster as
well as for internal communications between each sharded cluster
component.
Enable Sharding for a Database
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To proceed, you must be connected to the :binary:`~bin.mongos` and
authenticated as the cluster administrator user for the sharded cluster.
.. note::
This is the cluster administrator for the sharded cluster and *not*
the shard-local cluster administrator.
Enabling sharding on a database makes it possible to shard collections
within the database. Use the :method:`sh.enableSharding()` method to
enable sharding on the target database.
.. code-block:: javascript
sh.enableSharding("<database>")
Shard a Collection
~~~~~~~~~~~~~~~~~~
To proceed, you must be connected to the :binary:`~bin.mongos` and
authenticated as the cluster administrator user for the sharded cluster.
.. note::
This is the cluster administrator for the sharded cluster and *not*
the shard-local cluster administrator.
To shard a collection, use the :method:`sh.shardCollection()` method.
You must specify the full namespace of the collection and a document containing
the shard key.
Your selection of shard key affects the efficiency of sharding, as well as
your ability to take advantage of certain sharding features such as
:doc:`/core/tag-aware-sharding`. See the selection considerations listed
in the :ref:`sharding-shard-key-selection`.
If the collection already contains data, you must create an index on the
:term:`shard key` using the :method:`db.collection.createIndex()` method before
using :method:`~sh.shardCollection()`.
If the collection is empty, MongoDB creates the index as part of
:method:`sh.shardCollection()`.
The following is an example of the :method:`sh.shardCollection()` method:
.. code-block:: javascript
sh.shardCollection("<database>.<collection>", { <key> : <direction> } )
Next Steps
----------
Create users to allow clients to connect to and interact with
the sharded cluster.
See :ref:`database-user-roles` for basic built-in roles to use in creating
read-only and read-write users.
x.509 Internal Authentication
-----------------------------
For details on using x.509 for internal authentication, see
:doc:`/tutorial/configure-x509-member-authentication`.
To upgrade from keyfile internal authentication to x.509 internal
authentication, see
:doc:`/tutorial/upgrade-keyfile-to-x509`.
.. seealso::
:doc:`/core/sharded-cluster-components`
:doc:`/core/sharded-cluster-requirements`
.. _deploy-mirrored-config-servers:
Create Mirrored Config Servers (Deprecated)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. versionchanged:: 3.2
Starting in MongoDB 3.2, config servers for sharded clusters can be
deployed as a :term:`replica set`. MongoDB 3.2 deprecates the use of
mirrored :binary:`~bin.mongod` instances for config servers.
In production deployments, if using mirrored config servers, you must deploy
exactly *three* config server instances, each running on different servers to
assure good uptime and data safety. In test environments, you can run all three
instances on a single server.
.. note::
If using MongoDB 3.2, consider using Replica Set Config Server deployments
over mirrored config servers.
.. include:: /includes/steps/deploy-sharded-cluster-mirrored-config.rst