Ceph » mgr » Dashboard

I had a similar problem implementing https://github.com/ceph/ceph/pull/32680. There was a need to get some settings exposed to the UI but for users without configOpts privileges. I enhanced the already existing /ui-api/standard_settings endpoint (see https://github.com/ceph/ceph/pull/32680/files#diff-c3a875d99d1cd079a9e1f9b86dbe8195R92), but this would not fit in the future when there is the need to expose more settings in such a case. Currently i do not have any idea how to improve the privilege model, but i have the strong feeling that it requires some refactoring.

Good observation; thanks for bringing this up!

About your first suggestion: I think the term guest is too generic and may leave users confused about what this could be used for.

The original intention of the readonly role was being able to have these user to log into the dashboard and to view that cluster's health state and current configuration (e.g. Pools and services), which includes it's config settings, but does not allow making any changes to any object or entity of the cluster. But there's indeed a potential risk that this gives these users a way to obtain credentials that would allow them to elevate their privileges for certain services outside of using the dashboard.

Renaming a role during an upgrade may be more complicated than simply updating it's privileges. I'm fine with revoking access to configOpts in general for the readonly role, otherwise we'd end up with maintaining black/whitelists of which config options should be accessible (but maybe such a black/whitelist filter for config options would be desirable?)

I also agree to your other two suggested next steps:

• Make pool-form get osd_pool_default_pg_autoscale_mode from /pool/_info.
• Remove configOpt read perm (and test) in all other roles.

Lenz Grimmer wrote:

..., otherwise we'd end up with maintaining black/whitelists of which config options should be accessible (but maybe such a black/whitelist filter for config options would be desirable?)

I'm not sure if there is a way around it. As Volker already wrote, we do have some config options that are required by any user to be able to log into the dashboard (for example the password expiration date). We currently have a "workaround" by using the /ui-api/standard_settings API endpoint. I fully agree with Volker that's not the right way going forward.

Thanks @Lenz Grimmer, @Volker and @Tatjana!

• Embedding all required config setting info in ui-api/ helper endpoints:
  • Pros: existing approach (proven), easier to implement (already there) and keeps complexity/hides Ceph specifics in the back-end.
  • Cons: these endpoints are usually pre-fetched on component loading and never refreshed. It makes harder to react to live changes.
• Providing fine-grained permissions at config setting-level:
  • Pros: more extensible, and forms might react dynamically to changes.
  • Cons: requires changes to config controller, it might be harder to extend/maintain and track security issues, and brings complexity to front-end (routing single front-end component to multiple back-end endpoints).

I personally prefer the latter approach, as it'd be really easy to implement if all Ceph config options would have their corresponding service tags, as we could reuse that info for automatically tagging scopes per cluster config option:

//src/common/options.h
struct Option { 
...
  // Items like mon, osd, rgw, rbd, ceph-fuse.  This is advisory metadata                               
  // for presentation layers (like web dashboards, or generated docs), so that                          
  // they know which options to display where.                                                          
  // Additionally: "common" for settings that exist in any Ceph code.  Do                                                                                                                                                                                                                   
  // not use common for settings that are just shared some places: for those                            
  // places, list them.                                                                                 
  std::vector<const char*> services; 

However, for this specific case, we may see that there's no match between our pool-manager role and any Ceph service (rbd, rgw, ...).

    Option("osd_pool_default_pg_autoscale_mode", Option::TYPE_STR, Option::LEVEL_ADVANCED)                                                                                                                                                                                                  
    .set_default("on")                                                                               
    .set_flag(Option::FLAG_RUNTIME)                                                                  
    .set_enum_allowed({"off", "warn", "on"})                                                         
    .set_description("Default PG autoscaling behavior for new pools"),
+   .add_service("pool")  // weird. Instead: rbd + cephfs + rgw

IMHO this is an indication that the pool scope and pool-manager role are not very meaningful per se. Instead we should probably remove pool-manager and pool scope and only allow <service>-manager to create/edit/delete pools with application tag <service> (let <service> be rgw, cephfs or rbd).