#1695

[Bug]: Runbook rules do not provide scoped connection access — users must already have the connection in their group

Openjackobermanopened 2mo ago

Bug Description

Summary

Runbook rules do not grant users access to execute a runbook on a connection they don't already have in their group. The "Group access configuration" field in the runbook rule UI is therefore misleading — it implies a group can run the configured runbook on the configured connection without direct connection access, but in practice they cannot.

Problems observed

1. POST /api/runbooks/exec requires connection_name even though the connection is already specified in the runbook rule

The runbook rule already specifies which connection the runbook should run on. Callers should not need to pass connection_name in the API payload — the runbook rule should resolve it. Instead, the API requires connection_name and then checks connection-level access for the calling user, returning 404 {"message":"connection not found"} if the user's group doesn't have direct access to that connection — even when a runbook rule exists granting that group access to that connection+runbook.

2. Runbook executes on the wrong connection

The resource configuration in the runbook rule is ignored at execution time.

Steps to reproduce:

  1. Create a runbook rule with a specific resource role configured (e.g. connection-a)
  2. Go to Runbooks in the UI
  3. Select a different resource role from the dropdown (e.g. connection-b) and run the runbook
  4. The runbook executes on connection-b, not connection-a as specified in the rule — the resource configuration is ignored

3. Runbook rule doesn't appear in UI under the configured connection

Steps to reproduce:

  1. Create a runbook rule with a specific resource role configured
  2. Go to Runbooks Setup
  3. Click the "Resource Role" filter button and select the resource role you configured in the rule
  4. The rule does not appear — "No runbook rules found" is shown despite the rule being correctly stored (confirmed via API)

Expected behavior

A user in a group listed in a runbook rule's user_groups should be able to execute that runbook on the rule's configured connection — without needing the connection added to their group directly, and without needing to specify connection_name in the API call. The runbook rule should fully define the execution context: which connection to use, which users can trigger it, and which runbook file to run.

Question

Is the intended behavior of runbook rules to only filter which runbooks are visible in the UI, with no effect on connection-level authorization or execution context? If so, this needs to be clearly documented. If not, this is a bug.

I can also split these out into separate bugs if desired.

Steps to Reproduce

Specified above.

Expected Behavior

Specified above.

Actual Behavior

Specified above.

Version

1.126.1 (OSS, self-hosted)

Browser(s)

Other

Operating System

WSL on Windows 11

Screenshots

No response

Additional Context

No response

Relevant Log Output

undefined

Code of Conduct

  • I agree to follow this project's Code of Conduct

Activity

4
github-actions[bot]2mo ago

🔗 Synced to Linear: SUP-193

EmanuelJr2mo ago

Hello, @jackoberman !

About the 1., it’s not a bug. The resource role specification in the runbook rules defines which connections can be executed with that runbook, not a 1:1 mapping.

Are you using an admin account? When you are using the Runbooks with an admin account, you bypass every rule set before. You can try with a different user.

jackoberman2mo ago

Hey @EmanuelJr !

I think I'm confused about the function of runbooks. From my understanding (which may be based on wrong assumptions), we should be able to give an under-permissioned user access to a runbook which then grants them the ability to run a specific workflow using elevated permissions. This is done by granting them access to the runbook which uses a resource / connection with elevated permissions that the user would not otherwise have access to. Requiring the user to already have the resource with that connection with elevated permissions feels like it invalidates the point.

For our specific purposes, I'd like to grant under-permissioned users the ability to flip a bool column for a specific ClickHouse table. I do not want to give them access to a write connection, but I want to give them access to a runbook that allows them to select a row and just flip that one column for that row.

When I tried from the non-admin, under-permissioned user, I kept seeing errors saying that, before accessing the runbook, the user needed to have access to the connection that the runbook uses. I ran into similar issues in the UI where the non-admin users were able to see but not submit anything from the runbook.

EmanuelJr2mo ago

@jackoberman makes complete sense; you would also need to use the Access Request to help mitigate this problem. I’ll escalate this, as it’s a valid concern.