Task policy

circle-exclamation

Purpose

Spacelift tasks are a handy feature that allows an arbitrary command to be executed within the context of your fully initialized stack. This feature is designed to make running one-off administrative tasks (eg. resource taintingarrow-up-right) safer and more convenient. It can also be an attack vector allowing evil people to do bad things, or simply a footgun allowing well-meaning people to err in a spectacular way.

Enter task policies. The sole purpose of task policies is to prevent certain commands from being executed, to prevent certain groups or individuals from executing any commands, or to prevent certain commands from being executed by certain groups or individuals.

circle-info

Preventing admins from running tasks using policies can only play an advisory role and should not be considered a safety measure. A bad actor with admin privileges can detach a policy from the stack and run whatever they want. Choose your admins wisely.

Task policies are simple in that they only use a single rule - deny - with a string message. A single match for that rule will prevent a run from being created, with an appropriate API error. Let's see how that works in practice by defining a simple rule and attaching it to a stack:

package spacelift

deny["not in my town, you don't"] { true }

And here's the outcome when trying to run a task:

Data input

This is the schema of the data input that each policy request will receive:

Helpers

In addition to our global helper functions, we also provide the following helpers for task policies:

  • request - an alias for input.request.

  • session - an alias for input.session.

  • stack - an alias for input.stack.

Examples

Let's have a look at a few examples to see what you can accomplish with task policies. You've seen one example already - disabling tasks entirely. That's perhaps both heavy-handed and naive given that admins can detach the policy if needed. So let's only block non-admins from running tasks:

Let's look at an example of this simple policy in the Rego playgroundarrow-up-right.

That's still pretty harsh. We could possibly allow writers to run some commands we consider safe - like resource tainting and untaintingarrow-up-right. Let's try then, and please excuse the regex:

Feel free to play with the above example in the Rego playgroundarrow-up-right.

If you want to keep whitelisting different commands, it may be more elegant to flip the rule logic, create a series of allowed rules, and define one deny rule as not allowed. Let's have a look at this approach, and while we're at it let's remind everyone not to run anything during the weekend:

As usual, this example is available to play around witharrow-up-right.

Last updated

Was this helpful?