[Fleet] Remove superuser requirement to access Fleet #108252

mostlyjason · 2021-08-11T18:23:52Z

One blocker for many users using Fleet and Integrations is the requirement for the superuser role. This requires users to have broad permissions in order to use Fleet and Integrations which is a security problem. We should remove this requirement and rely on users having the Kibana privilege to access "Fleet and Integrations" (potentially with a built-in role).

Blockers:

Implementation scope

UX changes

For all disabled buttons, a tooltip should also be added that indicates the user needs additional permissions. An example:

Notes

Preserving BWC with users granted access to Integrations app in 7.16

This is required to avoid breaking read access to Integrations since we allowed users with "read" to this privilege
to be able to view the integrations app even if they did not have superuser, starting in 7.16. Since there is no
existing mechanism to update the privileges stored in existing user roles, we should be careful change the privilege id
field in a way that won't break these existing roles:

We should rename (change the name property) the existing combined privilege with the id: 'fleet' to
Integrations and use this privilege to drive access to Integrations going forward. The id should not change.
The privilege we add for Fleet should have the id: 'fleetv2'.
In the future we can migrate the above, but no such ability exists today. We'll consider this technical debt for now
and hide this detail behind the FleetAuthz abstraction.

The text was updated successfully, but these errors were encountered:

elasticmachine · 2021-08-11T18:23:54Z

Pinging @elastic/fleet (Team:Fleet)

joshdover · 2022-01-06T16:49:45Z

@mostlyjason @dborodyansky I've updated the issue description to note all of the small UI elements that need to be adjusted when the user does not have access to appropriate actions. Currently I'm proposing that we simply disable each element, but I do wonder if we should do something more to explain why the button is disabled.

For the buttons, I think we can do the same thing that we're doing on the "Add " integration CTA:

However for the dropdown menus, I wonder if a tooltip is even possible or could be confusing. Any suggestions here? For example, we need to prevent the user from clicking "Delete integration" here:

dborodyansky · 2022-01-06T17:07:11Z

@joshdover Does the privilege limitation apply only to "delete", not "edit". If both, then hiding the [...] menu entirely would be expected.

joshdover · 2022-01-06T19:26:17Z

@joshdover Does the privilege limitation apply only to "delete", not "edit". If both, then hiding the [...] menu entirely would be expected.

Good point on that one, agreed we should hide the entire list, bad example on my part. How about this one where the "Add Agent" option will be available? Note that when there are already agents enrolled, the other "Add Agent" CTA button is not visible.

dborodyansky · 2022-01-06T19:32:11Z

How about this one where the "Add Agent" option will be available?

Hiding unavailable actions within the menu seems appropriate in this case. There are some guidelines in the works which recommend hiding controls within tables for which a user may not have privileges.

dikshachauhan-qasource · 2022-02-22T13:36:31Z

Hi @jen-huang @joshdover

We have performed testing today around this feature and found two below bugs.

[Fleet] No tool tip is displayed for disabled 'Add integration' button under Policy detail page when user has only Read rights for Integrations. #126139
Advanced Tab is available to Non-super user having only Read rights for Integrations under Endpoint Security. #126148

Further, we are in progress of test content creation for this ticket at TestRail and will share links for test cases created by tomorrow.

Thanks
QAS

dikshachauhan-qasource · 2022-02-23T13:13:16Z

Hi @mostlyjason

We have created below 17 test cases for this feature ticket at Testrail:

Further, I have one query for last UI change:

When end users and kibana_system try to set up fleet server and they don't already have a fleet server set up:
- [x] app/fleet/agents should show this callout:

How this will work at Cloud for non-super user when Integration server section is excluded while creating deployments.
Currently it shows "Edit deployment page" to both users: Non-super user & Super user. Is it expected.

Thanks
QAS

joshdover · 2022-02-23T13:30:35Z

Currently it shows "Edit deployment page" to both users: Non-super user & Super user. Is it expected.

We should probably hide this as non-superusers may not have access to the Cloud console, but I also know that is changing recently with the addition of more user roles on Cloud. @mostlyjason we could probably use your input here.

mostlyjason · 2022-02-23T13:50:50Z

I think we should show it to both since we don't know whether the signed in user in kibana has access to the cloud console or not. It doesn't matter if they are a superuser in Kibana since Elastic Cloud has separate privileges. If they sign into Elasticsearch directly using user/pass or SSO, they may not be signed into Elastic Cloud. After the link they can sign in with Elastic Cloud if needed or ask a cloud admin for help.

dikshachauhan-qasource · 2022-02-24T12:50:29Z

Hi All

We have executed below feature run, on this PR at testrail for created testcases:

Remove SuperUser Access to Fleet

We will retest the failed testcases on BC4 and add the results once, reported issues are fixed.

