aboutsummaryrefslogtreecommitdiff
path: root/doc/source/admin/password-rotation.rst
blob: e5cfd026190cd85132d35165d3298e16941e61ae (plain)
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
282
283
284
285
286
287
288
289
290
291
292
293
294
295
=================
Password Rotation
=================

This guide describes how to change the internal secrets from ``passwords.yml``
used by Kolla-Ansible. It does not cover every possible ``passwords.yml``
variable, only the most common ones.

.. warning::

   Always back up your ``passwords.yml`` file before making any changes.
   Otherwise, it is easy to make unrecoverable mistakes.

.. warning::

   This guide relies on recent changes to Kolla and Kolla-Ansible. You may
   encounter errors if applying this guide to older deployments. It is
   recommended that you update your containers and kolla-ansible to the latest
   available versions before proceeding.

Regenerating secrets
--------------------

Passwords can be quickly re-generated using ``kolla-genpwd``.

Assuming an existing ``/etc/kolla/passwords.yml`` file, make a backup:

.. code-block:: bash

   cp /etc/kolla/passwords.yml ./passwords.yml.bak

Edit the ``passwords.yml`` file to remove the password strings for any secrets
that need to be regenerated i.e. change ``foo: "bar"`` to ``foo:``.

Regenerate the removed passwords:

.. code-block:: bash

   kolla-genpwd -p /etc/kolla/passwords.yml

Applying regenerated secrets
----------------------------

The majority of the secrets can be applied by simply reconfiguring services
with ``kolla-ansible reconfigure``. Below is a list of secrets that can be
applied this way.


* ``*_keystone_password``
* ``*_database_password`` (excluding ``nova_database_password``)
* ``*_ssh_key`` (excluding ``kolla_ssh_key``)
* ``keystone_admin_password``
* ``designate_rndc_key``
* ``keepalived_password``
* ``libvirt_sasl_password``
* ``metadata_secret``
* ``opensearch_dashboards_password``
* ``osprofiler_secret``
* ``prometheus_alertmanager_password``
* ``qdrouterd_password``
* ``valkey_master_password``

It is possible to change more secrets however some require manual steps. The
manual steps vary depending on the secret. They are listed below in the order
they should be applied if they are to be changed at the same time. Once all
manual steps are complete, reconfigure services (``kolla-ansible
reconfigure``).

For simplicity, this guide assumes Docker is being used. The same commands
should also work for Podman deployments by replacing instances of ``docker``
with ``podman`` in all relevant commands.

Kolla SSH key
^^^^^^^^^^^^^
There is currently no mechanism within Kolla-Ansible to rotate
``kolla_ssh_key``. It is however a relatively simple task to perform using a
standard Ansible playbook, or can be performed by hand on smaller deployments.

Horizon Secret Key
^^^^^^^^^^^^^^^^^^
The Horizon secret key (``horizon_secret_key``) is unique because it explicitly
supports rotation. In reality, it is a Django secret key, and is used for
cryptographic signing e.g. generating password recovery links. To minimise user
impact, it is possible to set two secret keys at once. The new one will be used
for generating new artifacts, while the old one will still be accepted for
existing artifacts.

Take note of the old password, generate a new one, and take note of it as well.

Add it to the ``passwords.yml`` file, along with the old secret, in this
exact format (including quotes in the middle):

.. code:: bash

   horizon_secret_key: newsecret' 'oldsecret

It is important to remember to remove the old key and reconfigure services
again, after all old artifacts have expired e.g. after approximately one to two
weeks.

Grafana Admin Password
^^^^^^^^^^^^^^^^^^^^^^
The Grafana admin password (``grafana_admin_password``) must be rotated
manually.

#. Generate a new Grafana Admin password.

#. Replace the old password in ``passwords.yml``.

#. Exec into any Grafana container:

   .. code:: bash

      docker exec -it grafana bash

#. Run the password reset command, then enter the new password:

   .. code:: bash

      grafana-cli admin reset-admin-password --password-from-stdin

Database Password
^^^^^^^^^^^^^^^^^
The database administrator password (``database_password``) must be rotated
manually.

#. Generate a new database password.

#. Replace the old password in ``passwords.yml``, take note of both the old and
   new passwords.

#. SSH to a host running a MariaDB container.

#. Exec into the MariaDB container:

   .. code-block:: bash

      docker exec -it mariadb bash

