Consider mechanism for out of band approvals

[RamblingCookieMonster]

Hiyo!

It might be nice to have a plugin to enable out-of-band approvals.

Example workflow:

Abstract:

• User: !Invoke-HighPrivilegeThingy

• Bot:

  • Reaction that command is processing
  • Reaction to indicate command is waiting on approval
  • Output including:
    • <approval #>
    • (reaction, code, etc.)
    • Details on how to list pending approvals

• ApproverUser: Perform some sort of approval

  • !Approve <approval #>

• Bot: Runs intended command

• User: Yay!

Specific example

• wframe: !HighPrivilegeThing -h Server1
• bot: Approval #1234 for command HighPrivilegeThing -h Server 1 from @wframe waiting on approval by reaction or !Approve
• jdoe: !PendingApprovals
• bot:
  ID Command From Whatif <might be tough to standardize this>
1234 HighPrivilegeThing wframe HighPrivilegeThing Server1
1233 AnotherCommand jdoe Some other command whatif
• jdoe: !approve 1234
• psbot: [validates jdoe can approve this command, invokes !HighPrivilegeThing] Output from command

Another specific example

• wframe: !HigherPrivilegeThing -h Server1
• bot: Approval #1234 for command HighPrivilegeThing -h Server 1 from @wframe waiting on approval by !Approve with one-time-password
• bot: [sends out-of-band (e-mail, etc.) approval password for #1234 to specified approvers, including wframe]
• wframe: !Approve 1234 abc123
• bot: [validates abc123 is the token, invokes !HigherPrivilegeThing] Output from command

Design considerations:

• Multiple approval types. e.g.:
  • Slack reactions or PoshBot commands (already in place)
  • Out-of-band options (if a server for webhooks was included, for example)
• Method of securely storing pending commands, including
  • User
  • Time received
  • Originating command
  • Command to run
  • Valid approval types and details
• For chat-based-approval, data on who (user/group) can approve what commands (by command, plugin, or 'this person can approve all the things')
• Configuration to specify timeouts (global for sure, per-command might be nice-to-have)
• Some sort of !PendingApprovals command

Probably missing a bunch, these were just a quick brainstorm, figured it might be worth opening this up for discussion

Cheers!

[devblackops]

@RamblingCookieMonster I could have sworn an issue was created for this but I guess not 😄

This was the major feature added in v0.8.0 with commit 556359c. For now it just supports some builtin commands for approving/denying/listing commands and is documented here.

[RamblingCookieMonster]

Eek! Completely forgot about that, thanks for the reminder!

[devblackops]

Give it a go and let me know what you think! Out of band and reaction-based approvals would be cool. I just wanted to get it working in a basic state.

[RamblingCookieMonster]

Hiii! So I think this is done in the basic form, going to close this out.

Down the line, a more controlled option would be awesome as well, e.g.

Another specific example
wframe: !HigherPrivilegeThing -h Server1
bot: Approval #1234 for command HighPrivilegeThing -h Server 1 from @wframe waiting on approval by !Approve with one-time-password
bot: [sends out-of-band (e-mail, etc.) approval password for #1234 to specified approvers, including wframe]
wframe: !Approve 1234 abc123
bot: [validates abc123 is the token, invokes !HigherPrivilegeThing] Output from command

Where the second factor might be that secret that the bot sent, or some other pluggable thing (e.g. I might like to hook it up so that the approval requires a 2fa code which is validated via radius

You could probably close this issue though, if that was ever a thing we could just open a new issue