Thanks
QAS

zez3 · 2022-03-11T06:09:30Z

This does not seem to work in 8.1 on my deployment.

I get wrong permissions

and
do I really need to give all spaces to my limited users?

joshdover · 2022-03-14T12:31:18Z

@zez3 Fleet does not currently support Spaces so to make this explicit, we require that when you grant access to Fleet, you do so across all Spaces. This does not mean that you need to give access to all features across all Spaces, only for Fleet.

In the screenshot above, you have not granted access to Fleet, it's still checked as None on the right. You will also need to grant access to Integrations. It should look like this:

zez3 · 2022-03-15T09:26:45Z

@joshdover

@zez3 Fleet does not currently support Spaces so to make this explicit, we require that when you grant access to Fleet, you do so across all Spaces. This does not mean that you need to give access to all features across all Spaces, only for Fleet.

I understand this and would accept this workaround but...

In the screenshot above, you have not granted access to Fleet, it's still checked as None on the right.

the None(ViewOnly) is read only("feature_fleet.read"), I saw(#125836) an open issue for renaming this to Read.

I don't need nor want to allow write (All) permission to my users. I need for them to see that the agent that they just installed is alive and it has a policy assigned.
Ideally only the ones that belong to them. I am currently using the namespaces in index name in roles to enforce that.

here are my current permisions

{
  "MYSPACE" : {
    "cluster" : [ ],
    "indices" : [
      {
        "names" : [
          "logs-mylogs*"
        ],
        "privileges" : [
          "read",
          "read_cross_cluster",
          "view_index_metadata",
          "index"
        ],
        "field_security" : {
          "grant" : [
            "*"
          ],
          "except" : [ ]
        },
        "query" : """ {"match_phrase": {"match_my_phrase"}}""",
        "allow_restricted_indices" : false
      }
    ],
    "applications" : [
      {
        "application" : "kibana-.kibana",
        "privileges" : [
          "feature_canvas.all",
          "feature_maps.all",
          "feature_ml.read",
          "feature_graph.all",
          "feature_visualize.all",
          "feature_dashboard.minimal_all",
          "feature_dashboard.url_create",
          "feature_dashboard.store_search_session",
          "feature_discover.minimal_all",
          "feature_discover.url_create",
          "feature_discover.store_search_session",
          "feature_logs.read",
          "feature_infrastructure.read",
          "feature_apm.read",
          "feature_uptime.read",
          "feature_observabilityCases.read",
          "feature_fleet.read",
          "feature_stackAlerts.all",
          "feature_actions.all",
          "feature_siem.read",
          "feature_advancedSettings.read",
          "feature_indexPatterns.read",
          "feature_savedObjectsTagging.read",
          "feature_savedObjectsManagement.all"
        ],
        "resources" : [
          "space:*"
        ]
      }
    ],
    "run_as" : [ ],
    "metadata" : { },
    "transient_metadata" : {
      "enabled" : true
    }
  }
}

The Integrations looks good as read-only.

joshdover · 2022-03-15T10:34:24Z

the None is read only("feature_fleet.read"), I saw(cannot find it now) an open issue for renaming this to Read.

I don't need nor want to allow write (All) permission to my users. I need for them to see that the agent that they just installed is alive and it has a policy assigned.

Got it, thanks for explaining what you're looking for. We do not yet support a read-only mode for Fleet, that is a separate feature that we are prioritizing (we don't have a public tracking issue for this right now).

You are right that the privilege name shows up as feature_fleet.read when you select "Read" for the Integrations privilege. This is less than ideal, but a shortcut we had to take to avoid a breaking change for now. So privileges named as "Integrations" in the UI are actually stored in the role on the API as "fleet" while privileges named as "Fleet" in the UI are stored as "fleetv2". This is working as expected for now and is something we'll clean up in the future.

So to summarize:

You can grant a user "Read" or "All" access to Integrations in 8.1+ and this will show up in the API as feature_fleet.read or feature_fleet.all but it actually is used for Integrations and not for Fleet
You can grant a user "All" access to Fleet in 8.1+ and this will show up in the API as feature_fleetv2.all. We do not yet support read-only access to Fleet, but we plan to in a future release.
In 8.1, users no longer have to have the superuser role in order to access the Fleet app, and instead can access the app if they are granted the "All" privilege for Fleet (feature_fleetv2.all). This is an improvement over prior releases where granting access to the "Fleet & Integrations" privilege was not sufficient to use the Fleet app.

mostlyjason added the Team:Fleet Team label for Observability Data Collection Fleet team label Aug 11, 2021

joshdover mentioned this issue Oct 26, 2021

[Fleet] Exposed service to manipulate fleet-* should use internal ES client #116182

Closed

jen-huang added the v8.0.0 label Nov 2, 2021

