[SLOs] remove manage_transform and manage_ingest_pipeline privilege requirements

[dominiqueclarke]

Summary

Resolves https://github.com/elastic/observability-dev/issues/3845

Removes the manage_transform and manage_ingest_pipeline privilege requirements from the SLO app.

This accomplished by replacing the existing ES client with asSecondaryAuthUser client.

The asSecondaryAuthUser client passes es-secondary-authorization headers to the related APIs. When supported, the API will use the primary auth (the kibana system user) to handle primary actions such as creating the transforms and ingest pipelines, while using secondary auth to check against index privileges. The result is the ability to for Kibana to create transforms and pipelines on behalf of the user, while respecting the users index privileges.

Testing

To test, be sure to use a less privileged user without manage_transform or manage_pipeline privileges. Begin by creating two new roles, slo_editor and slo_viewer

Index privileges for slo_editor user

.slo-*: 'write', 'read', 'read_cross_cluster', 'view_index_metadata', 'manage', 'auto_configure'

Index privileges for slo_viewer user

.slo-*: 'read', 'read_cross_cluster', 'view_index_metadata'

Then create two new users, slo_editor and slo_viewer and give them the following roles:

slo_editor: 'slo_editor', 'editor'
slo_viewer: 'slo_viewer', 'viewer'

An overall regression testing of the SLO app is desired, including:

Editor user

1. Creating a SLI without a group by
2. Creating a SLI with a group by
3. Updating an SLI without a group by
4. Updating a SLI with a group by
5. Deleting a SLI
6. Inspecting an SLI
7. Resetting an SLI
8. Receiving and viewing SLI health notifications on the SLO page
9. Viewing SLOs

Viewer user

1. Inspecting an SLI
2. Receiving and viewing SLI health notifications on the SLO page
3. Viewing SLOs

[obltmachine]

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

• /oblt-deploy : Deploy a Kibana instance using the Observability test environments.
• run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)

[dominiqueclarke]

Note: I have not implemented the SLO health API yet. That will need to be done before this is merged.

[dominiqueclarke]

/ci

[dominiqueclarke]

/ci

[dominiqueclarke]

/ci

[dominiqueclarke]

/ci

[dominiqueclarke]

/ci

[elasticmachine]

Pinging @elastic/obs-ux-management-team (Team:obs-ux-management)

[mgiota]

@dominiqueclarke I was checking all the routes in this file and I was wondering if we need to pass the scopedClusterClient to the getSloBurnRates route as well. I noticed that you didn't change the GET requests, but getSloBurnRates is POST request, so I thought we might need to pass the scopedClusterClient there as well. What do you think?

[dominiqueclarke]

There aren't any transform or ingest pipeline actions in that code path.

[mgiota]

Here's some outcome from my manual testing:

I created an slo_editor role, but as you can see in the Video recording I can not see the Good/Bad Events Chart. When I am logged in with elastic user, Good/Bad events chart loads properly.

Screen.Recording.2024-08-22.at.13.59.59.mov

UPDATE
I haven't given my user the editor role. Once I added editor role as well, Good/Bad events charts loaded properly.

[jeramysoucy]

I think Kibana Security is only tagged for a review here because the changes from #190998 are not merged to this PR yet. If that is untrue please let me know.

[mgiota]

I finished with manual testing and everything works well!

[mgiota]

@dominiqueclarke This screenshot is not directly related to your PR, it is related to something similar I was working on regarding SLO permissions through SLO integrations. So below screenshot is from another PR

I'm playing around with user roles in your PR and trying to reproduce this Transform error message. Do you know what role and privileges I need to use to be able to get this Transform error message? The reason I am asking is because I am thinking we could display a Reauthorization required message directly in the SLO lists page similar to how Fleet team or ML team handle it. They have screenshots with the UI workflow they use. I can create a ticket with more details and we can discuss it with the team. What do you think?

[mgiota]

I am reading through the SLO permissions email thread and I found this linked issue. Do I understand correctly that we want to move away from explicit opt-ins and make it more back-box to the user? If that's the case, what I suggest above regarding a reauthorization flow is not the right way.

[dominiqueclarke]

I wanted to align this with the actual index pattern and privileges we specify for the SLO product, but I'm not sure if that's even the purpose of this test/service because it seems like it's intended to just test transforms and doesn't actually really relate to SLOs at all?

[dmlemeshko]

I believe best person to answer is @mgiota , she added the service

[dominiqueclarke]

@mgiota If this is SLO related then I think this change is fine. The tests are indeed passing.

[muthu-mps]

@dominiqueclarke, @mgiota -

• Using the es-secondary-authorization, Will this solve the authorization issue with the transform jobs creations when we create SLOs by using the default Kibana user role?
• While removing the manage_transform and manage_ingest_pipeline privileges, we may need to update the SLO creation documentation.

[dominiqueclarke]

@dominiqueclarke, @mgiota -

• Using the es-secondary-authorization, Will this solve the authorization issue with the transform jobs creations when we create SLOs by using the default Kibana user role?
• While removing the manage_transform and manage_ingest_pipeline privileges, we may need to update the SLO creation documentation.

• Yes, using es-secondary-auth splits the privilege model in two, using one set of privileges, the kibana system's, for the primary action (creating, editing, deleting transforms) and another set privileges, the users, for determining access to the source and destination index
• Yes, we will need to create a ticket to update the docs

[dmlemeshko]

x-pack/test_serverless/api_integration/services/transform/security_common.ts changes LGTM

[shahzad31]

i still see manage_transform permission listed as requirement on SLO home page

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: c1c9224
• Kibana Serverless Image: docker.elastic.co/kibana-ci/kibana-serverless:pr-190572-c1c92248ecd0

Failed CI Steps

• FTR Configs #69

Test Failures

• [job] [logs] FTR Configs #69 / Cloud Security Posture Test adding Cloud Security Posture Integrations KSPM K8S KSPM K8S KSPM K8S Workflow

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
slo	916.6KB	916.5KB	-113.0B

History

• 💛 Build #229830 was flaky febb9bf
• 💔 Build #229788 failed ffbea83
• 💚 Build #229747 succeeded 55e1828
• 💛 Build #229291 was flaky c0fe40a
• 💔 Build #229253 failed d838b3c

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream