Matt Titmus
Matt Titmus
Cog had a really nifty feature that allowed privileged users to create custom API endpoints -- additions to the Cog REST API -- that could be used to trigger commands...
Currently, command output is limited to plain text, as if it was any command line tool. This is adequate for simple use cases, but doesn't allow for the addition of...
Currently Gort only responds to explicit commands, formatted like structured commands. There should be some kind of ability to respond to non-command text, sort of like Slack "triggers" (but not...
Long outputs (such as the help message from `kubectl`) don't generated reasonable output. * Slack: A `invalid_blocks` appears, followed by the text in plain (not monospace) format * Discord: An...
Commands often require access to runtime variables, particularly when interacting with external services, ranging from mundane values (like the URL of a downstream resource) to highly sensitive information (like database...
Currently audit logs are written to the database, but access to them requires querying the table directly. A `gort logs` command would be very helpful. * It should only be...
Some actions may require an especially high level of security to prevent accidental of malicious execution. For these we should allow commands to require a [two-man rule](https://en.wikipedia.org/wiki/Two-man_rule).
Add support for two-factor auth via an authenticator app for specific commands or command bundles.
Currently every command is completely stateless, which is fine most of the time, but occasionally a command may want to store a bit of data to access later, or for...
A rule tester would be helpful for rule development. Maybe something like: ``` $ gort evaluate --user admin \ --rule 'with arg[0] == "user" must have gort:manage_users' --command 'gort user...