Skip to content

DOCS-8616: no-downtime security sharded cluster #2834

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion source/core/security-internal-authentication.txt
Original file line number Diff line number Diff line change
Expand Up @@ -95,6 +95,7 @@ see :doc:`/tutorial/upgrade-keyfile-to-x509`.
/tutorial/enforce-keyfile-access-control-in-existing-replica-set-without-downtime
/tutorial/deploy-replica-set-with-keyfile-access-control
/tutorial/enforce-keyfile-access-control-in-existing-sharded-cluster
/tutorial/deploy-sharded-cluster-with-keyfile-access-control
/tutorial/enforce-keyfile-access-control-in-existing-sharded-cluster-no-downtime
/tutorial/deploy-sharded-cluster-with-keyfile-access-control
/tutorial/configure-x509-member-authentication
/tutorial/upgrade-keyfile-to-x509
25 changes: 18 additions & 7 deletions source/includes/extracts-keyfile-info.yaml
Original file line number Diff line number Diff line change
@@ -1,9 +1,12 @@
ref: _keyfile-intro
content: |

The contents of the :ref:`keyfile <internal-auth-keyfile>` serves as
the shared password for the members of the {{deployment}}. The
content of the keyfile must be the same for all members of the
With :ref:`keyfile <internal-auth-keyfile>` authentication, the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With keyfile internal authentication, each ...

