Skip to content
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

[Feature Control] Ability to hide Management application completely #35040

Closed
AlonaNadler opened this issue Apr 12, 2019 · 12 comments · Fixed by #67791
Closed

[Feature Control] Ability to hide Management application completely #35040

AlonaNadler opened this issue Apr 12, 2019 · 12 comments · Fixed by #67791
Assignees
Labels
Feature:Security/Feature Controls Platform Security - Spaces & Role Mgmt feature controls Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!

Comments

@AlonaNadler
Copy link

Currently, with FC users will be able to hide/restrict certain features within management like index patterns and advanced setting, the rest of the options including all ES, Ingest and Kibana will be available even if the users don't have a privilege to use them and there is no way to hide/restrict the entire management application.

The ask is to be able to hide and restrict management application completely as part of Feature Control.

@AlonaNadler AlonaNadler added the Feature:Security/Feature Controls Platform Security - Spaces & Role Mgmt feature controls label Apr 12, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-security

@legrego
Copy link
Member

legrego commented Apr 15, 2019

For posterity, I want to document the reasons why we don't currently have support for this. Nothing here is insurmountable, but it adds complexity that we weren't comfortable taking on for the initial release of Feature Controls:

  1. What happens if a user hides the Management application in all spaces? With the Management app gone, they won't have access to the Spaces Management screen, so they don't have a way to re-enable Management through the UI. Their only recourse is to use our experimental Spaces APIs.

  2. We'll need to audit all places where Kibana assumes that the Management app is available. There are a lot of deep links into the application which need to be given consideration.

  3. Reporting -- the Management app is the only way to view your reports. If we take the Management app away, then we should also hide the reporting functionality.

@AlonaNadler
Copy link
Author

Hiding the management application seems to be one of the most common requests around hiding/restricting applications. @legrego you raised good points, given that there is complexity in this request, maybe there are alternatives

What happens if a user hides the Management application in all spaces? With the Management app gone, they won't have access to the Spaces Management screen, so they don't have a way to re-enable Management through the UI. Their only recourse is to use our experimental Spaces APIs.

For users who use security, usually admins set the privileges and can disable the management application to end users, is it possible to keep management always on for all superusers?
Another suggestion is that for basic users it will not be possible to hide management in the default space? that way they will have at least one place where management is enabled

Reporting -- the Management app is the only way to view your reports. If we take the Management app away, then we should also hide the reporting functionality.

If reporting was no longer in management, will it be easier to hide management application completely?

@legrego
Copy link
Member

legrego commented Apr 25, 2019

For users who use security, usually admins set the privileges and can disable the management application to end users, is it possible to keep management always on for all superusers?

If we only enabled this toggle on the Role Management screen, then we could support something like this, but having it available in Spaces too complicates it further.

Another suggestion is that for basic users it will not be possible to hide management in the default space? that way they will have at least one place where management is enabled

That's an interesting thought. Do you think we could get away with always restricting the default space in this way?

If reporting was no longer in management, will it be easier to hide management application completely?

It would help a bit. We'd have to figure out what to do with the apps that redirect for index pattern management too, but that's not a huge task I don't think. Where do you envision reporting living?

@AlonaNadler
Copy link
Author

That's an interesting thought. Do you think we could get away with always restricting the default space in this way?

Since to hide management is a common request going might be worth it. With this approach, basic users will not be able to hide the entire management application in the default space.
For users with security, they will be able to define specific roles with no access to the management app at all while admins will have it, make sense?

It would help a bit. We'd have to figure out what to do with the apps that redirect for index pattern management too, but that's not a huge task I don't think. Where do you envision reporting living?

Management app becoming more and more the place to manage the entire stack, Im not sure reporting should stay there, end users that are mainly exploring and visualizing the data often don't need anything in the management app beside reporting

@legrego
Copy link
Member

legrego commented Apr 26, 2019

Since to hide management is a common request going might be worth it. With this approach, basic users will not be able to hide the entire management application in the default space.

That makes sense to me.

For users with security, they will be able to define specific roles with no access to the management app at all while admins will have it, make sense?

I'm struggling to see how we can make this work with the read/write privileges that we assign on the Role Management screen today. Most of the Management screen relies on ES Cluster Privileges to function, which aren't supported by the read/write privileges we grant today. So it wouldn't make sense to grant "readonly" or "read/write" access to Management as a whole, as it would only be able to control a few Kibana screens, namely Saved Objects and Index Patterns. The rest of the screens are controlled by other privileges, which might confuse users even more.