#. Log in to the database. You will be prompted for the password. Use the
   old value of ``database_password``:

   .. code:: bash

      mariadb --batch -uroot -p

#. Check the current state of the ``root`` user:

   .. code:: bash

      SELECT Host,User,Password FROM mysql.user WHERE User='root';

#. Update the password for the ``root`` user:

   .. code:: bash

      SET PASSWORD FOR 'root'@'%' = PASSWORD('newpassword');

#. Check that the password hash has changed in the user list:

   .. code:: bash

      SELECT Host,User,Password FROM mysql.user WHERE User='root';

#. If there are any remaining root users with the old password e.g.
   ``root@localhost``, change the password for them too.

Nova Database Password
^^^^^^^^^^^^^^^^^^^^^^
The nova database admin user password (``nova_database_password``) must be
rotated manually.

.. warning::

   From this point onward, API service may be disrupted.

#. Generate a new Nova database password.

#. Replace the old password in ``passwords.yml``.

#. Exec into the ``nova_conductor`` container:

   .. code:: bash

      docker exec -it nova_conductor bash

#. List the cells:

   .. code:: bash

      nova-manage cell_v2 list_cells --verbose

#. Find the entry for ``cell0``, copy the Database Connection value,
   replace the password in the string with the new value, and update it
   with the following command:

   .. code:: bash

      nova-manage cell_v2 update_cell --cell_uuid 00000000-0000-0000-0000-000000000000 --database_connection "CONNECTION WITH NEW PASSWORD HERE" --transport-url "none:///"

   (If the ``cell_uuid`` for ``cell0`` is not
   ``00000000-0000-0000-0000-000000000000``, change the above command
   accordingly)

Heat Domain Admin Password
^^^^^^^^^^^^^^^^^^^^^^^^^^
The keystone password for the heat domain admin service user
(``heat_domain_admin_password``) must be rotated manually.

It can be changed by an administrator just like any other standard OpenStack
user password. Generate a new password, replace the old password in
``passwords.yml``, then apply the change manually:

.. code-block:: bash

   openstack user set --password <password> heat_domain_admin --domain heat_user_domain

RabbitMQ Secrets
^^^^^^^^^^^^^^^^
RabbitMQ uses two main secrets. An Erlang cookie for cluster membership
(``rabbitmq_cluster_cookie``), and a RabbitMQ management user password
(``rabbitmq_password``). There is currently no documented process for
seamlessly rotating these secrets. Many OpenStack services use RabbitMQ for
communication and reconfiguring them with the new credentials can take some
time, resulting in a relatively long API outage.

It is recommended that you stop all services, then stop and destroy the
RabbitMQ containers and volumes. Because the RabbitMQ containers are destroyed,
``kolla-ansible deploy`` should be used to restart services rather than
``kolla-ansible reconfigure``. Detailed steps are listed below:

#. Generate a new ``rabbitmq_cluster_cookie`` and ``rabbitmq_password``.

#. Replace the old values in ``passwords.yml``.

#. Stop OpenStack services:

   .. code-block:: bash

      kolla-ansible stop -i inventory

#. On each node running RabbitMQ, destroy its containers and volumes:

   .. code-block:: bash

      docker stop rabbitmq
      docker rm rabbitmq
      docker volume rm rabbitmq

#. Redeploy services:

   .. code-block:: bash

      kolla-ansible deploy -i inventory

Post-redeploy changes
^^^^^^^^^^^^^^^^^^^^^
Once services have been redeployed, the existing Memcached data should be
flushed. The old Memcached password will no longer be used so any data stored
using it will be inaccessible.

The instructions below must be run from a host that has access to the network
the Memcached containers are using. If you are not sure, run them from a host
that is running Memcached.

#. Install a telnet client:

   .. code-block:: bash

      apt/dnf install telnet

#. Check the config for the IP and port used by Memcached (on every host
   running Memcached):

   .. code:: bash

      sudo grep command /etc/kolla/memcached/config.json

   The IP and port will be printed after ``-l`` and ``-p`` respectively

#. For each container start a Telnet session, clear all data, then
   exit:

   .. code:: bash

      telnet <ip> <port>
      flush_all
      quit

Known out-of-scope secrets
--------------------------
Below is a list of passwords that are known to be outside the scope of this
guide.

* ``docker_registry_password`` - kolla-ansible cannot manage docker registries.