Skip to main content

Granular access for tasks

Feature RequestsStacksSpacesPoliciesAccess Control

We often use tasks to perform operations that might contain sensitive data like credentials or the state contents. We would like to be able to also control access to the tasks tab so that we enable read/write access to the stack or space but limit their tasks read access.

Workaround
Problem
Status: 🔭 Discovery2 comments

Log in to comment and vote

Comments2

  • Silver Milkshake

    •

    May 15, 2025

    Hi @Marcin Wyszynski
    Thank you for your reply.

    • What kinds of tasks are you running where read-only users shouldn’t see the output?

      • Our use case is to give the ability to use terraform to developers to set up resources like an RDS instance in AWS. Our custom RDS module creates among other things the password to be used by the application and stores it in Vault our secrets manager. Then our application automatically reads the secret from Vault, so no need for Dev teams to ever read the password. The issue arises when there is some troubleshooting that requires to modify the state. We retrieve it via a task and gets logged directly in the Tasks tab for anyone with access to that space to see the password, leading to a rotation.

    • Is it about the command, the result, or something embedded in the logs?

      • It is about what is embedded in the logs, as the Tasks history currently doesn’t allow to remove past runs.

    • Could the sensitive parts be routed elsewhere, or masked?

      • Could be moved to a bucket as per the current documentation, but we want to explore easier DevEx options for us before ideating a whole s3 storage and retrieval process every time we just want to take a look at the state and make easier the import and export of the state.

    • Are stacks working as the right boundary for your workflow? Or is this a sign that “task runner” and “infra delivery” might need to be separated?

      • I advocate to consider the separation of them, for our current use case and need a mere task history read access restriction would suffice. But might not be enough in the future as we automate further the provisioning and maintenance of those resources. Our current main goal we are striving for is making our App Dev Teams Effective Spacelift users to independently manage their infra provisioning via our Terraform modules/abstractions. They only would require to know some basics and we want them to have the power of provisioning in scenarios where all is going good, when troubleshooting or going further than just terraform plan/apply/destroy in the commands we would like to still restrict those to us Admins of Spacelift/DevOps/SRE teams.

    Hope these clarify further the reasoning behind our request and happy to clarify further if needed.

  • Black Breeze

    •

    May 10, 2025

    Thanks for the feedback! We’d love to understand more about the real-world situations you’re trying to manage here. Specifically:

    • What kinds of tasks are you running where read-only users shouldn’t see the output?

    • Is it about the command, the result, or something embedded in the logs?

    • Could the sensitive parts be routed elsewhere, or masked?

    Right now, “read-only” stack access includes task visibility because tasks are usually used for transparency and debugging. But if your use case treats them more like secure automations, that’s a strong signal—and it might tie into how we think about what a stack is.

    Are stacks working as the right boundary for your workflow? Or is this a sign that “task runner” and “infra delivery” might need to be separated?

    Happy to dig deeper—your insight could influence not just permissions, but fundamentals of how we model work in Spacelift.