I think to get to the point where we can hide Management in a logical manner w/ security, we first need the ability to hide management screens based on the user's cluster privileges. At that point, we can make more intelligent decisions about when to show/hide the Management app.

Management app becoming more and more the place to manage the entire stack, Im not sure reporting should stay there, end users that are mainly exploring and visualizing the data often don't need anything in the management app beside reporting

I completely agree. We just need to figure out where reporting should actually live, and then move it there.

@kobelb
Copy link
Contributor

kobelb commented May 2, 2019

After further discussion, we're planning on hiding the management tab when there are no management "sections" available. We've broken this down into the following explicit issues:

@flash1293
Copy link
Contributor

#63443 will move Discover, Visualize, Dashboard, Lens and Dev Tools to the new platform where they become separate applications (currently they are all wrapped up in the kibana app).

This worsens a problem which already exists today: When a user doesn't have a role granting them access to the kibana app, they won't be able to access management at all (because they will get a 404). Currently this only affects solution apps (e.g. if a user can only access apm and nothing else), but with the PR mentioned above it will also affect the "core apps" of Kibana, making it much more likely for people to run into the problem. E.g. when a user is just given access rights to discover, dashboard and visualize, they won't be able to access management anymore - the navlink will be there but it will just lead to a 404 page.

cc @azasypkin @legrego

@legrego
Copy link
Member

legrego commented Apr 30, 2020

(full disclosure: I haven't looked at #63443)

Most features will grant access to the kibana app in addition to whatever applications they expose. This historically allowed them to access the home page, as well as management.

If management is still under the kibana app in the short-term, then I expect this will continue to work...it doesn't solve the long term problem, but I don't think it's made worse by #63443

@legrego legrego added the Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! label Apr 30, 2020
@flash1293
Copy link
Contributor

@legrego OK so you think in that PR I should just keep the kibana privilege for the discover, dashboard, visualize, ... features?

@legrego
Copy link
Member

legrego commented Apr 30, 2020

Yes I would keep that privilege for the time being

@flash1293
Copy link
Contributor

@legrego Hm, I just tried that but somehow it doesn't work. When I list two apps for each of those features, it becomes impossible to disable them via feature controls. Maybe I'm doing something wrong.

Everything works fine (except for the thing with management 404ing)

    {
      id: 'dev_tools',
      name: i18n.translate('xpack.features.devToolsFeatureName', {
        defaultMessage: 'Dev Tools',
      }),
      order: 1300,
      icon: 'devToolsApp',
      navLinkId: 'dev_tools',
      app: ['dev_tools'],
      catalogue: ['console', 'searchprofiler', 'grokdebugger'],
      privileges: {
        all: {
          app: ['dev_tools'],
          catalogue: ['console', 'searchprofiler', 'grokdebugger'],
          api: ['console'],
          savedObject: {
            all: [],
            read: [],
          },
          ui: ['show', 'save'],
        },
        read: {
          app: ['dev_tools'],
          catalogue: ['console', 'searchprofiler', 'grokdebugger'],
          api: ['console'],
          savedObject: {
            all: [],
            read: [],
          },
          ui: ['show'],
        },
      },
      privilegesTooltip: i18n.translate('xpack.features.devToolsPrivilegesTooltip', {
        defaultMessage:
          'User should also be granted the appropriate Elasticsearch cluster and index privileges',
      }),
    },

Dev tools is always accessible, no matter what:

    {
      id: 'dev_tools',
      name: i18n.translate('xpack.features.devToolsFeatureName', {
        defaultMessage: 'Dev Tools',
      }),
      order: 1300,
      icon: 'devToolsApp',
      navLinkId: 'dev_tools',
      app: ['dev_tools', 'kibana'],
      catalogue: ['console', 'searchprofiler', 'grokdebugger'],
      privileges: {
        all: {
          app: ['dev_tools', 'kibana'],
          catalogue: ['console', 'searchprofiler', 'grokdebugger'],
          api: ['console'],
          savedObject: {
            all: [],
            read: [],
          },
          ui: ['show', 'save'],
        },
        read: {
          app: ['dev_tools', 'kibana'],
          catalogue: ['console', 'searchprofiler', 'grokdebugger'],
          api: ['console'],
          savedObject: {
            all: [],
            read: [],
          },
          ui: ['show'],
        },
      },
      privilegesTooltip: i18n.translate('xpack.features.devToolsPrivilegesTooltip', {
        defaultMessage:
          'User should also be granted the appropriate Elasticsearch cluster and index privileges',
      }),
    },

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Security/Feature Controls Platform Security - Spaces & Role Mgmt feature controls Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants