9 The Ceph Dashboard is a built-in web-based Ceph management and monitoring
10 application to administer various aspects and objects of the cluster. It is
11 implemented as a :ref:`ceph-manager-daemon` module.
13 The original Ceph Dashboard that was shipped with Ceph Luminous started
14 out as a simple read-only view into various run-time information and performance
15 data of a Ceph cluster. It used a very simple architecture to achieve the
16 original goal. However, there was a growing demand for adding more web-based
17 management capabilities, to make it easier to administer Ceph for users that
18 prefer a WebUI over using the command line.
20 The new :term:`Ceph Dashboard` module is a replacement of the previous one and
21 adds a built-in web based monitoring and administration application to the Ceph
22 Manager. The architecture and functionality of this new module is derived from
23 and inspired by the `openATTIC Ceph management and monitoring tool
24 <https://openattic.org/>`_. The development is actively driven by the team
25 behind openATTIC at `SUSE <https://www.suse.com/>`_, with a lot of support from
26 companies like `Red Hat <https://redhat.com/>`_ and other members of the Ceph
29 The dashboard module's backend code uses the CherryPy framework and a custom
30 REST API implementation. The WebUI implementation is based on
31 Angular/TypeScript, merging both functionality from the original dashboard as
32 well as adding new functionality originally developed for the standalone version
33 of openATTIC. The Ceph Dashboard module is implemented as a web
34 application that visualizes information and statistics about the Ceph cluster
35 using a web server hosted by ``ceph-mgr``.
40 The dashboard provides the following features:
42 * **Multi-User and Role Management**: The dashboard supports multiple user
43 accounts with different permissions (roles). The user accounts and roles
44 can be modified on both the command line and via the WebUI. The dashboard
45 supports various methods to enhance password security, e.g. by enforcing
46 configurable password complexity rules, forcing users to change their password
47 after the first login or after a configurable time period. See
48 :ref:`dashboard-user-role-management` for details.
49 * **Single Sign-On (SSO)**: the dashboard supports authentication
50 via an external identity provider using the SAML 2.0 protocol. See
51 :ref:`dashboard-sso-support` for details.
52 * **SSL/TLS support**: All HTTP communication between the web browser and the
53 dashboard is secured via SSL. A self-signed certificate can be created with
54 a built-in command, but it's also possible to import custom certificates
55 signed and issued by a CA. See :ref:`dashboard-ssl-tls-support` for details.
56 * **Auditing**: the dashboard backend can be configured to log all PUT, POST
57 and DELETE API requests in the Ceph audit log. See :ref:`dashboard-auditing`
58 for instructions on how to enable this feature.
59 * **Internationalization (I18N)**: the dashboard can be used in different
60 languages that can be selected at run-time.
62 Currently, Ceph Dashboard is capable of monitoring and managing the following
63 aspects of your Ceph cluster:
65 * **Overall cluster health**: Display overall cluster status, performance
67 * **Embedded Grafana Dashboards**: Ceph Dashboard is capable of embedding
68 `Grafana`_ dashboards in many locations, to display additional information
69 and performance metrics gathered by the :ref:`mgr-prometheus`. See
70 :ref:`dashboard-grafana` for details on how to configure this functionality.
71 * **Cluster logs**: Display the latest updates to the cluster's event and
72 audit log files. Log entries can be filtered by priority, date or keyword.
73 * **Hosts**: Display a list of all hosts associated to the cluster, which
74 disks are attached, which services are running and which version of Ceph is
76 * **Performance counters**: Display detailed service-specific statistics for
78 * **Monitors**: List all MONs, their quorum status, open sessions.
79 * **Monitoring**: Enable creation, re-creation, editing and expiration of
80 Prometheus' silences, list the alerting configuration of Prometheus and all
81 configured and firing alerts. Show notifications for firing alerts.
82 * **Configuration Editor**: Display all available configuration options,
83 their description, type and default values and edit the current values.
84 * **Pools**: List all Ceph pools and their details (e.g. applications,
85 pg-autoscaling, placement groups, replication size, EC profile, CRUSH
86 rulesets, quotas etc.)
87 * **OSDs**: List all OSDs, their status and usage statistics as well as
88 detailed information like attributes (OSD map), metadata, performance
89 counters and usage histograms for read/write operations. Mark OSDs
90 up/down/out, purge and reweight OSDs, perform scrub operations, modify
91 various scrub-related configuration options, select different profiles to
92 adjust the level of backfilling activity. List all disks associated with an
93 OSD. Set and change the device class of an OSD, display and sort OSDs by
94 device class. Deploy new OSDs on new disks/hosts.
95 * **Device management**: List all hosts known by the orchestrator. List all
96 disks and their properties attached to a node. Display disk health information
97 (health prediction and SMART data). Blink enclosure LEDs.
98 * **iSCSI**: List all hosts that run the TCMU runner service, display all
99 images and their performance characteristics (read/write ops, traffic).
100 Create, modify and delete iSCSI targets (via ``ceph-iscsi``). Display the
101 iSCSI gateway status on the landing page and info about active initiators.
102 See :ref:`dashboard-iscsi-management` for instructions on how to configure
104 * **RBD**: List all RBD images and their properties (size, objects, features).
105 Create, copy, modify and delete RBD images (incl. snapshots) and manage RBD
106 namespaces. Define various I/O or bandwidth limitation settings on a global,
107 per-pool or per-image level. Create, delete and rollback snapshots of selected
108 images, protect/unprotect these snapshots against modification. Copy or clone
109 snapshots, flatten cloned images.
110 * **RBD mirroring**: Enable and configure RBD mirroring to a remote Ceph server.
111 Lists all active sync daemons and their status, pools and RBD images including
112 their synchronization state.
113 * **CephFS**: List all active file system clients and associated pools,
114 including their usage statistics. Evict active CephFS clients. Manage CephFS
115 quotas and snapshots. Browse a CephFS directory structure.
116 * **Object Gateway**: List all active object gateways and their performance
117 counters. Display and manage (add/edit/delete) object gateway users and their
118 details (e.g. quotas) as well as the users' buckets and their details (e.g.
119 placement targets, owner, quotas, versioning, multi-factor authentication).
120 See :ref:`dashboard-enabling-object-gateway` for configuration instructions.
121 * **NFS**: Manage NFS exports of CephFS file systems and RGW S3 buckets via NFS
122 Ganesha. See :ref:`dashboard-nfs-ganesha-management` for details on how to
123 enable this functionality.
124 * **Ceph Manager Modules**: Enable and disable all Ceph Manager modules, change
125 the module-specific configuration settings.
131 Ceph Dashboard is primarily tested and developed using the following web
134 +-----------------------------------------------+----------+
135 | Browser | Versions |
136 +===============================================+==========+
137 | `Chrome <https://www.google.com/chrome/>`_ | 68+ |
138 +-----------------------------------------------+----------+
139 | `Firefox <https://www.mozilla.org/firefox/>`_ | 61+ |
140 +-----------------------------------------------+----------+
142 While Ceph Dashboard might work in older browsers, we cannot guarantee it and
143 recommend you to update your browser to the latest version.
148 If you have installed ``ceph-mgr-dashboard`` from distribution packages, the
149 package management system should have taken care of installing all the required
152 If you're installing Ceph from source and want to start the dashboard from your
153 development environment, please see the files ``README.rst`` and ``HACKING.rst``
154 in directory ``src/pybind/mgr/dashboard`` of the source code.
156 Within a running Ceph cluster, the Ceph Dashboard is enabled with::
158 $ ceph mgr module enable dashboard
163 .. _dashboard-ssl-tls-support:
168 All HTTP connections to the dashboard are secured with SSL/TLS by default.
170 To get the dashboard up and running quickly, you can generate and install a
171 self-signed certificate using the following built-in command::
173 $ ceph dashboard create-self-signed-cert
175 Note that most web browsers will complain about such self-signed certificates
176 and require explicit confirmation before establishing a secure connection to the
179 To properly secure a deployment and to remove the certificate warning, a
180 certificate that is issued by a certificate authority (CA) should be used.
182 For example, a key pair can be generated with a command similar to::
184 $ openssl req -new -nodes -x509 \
185 -subj "/O=IT/CN=ceph-mgr-dashboard" -days 3650 \
186 -keyout dashboard.key -out dashboard.crt -extensions v3_ca
188 The ``dashboard.crt`` file should then be signed by a CA. Once that is done, you
189 can enable it for all Ceph manager instances by running the following commands::
191 $ ceph dashboard set-ssl-certificate -i dashboard.crt
192 $ ceph dashboard set-ssl-certificate-key -i dashboard.key
194 If different certificates are desired for each manager instance for some reason,
195 the name of the instance can be included as follows (where ``$name`` is the name
196 of the ``ceph-mgr`` instance, usually the hostname)::
198 $ ceph dashboard set-ssl-certificate $name -i dashboard.crt
199 $ ceph dashboard set-ssl-certificate-key $name -i dashboard.key
201 SSL can also be disabled by setting this configuration value::
203 $ ceph config set mgr mgr/dashboard/ssl false
205 This might be useful if the dashboard will be running behind a proxy which does
206 not support SSL for its upstream servers or other situations where SSL is not
207 wanted or required. See :ref:`dashboard-proxy-configuration` for more details.
211 Use caution when disabling SSL as usernames and passwords will be sent to the
212 dashboard unencrypted.
217 You need to restart the Ceph manager processes manually after changing the SSL
218 certificate and key. This can be accomplished by either running ``ceph mgr
219 fail mgr`` or by disabling and re-enabling the dashboard module (which also
220 triggers the manager to respawn itself)::
222 $ ceph mgr module disable dashboard
223 $ ceph mgr module enable dashboard
228 Like most web applications, dashboard binds to a TCP/IP address and TCP port.
230 By default, the ``ceph-mgr`` daemon hosting the dashboard (i.e., the currently
231 active manager) will bind to TCP port 8443 or 8080 when SSL is disabled.
233 If no specific address has been configured, the web app will bind to ``::``,
234 which corresponds to all available IPv4 and IPv6 addresses.
236 These defaults can be changed via the configuration key facility on a
237 cluster-wide level (so they apply to all manager instances) as follows::
239 $ ceph config set mgr mgr/dashboard/server_addr $IP
240 $ ceph config set mgr mgr/dashboard/server_port $PORT
241 $ ceph config set mgr mgr/dashboard/ssl_server_port $PORT
243 Since each ``ceph-mgr`` hosts its own instance of dashboard, it may also be
244 necessary to configure them separately. The IP address and port for a specific
245 manager instance can be changed with the following commands::
247 $ ceph config set mgr mgr/dashboard/$name/server_addr $IP
248 $ ceph config set mgr mgr/dashboard/$name/server_port $PORT
249 $ ceph config set mgr mgr/dashboard/$name/ssl_server_port $PORT
251 Replace ``$name`` with the ID of the ceph-mgr instance hosting the dashboard web
256 The command ``ceph mgr services`` will show you all endpoints that are
257 currently configured. Look for the ``dashboard`` key to obtain the URL for
258 accessing the dashboard.
260 Username and Password
261 ^^^^^^^^^^^^^^^^^^^^^
263 In order to be able to log in, you need to create a user account and associate
264 it with at least one role. We provide a set of predefined *system roles* that
265 you can use. For more details please refer to the `User and Role Management`_
268 To create a user with the administrator role you can use the following
271 $ ceph dashboard ac-user-create <username> <password> administrator
273 Accessing the Dashboard
274 ^^^^^^^^^^^^^^^^^^^^^^^
276 You can now access the dashboard using your (JavaScript-enabled) web browser, by
277 pointing it to any of the host names or IP addresses and the selected TCP port
278 where a manager instance is running: e.g., ``http(s)://<$IP>:<$PORT>/``.
280 You should then be greeted by the dashboard login page, requesting your
281 previously defined username and password.
283 .. _dashboard-enabling-object-gateway:
285 Enabling the Object Gateway Management Frontend
286 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
288 To use the Object Gateway management functionality of the dashboard, you will
289 need to provide the login credentials of a user with the ``system`` flag
292 If you do not have a user which shall be used for providing those credentials,
293 you will also need to create one::
295 $ radosgw-admin user create --uid=<user_id> --display-name=<display_name> \
298 Take note of the keys ``access_key`` and ``secret_key`` in the output of this
301 The credentials of an existing user can also be obtained by using
304 $ radosgw-admin user info --uid=<user_id>
306 Finally, provide the credentials to the dashboard::
308 $ ceph dashboard set-rgw-api-access-key <access_key>
309 $ ceph dashboard set-rgw-api-secret-key <secret_key>
311 In a typical default configuration with a single RGW endpoint, this is all you
312 have to do to get the Object Gateway management functionality working. The
313 dashboard will try to automatically determine the host and port of the Object
314 Gateway by obtaining this information from the Ceph Manager's service map.
316 If multiple zones are used, it will automatically determine the host within the
317 master zone group and master zone. This should be sufficient for most setups,
318 but in some circumstances you might want to set the host and port manually::
320 $ ceph dashboard set-rgw-api-host <host>
321 $ ceph dashboard set-rgw-api-port <port>
323 In addition to the settings mentioned so far, the following settings do also
324 exist and you may find yourself in the situation that you have to use them::
326 $ ceph dashboard set-rgw-api-scheme <scheme> # http or https
327 $ ceph dashboard set-rgw-api-admin-resource <admin_resource>
328 $ ceph dashboard set-rgw-api-user-id <user_id>
330 If you are using a self-signed certificate in your Object Gateway setup, then
331 you should disable certificate verification in the dashboard to avoid refused
332 connections, e.g. caused by certificates signed by unknown CA or not matching
335 $ ceph dashboard set-rgw-api-ssl-verify False
337 If the Object Gateway takes too long to process requests and the dashboard runs
338 into timeouts, then you can set the timeout value to your needs::
340 $ ceph dashboard set-rest-requests-timeout <seconds>
342 The default value is 45 seconds.
344 .. _dashboard-iscsi-management:
346 Enabling iSCSI Management
347 ^^^^^^^^^^^^^^^^^^^^^^^^^
349 The Ceph Dashboard can manage iSCSI targets using the REST API provided by the
350 `rbd-target-api` service of the :ref:`ceph-iscsi`. Please make sure that it's
351 installed and enabled on the iSCSI gateways.
355 The iSCSI management functionality of Ceph Dashboard depends on the latest
356 version 3 of the `ceph-iscsi <https://github.com/ceph/ceph-iscsi>`_ project.
357 Make sure that your operating system provides the correct version, otherwise
358 the dashboard won't enable the management features.
360 If ceph-iscsi REST API is configured in HTTPS mode and its using a self-signed
361 certificate, then you need to configure the dashboard to avoid SSL certificate
362 verification when accessing ceph-iscsi API.
364 To disable API SSL verification run the following command::
366 $ ceph dashboard set-iscsi-api-ssl-verification false
368 The available iSCSI gateways must be defined using the following commands::
370 $ ceph dashboard iscsi-gateway-list
371 $ ceph dashboard iscsi-gateway-add <scheme>://<username>:<password>@<host>[:port]
372 $ ceph dashboard iscsi-gateway-rm <gateway_name>
375 .. _dashboard-grafana:
377 Enabling the Embedding of Grafana Dashboards
378 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
380 `Grafana`_ requires data from `Prometheus <https://prometheus.io/>`_. Although
381 Grafana can use other data sources, the Grafana dashboards we provide contain
382 queries that are specific to Prometheus. Our Grafana dashboards therefore
383 require Prometheus as the data source. The Ceph :ref:`mgr-prometheus` also only
384 exports its data in the Prometheus' common format. The Grafana dashboards rely
385 on metric names from the Prometheus module and `Node exporter
386 <https://prometheus.io/docs/guides/node-exporter/>`_. The Node exporter is a
387 separate application that provides machine metrics.
391 Prometheus' security model presumes that untrusted users have access to the
392 Prometheus HTTP endpoint and logs. Untrusted users have access to all the
393 (meta)data Prometheus collects that is contained in the database, plus a
394 variety of operational and debugging information.
396 However, Prometheus' HTTP API is limited to read-only operations.
397 Configurations can *not* be changed using the API and secrets are not
398 exposed. Moreover, Prometheus has some built-in measures to mitigate the
399 impact of denial of service attacks.
401 Please see `Prometheus' Security model
402 <https://prometheus.io/docs/operating/security/>` for more detailed
405 Grafana and Prometheus are likely going to be bundled and installed by some
406 orchestration tools along Ceph in the near future, but currently, you will have
407 to install and configure both manually. After you have installed Prometheus and
408 Grafana on your preferred hosts, proceed with the following steps.
410 1. Enable the Ceph Exporter which comes as Ceph Manager module by running::
412 $ ceph mgr module enable prometheus
414 More details can be found in the documentation of the :ref:`mgr-prometheus`.
416 2. Add the corresponding scrape configuration to Prometheus. This may look
423 - job_name: 'prometheus'
425 - targets: ['localhost:9090']
428 - targets: ['localhost:9283']
429 - job_name: 'node-exporter'
431 - targets: ['localhost:9100']
433 3. Add Prometheus as data source to Grafana
435 4. Install the `vonage-status-panel and grafana-piechart-panel` plugins using::
437 grafana-cli plugins install vonage-status-panel
438 grafana-cli plugins install grafana-piechart-panel
440 5. Add the Dashboards to Grafana:
442 Dashboards can be added to Grafana by importing dashboard jsons.
443 Following command can be used for downloading json files::
445 wget https://raw.githubusercontent.com/ceph/ceph/master/monitoring/grafana/dashboards/<Dashboard-name>.json
447 You can find all the dashboard jsons `here <https://github.com/ceph/ceph/tree/
448 master/monitoring/grafana/dashboards>`_ .
450 For Example, for ceph-cluster overview you can use::
452 wget https://raw.githubusercontent.com/ceph/ceph/master/monitoring/grafana/dashboards/ceph-cluster.json
454 6. Configure Grafana in `/etc/grafana/grafana.ini` to adapt anonymous mode::
461 In newer versions of Grafana (starting with 6.2.0-beta1) a new setting named
462 ``allow_embedding`` has been introduced. This setting needs to be explicitly
463 set to ``true`` for the Grafana integration in Ceph Dashboard to work, as its
464 default is ``false``.
469 allow_embedding = true
471 After you have set up Grafana and Prometheus, you will need to configure the
472 connection information that the Ceph Dashboard will use to access Grafana.
474 You need to tell the dashboard on which url Grafana instance is running/deployed::
476 $ ceph dashboard set-grafana-api-url <grafana-server-url> # default: ''
478 The format of url is : `<protocol>:<IP-address>:<port>`
482 Ceph Dashboard embeds the Grafana dashboards via ``iframe`` HTML elements.
483 If Grafana is configured without SSL/TLS support, most browsers will block the
484 embedding of insecure content into a secured web page, if the SSL support in
485 the dashboard has been enabled (which is the default configuration). If you
486 can't see the embedded Grafana dashboards after enabling them as outlined
487 above, check your browser's documentation on how to unblock mixed content.
488 Alternatively, consider enabling SSL/TLS support in Grafana.
490 If you are using a self-signed certificate in your Grafana setup, then you should
491 disable certificate verification in the dashboard to avoid refused connections,
492 e.g. caused by certificates signed by unknown CA or not matching the host name::
494 $ ceph dashboard set-grafana-api-ssl-verify False
496 You can directly access Grafana Instance as well to monitor your cluster.
498 .. _dashboard-sso-support:
500 Enabling Single Sign-On (SSO)
501 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
503 The Ceph Dashboard supports external authentication of users via the
504 `SAML 2.0 <https://en.wikipedia.org/wiki/SAML_2.0>`_ protocol. You need to create
505 the user accounts and associate them with the desired roles first, as authorization
506 is still performed by the Dashboard. However, the authentication process can be
507 performed by an existing Identity Provider (IdP).
511 Ceph Dashboard SSO support relies on onelogin's
512 `python-saml <https://pypi.org/project/python-saml/>`_ library.
513 Please ensure that this library is installed on your system, either by using
514 your distribution's package management or via Python's `pip` installer.
516 To configure SSO on Ceph Dashboard, you should use the following command::
518 $ ceph dashboard sso setup saml2 <ceph_dashboard_base_url> <idp_metadata> {<idp_username_attribute>} {<idp_entity_id>} {<sp_x_509_cert>} {<sp_private_key>}
522 * **<ceph_dashboard_base_url>**: Base URL where Ceph Dashboard is accessible (e.g., `https://cephdashboard.local`)
523 * **<idp_metadata>**: URL to remote (`http://`, `https://`) or local (`file://`) path or content of the IdP metadata XML (e.g., `https://myidp/metadata`, `file:///home/myuser/metadata.xml`).
524 * **<idp_username_attribute>** *(optional)*: Attribute that should be used to get the username from the authentication response. Defaults to `uid`.
525 * **<idp_entity_id>** *(optional)*: Use this when more than one entity id exists on the IdP metadata.
526 * **<sp_x_509_cert> / <sp_private_key>** *(optional)*: File path of the certificate that should be used by Ceph Dashboard (Service Provider) for signing and encryption.
530 The issuer value of SAML requests will follow this pattern: **<ceph_dashboard_base_url>**/auth/saml2/metadata
532 To display the current SAML 2.0 configuration, use the following command::
534 $ ceph dashboard sso show saml2
538 For more information about `onelogin_settings`, please check the `onelogin documentation <https://github.com/onelogin/python-saml>`_.
542 $ ceph dashboard sso disable
544 To check if SSO is enabled::
546 $ ceph dashboard sso status
550 $ ceph dashboard sso enable saml2
552 .. _dashboard-alerting:
554 Enabling Prometheus Alerting
555 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
557 Using Prometheus for monitoring, you have to define `alerting rules
558 <https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules>`_.
559 To manage them you need to use the `Alertmanager
560 <https://prometheus.io/docs/alerting/alertmanager>`_.
561 If you are not using the Alertmanager yet, please `install it
562 <https://github.com/prometheus/alertmanager#install>`_ as it's mandatory in
563 order to receive and manage alerts from Prometheus.
565 The Alertmanager capabilities can be consumed by the dashboard in three different
568 #. Use the notification receiver of the dashboard.
570 #. Use the Prometheus Alertmanager API.
572 #. Use both sources simultaneously.
574 All three methods are going to notify you about alerts. You won't be notified
575 twice if you use both sources, but you need to consume at least the Alertmanager API
576 in order to manage silences.
578 1. Use the notification receiver of the dashboard
580 This allows you to get notifications as `configured
581 <https://prometheus.io/docs/alerting/configuration/>`_ from the Alertmanager.
582 You will get notified inside the dashboard once a notification is send out,
583 but you are not able to manage alerts.
585 Add the dashboard receiver and the new route to your Alertmanager
586 configuration. This should look like::
589 receiver: 'ceph-dashboard'
592 - name: 'ceph-dashboard'
594 - url: '<url-to-dashboard>/api/prometheus_receiver'
597 Please make sure that the Alertmanager considers your SSL certificate in terms
598 of the dashboard as valid. For more information about the correct
599 configuration checkout the `<http_config> documentation
600 <https://prometheus.io/docs/alerting/configuration/#%3Chttp_config%3E>`_.
602 2. Use the API of Prometheus and the Alertmanager
604 This allows you to manage alerts and silences. This will enable the "Active
605 Alerts", "All Alerts" as well as the "Silences" tabs in the "Monitoring"
606 section of the "Cluster" menu entry.
608 Alerts can be sorted by name, job, severity, state and start time.
609 Unfortunately it's not possible to know when an alert was sent out through a
610 notification by the Alertmanager based on your configuration, that's why the
611 dashboard will notify the user on any visible change to an alert and will
612 notify the changed alert.
614 Silences can be sorted by id, creator, status, start, updated and end time.
615 Silences can be created in various ways, it's also possible to expire them.
617 #. Create from scratch
619 #. Based on a selected alert
621 #. Recreate from expired silence
623 #. Update a silence (which will recreate and expire it (default Alertmanager behaviour))
625 To use it, specify the host and port of the Alertmanager server::
627 $ ceph dashboard set-alertmanager-api-host <alertmanager-host:port> # default: ''
631 $ ceph dashboard set-alertmanager-api-host 'http://localhost:9093'
633 To be able to see all configured alerts, you will need to configure the URL to
634 the Prometheus API. Using this API, the UI will also help you in verifying
635 that a new silence will match a corresponding alert.
639 $ ceph dashboard set-prometheus-api-host <prometheus-host:port> # default: ''
643 $ ceph dashboard set-prometheus-api-host 'http://localhost:9090'
645 After setting up the hosts, you have to refresh the dashboard in your browser window.
649 The different behaviors of both methods are configured in a way that they
650 should not disturb each other through annoying duplicated notifications
653 .. _dashboard-user-role-management:
655 User and Role Management
656 ------------------------
661 By default the password policy feature is enabled including the following
664 - Is the password longer than N characters?
665 - Are the old and new password the same?
667 The password policy feature can be switched on or off completely::
669 $ ceph dashboard set-pwd-policy-enabled <true|false>
671 The following individual checks can be switched on or off::
673 $ ceph dashboard set-pwd-policy-check-length-enabled <true|false>
674 $ ceph dashboard set-pwd-policy-check-oldpwd-enabled <true|false>
675 $ ceph dashboard set-pwd-policy-check-username-enabled <true|false>
676 $ ceph dashboard set-pwd-policy-check-exclusion-list-enabled <true|false>
677 $ ceph dashboard set-pwd-policy-check-complexity-enabled <true|false>
678 $ ceph dashboard set-pwd-policy-check-sequential-chars-enabled <true|false>
679 $ ceph dashboard set-pwd-policy-check-repetitive-chars-enabled <true|false>
681 Additionally the following options are available to configure the password
684 - The minimum password length (defaults to 8)::
686 $ ceph dashboard set-pwd-policy-min-length <N>
688 - The minimum password complexity (defaults to 10)::
690 $ ceph dashboard set-pwd-policy-min-complexity <N>
692 The password complexity is calculated by classifying each character in
693 the password. The complexity count starts by 0. A character is rated by
694 the following rules in the given order.
696 - Increase by 1 if the character is a digit.
697 - Increase by 1 if the character is a lower case ASCII character.
698 - Increase by 2 if the character is an upper case ASCII character.
699 - Increase by 3 if the character is a special character like ``!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~``.
700 - Increase by 5 if the character has not been classified by one of the previous rules.
702 - A list of comma separated words that are not allowed to be used in a
705 $ ceph dashboard set-pwd-policy-exclusion-list <word>[,...]
711 Ceph Dashboard supports managing multiple user accounts. Each user account
712 consists of a username, a password (stored in encrypted form using ``bcrypt``),
713 an optional name, and an optional email address.
715 If a new user is created via Web UI, it is possible to set an option that this
716 user must assign a new password when they log in for the first time.
718 User accounts are stored in MON's configuration database, and are globally
719 shared across all ceph-mgr instances.
721 We provide a set of CLI commands to manage user accounts:
725 $ ceph dashboard ac-user-show [<username>]
729 $ ceph dashboard ac-user-create [--enabled] [--force-password] [--pwd_update_required] <username> [<password>] [<rolename>] [<name>] [<email>] [<pwd_expiration_date>]
731 To bypass the password policy checks use the `force-password` option.
732 Use the option `pwd_update_required` so that a newly created user has
733 to change their password after the first login.
737 $ ceph dashboard ac-user-delete <username>
739 - *Change Password*::
741 $ ceph dashboard ac-user-set-password [--force-password] <username> <password>
743 - *Change Password Hash*::
745 $ ceph dashboard ac-user-set-password-hash <username> <hash>
747 The hash must be a bcrypt hash and salt, e.g. ``$2b$12$Pt3Vq/rDt2y9glTPSV.VFegiLkQeIpddtkhoFetNApYmIJOY8gau2``.
748 This can be used to import users from an external database.
750 - *Modify User (name, and email)*::
752 $ ceph dashboard ac-user-set-info <username> <name> <email>
756 $ ceph dashboard ac-user-disable <username>
760 $ ceph dashboard ac-user-enable <username>
762 User Roles and Permissions
763 ^^^^^^^^^^^^^^^^^^^^^^^^^^
765 User accounts are also associated with a set of roles that define which
766 dashboard functionality can be accessed by the user.
768 The Dashboard functionality/modules are grouped within a *security scope*.
769 Security scopes are predefined and static. The current available security
772 - **hosts**: includes all features related to the ``Hosts`` menu
774 - **config-opt**: includes all features related to management of Ceph
775 configuration options.
776 - **pool**: includes all features related to pool management.
777 - **osd**: includes all features related to OSD management.
778 - **monitor**: includes all features related to Monitor management.
779 - **rbd-image**: includes all features related to RBD image
781 - **rbd-mirroring**: includes all features related to RBD-Mirroring
783 - **iscsi**: includes all features related to iSCSI management.
784 - **rgw**: includes all features related to Rados Gateway management.
785 - **cephfs**: includes all features related to CephFS management.
786 - **manager**: include all features related to Ceph Manager
788 - **log**: include all features related to Ceph logs management.
789 - **grafana**: include all features related to Grafana proxy.
790 - **prometheus**: include all features related to Prometheus alert management.
791 - **dashboard-settings**: allows to change dashboard settings.
793 A *role* specifies a set of mappings between a *security scope* and a set of
794 *permissions*. There are four types of permissions:
801 See below for an example of a role specification based on a Python dictionary::
805 'role': 'my_new_role',
806 'description': 'My new role',
807 'scopes_permissions': {
808 'pool': ['read', 'create'],
809 'rbd-image': ['read', 'create', 'update', 'delete']
813 The above role dictates that a user has *read* and *create* permissions for
814 features related to pool management, and has full permissions for
815 features related to RBD image management.
817 The Dashboard already provides a set of predefined roles that we call
818 *system roles*, and can be used right away in a fresh Ceph Dashboard
821 The list of system roles are:
823 - **administrator**: provides full permissions for all security scopes.
824 - **read-only**: provides *read* permission for all security scopes except
825 the dashboard settings.
826 - **block-manager**: provides full permissions for *rbd-image*,
827 *rbd-mirroring*, and *iscsi* scopes.
828 - **rgw-manager**: provides full permissions for the *rgw* scope
829 - **cluster-manager**: provides full permissions for the *hosts*, *osd*,
830 *monitor*, *manager*, and *config-opt* scopes.
831 - **pool-manager**: provides full permissions for the *pool* scope.
832 - **cephfs-manager**: provides full permissions for the *cephfs* scope.
834 The list of currently available roles can be retrieved by the following
837 $ ceph dashboard ac-role-show [<rolename>]
839 It is also possible to create new roles using CLI commands. The available
840 commands to manage roles are the following:
844 $ ceph dashboard ac-role-create <rolename> [<description>]
848 $ ceph dashboard ac-role-delete <rolename>
850 - *Add Scope Permissions to Role*::
852 $ ceph dashboard ac-role-add-scope-perms <rolename> <scopename> <permission> [<permission>...]
854 - *Delete Scope Permission from Role*::
856 $ ceph dashboard ac-role-del-scope-perms <rolename> <scopename>
858 To associate roles to users, the following CLI commands are available:
862 $ ceph dashboard ac-user-set-roles <username> <rolename> [<rolename>...]
864 - *Add Roles To User*::
866 $ ceph dashboard ac-user-add-roles <username> <rolename> [<rolename>...]
868 - *Delete Roles from User*::
870 $ ceph dashboard ac-user-del-roles <username> <rolename> [<rolename>...]
873 Example of User and Custom Role Creation
874 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
876 In this section we show a full example of the commands that need to be used
877 in order to create a user account, that should be able to manage RBD images,
878 view and create Ceph pools, and have read-only access to any other scopes.
880 1. *Create the user*::
882 $ ceph dashboard ac-user-create bob mypassword
884 2. *Create role and specify scope permissions*::
886 $ ceph dashboard ac-role-create rbd/pool-manager
887 $ ceph dashboard ac-role-add-scope-perms rbd/pool-manager rbd-image read create update delete
888 $ ceph dashboard ac-role-add-scope-perms rbd/pool-manager pool read create
890 3. *Associate roles to user*::
892 $ ceph dashboard ac-user-set-roles bob rbd/pool-manager read-only
894 .. _dashboard-proxy-configuration:
899 In a Ceph cluster with multiple ceph-mgr instances, only the dashboard running
900 on the currently active ceph-mgr daemon will serve incoming requests. Accessing
901 the dashboard's TCP port on any of the other ceph-mgr instances that are
902 currently on standby will perform a HTTP redirect (303) to the currently active
903 manager's dashboard URL. This way, you can point your browser to any of the
904 ceph-mgr instances in order to access the dashboard.
906 If you want to establish a fixed URL to reach the dashboard or if you don't want
907 to allow direct connections to the manager nodes, you could set up a proxy that
908 automatically forwards incoming requests to the currently active ceph-mgr
911 Configuring a URL Prefix
912 ^^^^^^^^^^^^^^^^^^^^^^^^
914 If you are accessing the dashboard via a reverse proxy configuration,
915 you may wish to service it under a URL prefix. To get the dashboard
916 to use hyperlinks that include your prefix, you can set the
917 ``url_prefix`` setting:
921 ceph config set mgr mgr/dashboard/url_prefix $PREFIX
923 so you can access the dashboard at ``http://$IP:$PORT/$PREFIX/``.
925 Disable the redirection
926 ^^^^^^^^^^^^^^^^^^^^^^^
928 If the dashboard is behind a load-balancing proxy like `HAProxy <https://www.haproxy.org/>`_
929 you might want to disable the redirection behaviour to prevent situations that
930 internal (unresolvable) URL's are published to the frontend client. Use the
931 following command to get the dashboard to respond with a HTTP error (500 by default)
932 instead of redirecting to the active dashboard::
934 $ ceph config set mgr mgr/dashboard/standby_behaviour "error"
936 To reset the setting to the default redirection behaviour, use the following command::
938 $ ceph config set mgr mgr/dashboard/standby_behaviour "redirect"
940 Configure the error status code
941 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
943 When the redirection behaviour is disabled, then you want to customize the HTTP status
944 code of standby dashboards. To do so you need to run the command::
946 $ ceph config set mgr mgr/dashboard/standby_error_status_code 503
948 HAProxy example configuration
949 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
951 Below you will find an example configuration for SSL/TLS pass through using
952 `HAProxy <https://www.haproxy.org/>`_.
954 Please note that the configuration works under the following conditions.
955 If the dashboard fails over, the front-end client might receive a HTTP redirect
956 (303) response and will be redirected to an unresolvable host. This happens when
957 the failover occurs during two HAProxy health checks. In this situation the
958 previously active dashboard node will now respond with a 303 which points to
959 the new active node. To prevent that situation you should consider to disable
960 the redirection behaviour on standby nodes.
966 option log-health-checks
971 frontend dashboard_front
975 redirect scheme https code 301 if !{ ssl_fc }
977 frontend dashboard_front_ssl
981 default_backend dashboard_back_ssl
983 backend dashboard_back_ssl
986 http-check expect status 200
987 server x <HOST>:<PORT> check-ssl check verify none
988 server y <HOST>:<PORT> check-ssl check verify none
989 server z <HOST>:<PORT> check-ssl check verify none
991 .. _dashboard-auditing:
993 Auditing API Requests
994 ---------------------
996 The REST API is capable of logging PUT, POST and DELETE requests to the Ceph
997 audit log. This feature is disabled by default, but can be enabled with the
1000 $ ceph dashboard set-audit-api-enabled <true|false>
1002 If enabled, the following parameters are logged per each request:
1004 * from - The origin of the request, e.g. https://[::1]:44410
1005 * path - The REST API path, e.g. /api/auth
1006 * method - e.g. PUT, POST or DELETE
1007 * user - The name of the user, otherwise 'None'
1009 The logging of the request payload (the arguments and their values) is enabled
1010 by default. Execute the following command to disable this behaviour::
1012 $ ceph dashboard set-audit-api-log-payload <true|false>
1014 A log entry may look like this::
1016 2018-10-22 15:27:01.302514 mgr.x [INF] [DASHBOARD] from='https://[::ffff:127.0.0.1]:37022' path='/api/rgw/user/klaus' method='PUT' user='admin' params='{"max_buckets": "1000", "display_name": "Klaus Mustermann", "uid": "klaus", "suspended": "0", "email": "klaus.mustermann@ceph.com"}'
1018 .. _dashboard-nfs-ganesha-management:
1020 NFS-Ganesha Management
1021 ----------------------
1023 Ceph Dashboard can manage `NFS Ganesha <http://nfs-ganesha.github.io/>`_ exports that use
1024 CephFS or RadosGW as their backstore.
1026 To enable this feature in Ceph Dashboard there are some assumptions that need
1027 to be met regarding the way NFS-Ganesha services are configured.
1029 The dashboard manages NFS-Ganesha config files stored in RADOS objects on the Ceph Cluster.
1030 NFS-Ganesha must store part of their configuration in the Ceph cluster.
1032 These configuration files must follow some conventions.
1033 Each export block must be stored in its own RADOS object named
1034 ``export-<id>``, where ``<id>`` must match the ``Export_ID`` attribute of the
1035 export configuration. Then, for each NFS-Ganesha service daemon there should
1036 exist a RADOS object named ``conf-<daemon_id>``, where ``<daemon_id>`` is an
1037 arbitrary string that should uniquely identify the daemon instance (e.g., the
1038 hostname where the daemon is running).
1039 Each ``conf-<daemon_id>`` object contains the RADOS URLs to the exports that
1040 the NFS-Ganesha daemon should serve. These URLs are of the form::
1042 %url rados://<pool_name>[/<namespace>]/export-<id>
1044 Both the ``conf-<daemon_id>`` and ``export-<id>`` objects must be stored in the
1045 same RADOS pool/namespace.
1048 Configuring NFS-Ganesha in the Dashboard
1049 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1051 To enable the management of NFS-Ganesha exports in Ceph Dashboard, we only
1052 need to tell the Dashboard, in which RADOS pool and namespace the
1053 configuration objects are stored. Then, Ceph Dashboard can access the objects
1054 by following the naming convention described above.
1056 The Dashboard command to configure the NFS-Ganesha configuration objects
1059 $ ceph dashboard set-ganesha-clusters-rados-pool-namespace <pool_name>[/<namespace>]
1061 After running the above command, Ceph Dashboard is able to find the NFS-Ganesha
1062 configuration objects and we can start manage the exports through the Web UI.
1065 Support for Multiple NFS-Ganesha Clusters
1066 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1068 Ceph Dashboard also supports the management of NFS-Ganesha exports belonging
1069 to different NFS-Ganesha clusters. An NFS-Ganesha cluster is a group of
1070 NFS-Ganesha service daemons sharing the same exports. Different NFS-Ganesha
1071 clusters are independent and don't share the exports configuration between each
1074 Each NFS-Ganesha cluster should store its configuration objects in a
1075 different RADOS pool/namespace to isolate the configuration from each other.
1077 To specify the locations of the configuration of each NFS-Ganesha cluster we
1078 can use the same command as above but with a different value pattern::
1080 $ ceph dashboard set-ganesha-clusters-rados-pool-namespace <cluster_id>:<pool_name>[/<namespace>](,<cluster_id>:<pool_name>[/<namespace>])*
1082 The ``<cluster_id>`` is an arbitrary string that should uniquely identify the
1083 NFS-Ganesha cluster.
1085 When configuring the Ceph Dashboard with multiple NFS-Ganesha clusters, the
1086 Web UI will automatically allow to choose to which cluster an export belongs.
1092 Dashboard Plug-ins extend the functionality of the dashboard in a modular
1093 and loosely coupled fashion.
1095 .. _Grafana: https://grafana.com/
1097 .. include:: dashboard_plugins/feature_toggles.inc.rst
1098 .. include:: dashboard_plugins/debug.inc.rst
1101 Troubleshooting the Dashboard
1102 -----------------------------
1104 Locating the Dashboard
1105 ^^^^^^^^^^^^^^^^^^^^^^
1107 If you are unsure of the location of the Ceph Dashboard, run the following command::
1109 $ ceph mgr services | jq .dashboard
1112 The command returns the URL where the Ceph Dashboard is located: ``https://<host>:<port>/``
1116 Many Ceph command line tools return results in JSON format. You may have to install
1117 the `jq <https://stedolan.github.io/jq>`_ command-line JSON processor utility on
1118 your operating system beforehand.
1121 Accessing the Dashboard
1122 ^^^^^^^^^^^^^^^^^^^^^^^
1124 If you are unable to access the Ceph Dashboard, run through the following
1127 #. Verify the Ceph Dashboard module is enabled::
1129 $ ceph mgr module ls | jq .enabled_modules
1131 Ensure the Ceph Dashboard module is listed in the return value of the
1132 command. Example snipped output from the command above::
1140 #. If it is not listed, activate the module with the following command::
1142 $ ceph mgr module enable dashboard
1144 #. Check the Ceph Dashboard and/or mgr log file for any errors. The exact
1145 location of the log files depends on the Ceph configuration.
1147 * Check if mgr log messages are written to a file by::
1149 $ ceph config get mgr log_to_file
1152 * Get the location of the log file (it's ``/var/log/ceph/<cluster-name>-<daemon-name>.log``
1155 $ ceph config get mgr log_file
1156 /var/log/ceph/$cluster-$name.log
1158 #. Ensure the SSL/TSL support is configured properly:
1160 * Check if the SSL/TSL support is enabled::
1162 $ ceph config get mgr mgr/dashboard/ssl
1164 * If the command returns ``true``, verify a certificate exists by::
1166 $ ceph config-key get mgr/dashboard/crt
1170 $ ceph config-key get mgr/dashboard/key
1172 * If it doesn't, run the following command to generate a self-signed
1173 certificate or follow the instructions outlined in
1174 :ref:`dashboard-ssl-tls-support`::
1176 $ ceph dashboard create-self-signed-cert
1179 Trouble Logging into the Dashboard
1180 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1182 If you are unable to log into the Ceph Dashboard and you receive the following
1183 error, run through the procedural checks below:
1185 .. image:: ../images/dashboard/invalid-credentials.png
1188 #. Check that your user credentials are correct. If you are seeing the
1189 notification message above when trying to log into the Ceph Dashboard, it
1190 is likely you are using the wrong credentials. Double check your username
1191 and password, and ensure the caps lock key is not enabled by accident.
1193 #. If your user credentials are correct, but you are experiencing the same
1194 error, check that the user account exists::
1196 $ ceph dashboard ac-user-show <username>
1198 This command returns your user data. If the user does not exist, it will
1201 $ Error ENOENT: User <username> does not exist
1203 #. Check if the user is enabled::
1205 $ ceph dashboard ac-user-show <username> | jq .enabled
1208 Check if ``enabled`` is set to ``true`` for your user. If not the user is
1211 $ ceph dashboard ac-user-enable <username>
1213 Please see :ref:`dashboard-user-role-management` for more information.
1216 A Dashboard Feature is Not Working
1217 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1219 When an error occurs on the backend, you will usually receive an error
1220 notification on the frontend. Run through the following scenarios to debug.
1222 #. Check the Ceph Dashboard/mgr logfile(s) for any errors. These can be
1223 identified by searching for keywords, such as *500 Internal Server Error*,
1224 followed by ``traceback``. The end of a traceback contains more details about
1225 what exact error occurred.
1226 #. Check your web browser's Javascript Console for any errors.
1232 Dashboard Debug Flag
1233 ''''''''''''''''''''
1235 With this flag enabled, traceback of errors are included in backend responses.
1237 To enable this flag via the Ceph Dashboard, navigate from *Cluster* to *Manager
1238 modules*. Select *Dashboard module* and click the edit button. Click the
1239 *debug* checkbox and update.
1241 To enable it via the CLI, run the following command::
1243 $ ceph dashboard debug enable
1246 Setting Logging Level of Dashboard Module
1247 '''''''''''''''''''''''''''''''''''''''''
1249 Setting the logging level to debug makes the log more verbose and helpful for
1252 #. Increase the logging level of manager daemons::
1254 $ ceph tell mgr config set debug_mgr 20
1256 #. Adjust the logging level of the Ceph Dashboard module via the Dashboard or
1259 * Navigate from *Cluster* to *Manager modules*. Select *Dashboard module*
1260 and click the edit button. Modify the ``log_level`` configuration.
1261 * To adjust it via the CLI, run the following command::
1263 $ bin/ceph config set mgr mgr/dashboard/log_level debug