It sounds straightforward.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This issue has been mentioned on Sensu Community. There might be relevant details there:

https://discourse.sensu.io/t/could-not-impliment-check-execute-only-privileges/2450/2

It would be useful to have an execute verb for the checks. I have users that need to re-run the checks but I don't want them to be able to change/delete the checks by accident.

I'm guessing that ExecuteCheck() needs to get its own checkExecuteAttributes() method instead of calling checkCreateAttributes() that uses Verb: "create".

For us this issue is related to sensu/sensu-docs#2968 , because without OIDC we cannot have 2FA login and therefore cannot trust users to create or update checks, since they may contain malicious commands (partially related to #3243 ). This means for security reasons we are forced to "involuntarily" block users from ad-hoc check execution :-(

So, I feel really silly for not thinking about this sooner, but I actually think the system already supports doing this... because to adhoc execute a check, you need permission to create an AdhocRequest. This means that we don't need any special new RBAC verb or anything, users just need create permissions on AdhocRequest.

@jspaleta is going to confirm, and if I'm right, this will become a docs issue.

@echlebek,
Looks like its not working as expected. I don't think AdhocRequest is wired up to RBAC
Also its not listed in sensuctl describe-type all nor does sensuctl describe-type AdhocRequest work

Here's the test I did, using fresh sensu-go-workshop environment, using sensuctl as workshop's 'sensu' user using SENSU_API_KEY envvar from .envrc file.

1. Create cluster role for check-execute

type: ClusterRole
api_version: core/v2
metadata:
  created_by: sensu
  labels:
    sensu.io/managed_by: sensuctl
  name: check-execute
spec:
  rules:
  - resources:
    - adhoc_request
    verbs:
    - get
    - list
    - create
    - update

2. Create cluster-role-binding to bind to similarly named group

type: ClusterRoleBinding
api_version: core/v2
metadata:
  created_by: sensu
  name: check-execute
spec:
  role_ref:
    name: check-execute
    type: ClusterRole
  subjects:
  - name: check-excute
    type: Group

3. Create cluster-role-binding for the view cluster-role to the viewers group

type: ClusterRoleBinding
api_version: core/v2
metadata:
  created_by: sensu
  name: viewers
spec:
  role_ref:
    name: view
    type: ClusterRole
  subjects:
  - name: viewers
    type: Group

4. Create user check-execute who in the groups viewers and check-execute

$ sensuctl user  list
    Username               Groups            Enabled  
──────────────── ────────────────────────── ──────────
  agent           system:agents              true     
  check-execute   viewers,check-execute      true     
  sensu           cluster-admins             true     

5. Create a simple echo string check with workshop subscription

type: CheckConfig
api_version: core/v2
metadata:
  created_by: sensu
  name: test
  namespace: default
spec:
  check_hooks: null
  command: echo "test execution check"
  env_vars: null
  handlers: []
  high_flap_threshold: 0
  interval: 60
  low_flap_threshold: 0
  output_metric_format: ""
  output_metric_handlers: null
  pipelines: []
  proxy_entity_name: ""
  publish: false
  round_robin: false
  runtime_assets: null
  secrets: null
  stdin: false
  subdue: null
  subscriptions:
  - workshop
  timeout: 0
  ttl: 0

6. execute check with sensuctl (as 'sensu' cluster admin)
7. confirm event(s) are created for the test check
8. delete all test check events.
9. Login to workshop web-ui as check-execute user, attempt to execute a check.
10. Watch web-ui tell you it executed the check, but no event is generated.
11. Cry.
12. log out of web-ui
13. using sensuctl as cluster admin user remove viewers group from user 'check-execute' and confirm with login to web-ui user no longer has read access to anything.. its just a big sad lizy with a 404 message.

Also note... using the test procedure above.
If I remove the check-execute group for the user leaving it only in the viewers group and re-test the web-ui will let me attempt a test execute and will tell me it went through (green box in ui telling me to go to events) instead of a red auth error.

So either this is a bug in the api endpoint not returning an errror when it should, or its a bug in the web-ui.

Need to retest the api endpoint directly with curl with an api key. I'll get to that Monday if noone else beats me to it.

This issue has become a bug, that we don't support the correct RBAC setup for AdhocRequest. We simply need to do so.