User permissions to only view, modify and delete dashboards/visualizations without access to admin settings

Security
1

Based on: Users and Roles - Open Distro Documentation

I added a read only user which is able to view created dashboards and create on demand reports via the reporting function.

The kibana_user and kibana_read_only role are mapped to this user as well as this custom logstash_data_ro role.

PUT _opendistro/_security/api/roles/logstash_data_ro
    {
        "cluster_permissions" : [
        "cluster_composite_ops_ro",
        "cluster:admin/opendistro/reports/menu/download"
        ],
        "index_permissions" : [
        {
            "index_patterns" : [
            "logstash-*"
            ],
            "dls" : "",
            "fls" : [ ],
            "masked_fields" : [ ],
            "allowed_actions" : [
            "read"
            ]
        }
        ],
        "tenant_permissions" : [
        {
            "tenant_patterns" : [
            "*"
            ],
            "allowed_actions" : [
            "kibana_all_read"
            ]
        }
        ]
    }

How can I create a second role/user that is able to modify, create and delete dashboards and visualizations without granting further privileges to accessing settings.
I probably need the same logstash_data_ro role and build a custom kibana_dashboard_user role.

PUT _opendistro/_security/api/roles/kibana_dashboard_user
{
   "cluster_permissions" : [
      "cluster_composite_ops"     <—— This permission group is probably to wide, but I can not find information which permission is used for visualizations
    ],
    "index_permissions" : [
      {
        "index_patterns" : [
          ".kibana",
          ".kibana-6",
          ".kibana_*"
        ],
        "fls" : [ ],
        "masked_fields" : [ ],
        "allowed_actions" : [
          "read",
          "delete",
          "manage",
          "index"
        ]
      },
      {
        "index_patterns" : [
	],
        "fls" : [ ],
        "masked_fields" : [ ],
        "allowed_actions" : [
          “crud”
        ]
      }
}

Bonus questions: How can I grant access to the notebooks plugin for non admin users to either of these roles?
Adding ”.notebooks” does not make any difference I still do not see the Notebooks menu entry. I suppose I have to add a permission to access notebooks but a dedicated notebook permission does not seem to exist.

Thank you for any suggestions.

2

Hello @shansb

What ODFE version do you currently run?

3

Hello @pablo thank you for your reply, I am on the latest odfe version 1.13.2 with elasticsearch-oss 7.10.2.

4

@shansb

Did you look at built-in notebooks roles? They have all the needed permissions for RO and RW roles.

image

5

@shansb

You can use actions which make cluster_composite_ops action group instead of action group.
Then delete one by one and check which action fits your needs.

image
image511×607 18.6 KB

6

Thank you for your suggestions.

Ok I see the nootbook roles you mentioned in roles but the linked permissions are missing in the permission overview.

It does not matter how I reference these:

PUT _opendistro/_security/api/roles/logstash_data_ro
    {
        "cluster_permissions" : [
        "cluster_composite_ops_ro",
        "cluster:admin/opendistro/reports/menu/download",
        "notebooks_full_access",
        "notebooks_read_access"
        ],
        "index_permissions" : [
        {
            "index_patterns" : [
            "logstash-*"
            ],
            "dls" : "",
            "fls" : [ ],
            "masked_fields" : [ ],
            "allowed_actions" : [
            "read"
            ]
        }
        ],
        "tenant_permissions" : [
        {
            "tenant_patterns" : [
            "*"
            ],
            "allowed_actions" : [
            "kibana_all_read"
            ]
        }
        ]
    }

Or directely linked:

PUT _opendistro/_security/api/roles/logstash_data_ro
    {
        "cluster_permissions" : [
        "cluster_composite_ops_ro",
        "cluster:admin/opendistro/reports/menu/download",
        "cluster:admin/opendistro/notebooks/create",
        "cluster:admin/opendistro/notebooks/update",
        "cluster:admin/opendistro/notebooks/delete",
        "cluster:admin/opendistro/notebooks/get",
        "cluster:admin/opendistro/notebooks/list"
        ],
        "index_permissions" : [
        {
            "index_patterns" : [
            "logstash-*"
            ],
            "dls" : "",
            "fls" : [ ],
            "masked_fields" : [ ],
            "allowed_actions" : [
            "read"
            ]
        }
        ],
        "tenant_permissions" : [
        {
            "tenant_patterns" : [
            "*"
            ],
            "allowed_actions" : [
            "kibana_all_read"
            ]
        }
        ]
    }

Both variants do not change anything, because the permissions cluster:admin/opendistro/notebooks/* are missing in the index.

Additionally they are not mentioned in the docs either:

Regarding your suggestion, building a custom action group using the permissions. I think it does not matter whether the permissions are linked directely in the role or via an action group, which is then set in the role. It is just another organizational style.

The problem is it is not clear for me which permission leads to which outcome and I hoped for a little guidance. The documentation does not provide more information it just lists these permissions.
And try-and-error is a tedious task.

7

Ok @pablo you were right from the beginning.

After I found some time to look at this issue again I noticed there is a .notebooks index as well, which needs to be added to the index_permissions.

PUT _opendistro/_security/api/roles/logstash_data_ro {
  "cluster_permissions" : [
    "cluster_composite_ops_ro",
    "notebooks_read_access"
  ],
  "index_permissions" : [
    {
      "index_patterns" : [
        "logstash-*",
        ".notebooks"
      ],
      "fls" : [ ],
      "masked_fields" : [ ],
      "allowed_actions" : [
        "read"
      ]
    }
  ],
  "tenant_permissions" : [
    {
      "tenant_patterns" : [
        "*"
      ],
      "allowed_actions" : [
        "kibana_all_read"
      ]
    }
  ]
}

This works like a charm if the user does not have the kibana_read_only role.