(only because people might not be familiar with keyfile authentication. each because your {{components}} is mongod or mongos.

{{components}} in the {{deployment}} use the contents of the keyfile as the
shared password for authenticating other members in the deployment. Only
{{components}} with the correct keyfile can join the {{deployment}}.

The content of the keyfile must be the same for all members of the
{{deployment}}.

You can generate a keyfile using any method you choose. The contents
Expand All @@ -24,22 +27,30 @@ source:
ref: _keyfile-intro
replacement:
deployment: replica set
components: :program:`mongod` instances
---
ref: keyfile-intro-sharded-cluster
source:
file: extracts-keyfile-info.yaml
ref: _keyfile-intro
replacement:
deployment: sharded cluster
components: :program:`mongod` or :program:`mongos` instances
---
ref: _keyfile-distribution
content: |
Copy the keyfile to each server hosting the {{deployment}} members. Use a
consistent location for each server.

Copy the keyfile to each server hosting the {{deployment}} members. For
simplicity in configuration and maintenance, save the keyfile to a
consistent location for each server, such as the file path specified in
the {{programs}} :setting:`storage.dbPath` setting.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Double checking that this recommendation of storage.dbPath has been vetted by someone.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I can't say that for certain.

I'll check with spencer

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@spencerjackson Can you chime in?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove ", such as the file path ... "


.. important::
Do not use shared network locations or storage mediums such as USB
drives for storing the keyfile.

If the {{programs}} cannot access the keyfile, they cannot communicate
with the {{deployment}}. Avoid storing the keyfile on storage mediums
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well, technically, they can communicate (at least to try to authenticate) and they'll fail and will not be recognized as a member of the sharded cluster.
Also, it's weird that this blurb is followed by:
Ensure that the user running the ... can access the keyfile.

that can be easily disconnected from the hardware hosting the
{{programs}}, such as a USB drive or a network attached storage device.

Ensure that the user running the {{programs}} can access the keyfile.
---
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
stepnum: 1
level: 4
title: "Remove ``transitionToAuth`` from the ``mongod`` configuration file."
ref: modify-config-files
pre: |

Remove the :setting:`security.transitionToAuth` key and its value from the
configuration file created during this tutorial.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Explicitly mention the keeping of the keyfile


.. code-block:: yaml

security:
keyFile: <path-to-keyfile>
---
stepnum: 2
level: 4
ref: restart-mongod
title: "Restart the ``mongod`` with the updated configuration file."
source:
file: steps-enable-authentication-in-shardcluster-nodowntime-transition-config.yaml
ref: restart-mongod
post: |

At the end of this section the config server replica set should be up and
running, fully enforcing authentication.

Users and client applications *must* specify authentiation credentials when
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

authentication

I think in general we don't expect user/client apps to access the config servers. I would just remove this sentence since the previous sentence kind of says it all.

connecting to the config server replica set.
replacement:
status: "updated"
...
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
stepnum: 1
level: 4
title: "Remove ``transitionToAuth`` from the ``mongos`` configuration file"
ref: modify-config-files
pre: |

Remove the :setting:`security.transitionToAuth` key and its value from the
configuration file created during this tutorial.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

explicitly state that they should keep the keyfile.


.. code-block:: yaml

security:
keyFile: <path-to-keyfile>

---
stepnum: 2
level: 4
ref: restart-mongos
title: "Restart the ``mongos`` with the updated configuration file."
pre: |

Connect to the :program:`mongos` and use the :method:`db.shutdownServer()`
method against the ``admin`` database to safely shut down the
:program:`mongos`.

Restart one :program:`mongos` at a time to ensure that clients
can connect to the sharded cluster. If your cluster has only one
:program:`mongos`, this step results in downtime while the :program:`mongos`
is offline.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ordering of the sentences in this step are slightly wonky.

.. note:: If your cluster has only one mongos ...

Connect to the mongos ...

.. code-block::

...
Restart (not you can then restart since you're not giving people a choice -- they need to restart) the mongos specifying ...


.. code-block:: javascript

db.getSiblingDB("admin").shutdownServer()

You can then restart the :program:`mongos` specifying the path to the updated
config file using :option:`--config`.

.. example::

The following operation restarts the :program:`mongos` specifying
the updated configuration file, here named ``mongos-secure.conf``.
The ``<path>`` represents the system path to the folder containing
the configuration file.

.. code-block:: shell

mongos --config <path>/mongos-secure.conf

.. note::
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This note seems like it belongs with the example. in which case, I might not make it a note.


MongoDB deployments running on :abbr:`Windows (Microsoft Windows)` use
the ``.cfg`` file extension instead of ``.conf``, and
:program:`mongos.exe` instead of :program:`mongos`.
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
stepnum: 1
level: 4
title: "Remove ``transitionToAuth`` from the ``mongod`` configuration file"
ref: modify-configuration
source:
file: steps-enable-authentication-in-shardcluster-nodowntime-auth-config.yaml
ref: modify-config-files
---
stepnum: 2
level: 4
title: "Restart the ``mongod`` with the new configuration file."
ref: restart-mongod
source:
file: steps-enable-authentication-in-shardcluster-nodowntime-transition-config.yaml
ref: restart-mongod
post: |

At the end of this section, the shard replica set should be up and
running fully enforcing authentication.

Users and client applications *must* specify authentiation credentials when
connecting to the shard replica set.
replacement:
status: "updated"
Original file line number Diff line number Diff line change
@@ -0,0 +1,95 @@
stepnum: 1
level: 4
title: "Add ``transitionToAuth: true`` to the ``mongod`` configuration file."
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update the mongod configuration file to include authentication settings.

(otherwise, you'd have to mention the keyfile as well).

ref: modify-config-files
pre: |

Copy the existing {{program}} configuration file, giving it a distinct
name such as ``<filename>-secure``.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing the extension .conf or .cfg for windows.


You will use this new configuration file to transition the {{program}} to
enforce authentication in the sharded cluster. Retain the original
configuration file for backup purposes.

Add the following settings to the new configuration file.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add :setting:security.transitionToAuth and security.keyFile settings to the new configuration file.

Replace the table with the yaml code block.

Keep the If using a different internal authentication ... blurb.


.. list-table::
:header-rows: 1
:widths: 30 70

* - Setting
- Value

* - :setting:`security.transitionToAuth`
- ``true``

* - :setting:`security.keyFile`
- Path to the keyfile.

If using a different internal authentication mechanism, specify
settings appropriate for the mechanism.

The new configuration file should contain all of the configuration settings
previously used by the {{program}}, as well as the new security
settings.

.. code-block:: yaml

security:
transitionToAuth: true
keyFile: <path-to-keyfile>
replacement:
program: :program:`mongod`
---
stepnum: 2
level: 4
ref: restart-mongod
title: "Restart the ``mongod`` with the new configuration file."
pre: |

If upgrading the a :term:`secondary`, connect to the :program:`mongod` and
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The organization is weird.
Paragraph 1 (shutdown)
-or-
Paragraph 2 (shutdown)
-and must do step for either-
Paragraph 3 (the restart)

No reader is going to read let me read paragraph 1, and skip over a section and let me resume at paragraph 3 and repeat for each secondary.

Starting with the secondaries, restart each secondary, one at a time:

#. Connect to the mongod and use db.shutdownServer ...
#. Restart ....

After all the secondaries have been updated, restart the primary:

#. COnnect ...
#. Use rs.stepDown() to step down the primary and trigger ... After it steps down, use ... to ensure

#. shutdown

#. Restart using ...

use the :method:`db.shutdownServer()` method against the ``admin`` database
to safely shut down the :program:`mongod`.

.. code-block:: javascript

db.getSiblingDB("admin").shutdownServer()

If upgrading the :term:`primary`, connect to the :program:`mongod` and use
the :method:`rs.stepDown()` method against the ``admin`` database to step
down the primary and trigger an election. You can use the
:method:`rs.status()` method to ensure the replica set elected a new primary.

Once you step down the primary, shut it down using the
:method:`db.shutdownServer()` method against the ``admin`` database.

.. code-block:: javascript

db.getSiblingDB("admin").rs.stepDown()
db.getSiblingDB("admin").shutdownServer()

Restart the :program:`mongod` with the {{status}} configuration
file, specifying the path to the config file using :option:`--config`.

.. example::

The following operation starts the replica set member specifying
the {{status}} configuration file, here named ``mongod-secure.conf``.
The ``<path>`` represents the system path to the folder containing
the configuration file.

.. code-block:: shell

mongod --config <path>/mongod-secure.conf

.. note::

MongoDB deployments running on :abbr:`Windows (Microsoft Windows)` use
the ``.cfg`` file extension instead of ``.conf``.
replacement:
status: "new"
post: |

Include additional settings as appropriate to your deployment. Refer to
the :ref:`configuration-options` documentation for a complete list of
configuration file options.
Original file line number Diff line number Diff line change
@@ -0,0 +1,79 @@
stepnum: 1
level: 4
title: "Add ``transitionToAuth: true`` to the ``mongos`` configuration file"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update the mongos configuration file to include authentication settings.

(otherwise, you'd have to mention in this long step the keyfile as well).

ref: modify-config-files
pre: |

Copy the existing {{program}} configuration file, giving it a distinct
name such as ``<filename>-secure``.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're missing the .conf or .cfg (if windows) for the filename.


You will use this new configuration file to transition the {{program}} to
enforce authentication in the sharded cluster. Retain the original
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove "in the sharded cluster".

configuration file for backup purposes.

Add the following settings to the new configuration file.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add :setting:security.transitionToAuth and security.keyFile settings to the new configuration file.

Replace the table with the yaml code block.

Keep the If using a different internal authentication ... blurb.


.. list-table::
:header-rows: 1
:widths: 30 70

* - Setting
- Value

* - :setting:`security.transitionToAuth`
- ``true``

* - :setting:`security.keyFile`
- Path to the keyfile.

If using a different internal authentication mechanism, specify
settings appropriate for the mechanism.

The new configuration file should contain all of the configuration settings
previously used by the {{program}}, as well as the new security
settings.

.. code-block:: yaml

security:
transitionToAuth: true
keyFile: <path-to-keyfile>
replacement:
program: :program:`mongos`
---
stepnum: 2
level: 4
ref: restart-mongos
title: "Restart the ``mongos`` with the new configuration file."
pre: |

Restart one :program:`mongos` at a time to ensure that clients can connect
to the sharded cluster. If your cluster has only one :program:`mongos`, this
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This step makes it seem like I would restart each of the mongos at step 2 instead of doing steps 1 & 2 for one mongos before repeating on the next mongos. Which contradicts the section intro paragraph. Pick one or the other. If you want people to update all the conf first and then restart one by one, or update the conf, restart, then update the conf for the other and restart.

step results in downtime while the :program:`mongos` is offline.

Connect to the :program:`mongos` and use the :method:`db.shutdownServer()`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lines 58-60 repeat lines 50-52

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

method against the ``admin`` database to safely shut down the
:program:`mongos`.

.. code-block:: javascript

db.getSiblingDB("admin").shutdownServer()

Restart :program:`mongos` with the new configuration file, specifying the
path to the config file using :option:`--config`.

.. example::

The following operation starts the :program:`mongos` specifying
the updated configuration file, here named ``mongos-secure.conf``.
The ``<path>`` represents the system path to the folder containing
the configuration file.

.. code-block:: shell

mongos --config <path>/mongos-secure.conf

.. note::

MongoDB deployments running on :abbr:`Windows (Microsoft Windows)` use
the ``.cfg`` file extension instead of ``.conf``.
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
stepnum: 1
level: 4
title: "Add ``transitionToAuth: true`` to the ``mongod`` configuration file."
ref: modify-configuration
source:
file: steps-enable-authentication-in-shardcluster-nodowntime-transition-config.yaml
ref: modify-config-files
---
stepnum: 2
level: 4
title: "Restart the ``mongod`` with the new configuration file."
ref: restart-mongod
source:
file: steps-enable-authentication-in-shardcluster-nodowntime-transition-config.yaml
ref: restart-mongod
replacement:
status: "new"
...
Loading