jen-huang changed the title ~~[Meta][Fleet] Replace superuser requirement with finer-grained permissions~~ [Fleet] Remove superuser requirement to access Fleet Nov 2, 2021

jen-huang assigned joshdover and criamico Nov 3, 2021

joshdover mentioned this issue Nov 19, 2021

[Fleet] Add base Fleet authz logic and API #119199

Merged

nchaulet mentioned this issue Nov 28, 2021

[Fleet] Use Fleet authz for fleet server routes security instead of enforcing superuser #119795

Merged

joshdover mentioned this issue Nov 30, 2021

[Fleet] Update calculateAuthz calls to respect superuser for now #119973

Merged

nchaulet mentioned this issue Nov 30, 2021

[Fleet] Use internal ES client to access .fleet system indices #119992

Merged

jen-huang added v8.1.0 and removed v8.0.0 labels Dec 1, 2021

criamico mentioned this issue Jan 5, 2022

[Fleet] Add support for non-superuser access to Fleet and Integrations #122347

Merged

6 tasks

jen-huang mentioned this issue Jan 24, 2022

[Request][Fleet] Account for removal of superuser requirement to access UI elastic/observability-docs#1488

Closed

criamico closed this as completed in #122347 Jan 31, 2022

juliaElastic mentioned this issue Feb 3, 2022

[8.1.0-SNAPSHOT] Fleet Server can't enroll: FAILED: Missed two check-ins elastic/fleet-server#1129

Closed

criamico mentioned this issue Feb 3, 2022

Missing privileges in agent logs (Superuser removal enhancement) #124529

Open

criamico mentioned this issue Feb 16, 2022

[Fleet] Add cypress tests for Editor and Viewer role under new privileges #125836

Closed

joshdover mentioned this issue Mar 8, 2022

[Discuss] Installing package assets that require elevated privileges elastic/package-spec#293

Open

joshdover mentioned this issue Jul 27, 2022

[Fleet] Support installing transforms without granting kibana_system index privileges #137278

Open

amolnater-qasource mentioned this issue Oct 13, 2022

[Self-Managed][Fleet]: manage_service_account message not available when the user doesn’t have fleet server setup with non-super user account. #143256

Closed

criamico mentioned this issue Nov 29, 2023

[REQUEST]: Document the privileges needed for Fleet and Integrations elastic/ingest-docs#724

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Fleet] Remove superuser requirement to access Fleet #108252

[Fleet] Remove superuser requirement to access Fleet #108252

mostlyjason commented Aug 11, 2021 •

edited by criamico

Loading

elasticmachine commented Aug 11, 2021

joshdover commented Jan 6, 2022 •

edited

Loading

dborodyansky commented Jan 6, 2022

joshdover commented Jan 6, 2022 •

edited

Loading

dborodyansky commented Jan 6, 2022

dikshachauhan-qasource commented Feb 22, 2022

dikshachauhan-qasource commented Feb 23, 2022 •

edited

Loading

joshdover commented Feb 23, 2022

mostlyjason commented Feb 23, 2022 •

edited

Loading

dikshachauhan-qasource commented Feb 24, 2022

zez3 commented Mar 11, 2022

joshdover commented Mar 14, 2022

zez3 commented Mar 15, 2022 •

edited

Loading

joshdover commented Mar 15, 2022

[Fleet] Remove superuser requirement to access Fleet #108252

[Fleet] Remove superuser requirement to access Fleet #108252

Comments

mostlyjason commented Aug 11, 2021 • edited by criamico Loading

Implementation scope

UX changes

Notes

Preserving BWC with users granted access to Integrations app in 7.16

elasticmachine commented Aug 11, 2021

joshdover commented Jan 6, 2022 • edited Loading

dborodyansky commented Jan 6, 2022

joshdover commented Jan 6, 2022 • edited Loading

dborodyansky commented Jan 6, 2022

dikshachauhan-qasource commented Feb 22, 2022

dikshachauhan-qasource commented Feb 23, 2022 • edited Loading

joshdover commented Feb 23, 2022

mostlyjason commented Feb 23, 2022 • edited Loading

dikshachauhan-qasource commented Feb 24, 2022

zez3 commented Mar 11, 2022

joshdover commented Mar 14, 2022

zez3 commented Mar 15, 2022 • edited Loading

joshdover commented Mar 15, 2022

mostlyjason commented Aug 11, 2021 •

edited by criamico

Loading

joshdover commented Jan 6, 2022 •

edited

Loading

joshdover commented Jan 6, 2022 •

edited

Loading

dikshachauhan-qasource commented Feb 23, 2022 •

edited

Loading

mostlyjason commented Feb 23, 2022 •

edited

Loading

zez3 commented Mar 15, 2022 •

edited

Loading