Tricky Balance to Strike

There's a natural tension that builds in almost every organization between security and engineering productivity. Tighten the controls too much and you slow everyone down, the process becomes a tax on productivity, morale suffers. Furthermore, when security becomes too cumbersome, devs find a way to circumvent it. If something is standing between them and finishing their work, they'll find creative ways to side-step, with a wink-wink from management who are all incentivized to move fast—making your organization less secure overall.

Although there is no magic bullet, and every organization is different, there are some things that can help:

• Get stakeholders involved early. If they feel like they had a say in process changes, you'll get more support around the process. They'll also catch stuff that doesn't make sense before it becomes policy.

• Don't apply the same rules everywhere. The controls you need around production customer data probably don't make sense for synthetic test data in dev. Or doing something read-only, like viewing dashboards, may not need as strict a control as restarting a production instance.

• Find the pain points and invest time to reduce the friction. Pay attention to where people are struggling. Maybe you can build some self-service tooling, or carve out exceptions.

This was top of mind when we built SPIN. Traditionally, applying the principle of least privilege means cutting fine-grained permissions or spinning up temporary tokens with limited scope—a lot of overhead for every little task. SPIN makes it easy to get the same result without that hassle.

Why not both?!

Spin lets you have your cake and eat it too!

Let's use AWS IAM as an example. It's incredibly powerful—you can define permissions down to individual API actions on specific resources. However, it quickly turns into a tangled mess of policies, roles, and conditions that nobody fully understands. You end up either over-permissioning because it's easier, or spending way too much time crafting the perfect policy for a one-off task.

Instead of carving out fine-grained permissions at the infrastructure level, SPIN lets you narrow the scope of broader service accounts to control access through the notebook itself. Notebook Authors define exactly what actions run. Notebook Users never see the underlying credentials, and they can't go off-script. So instead of writing a custom IAM policy every time someone needs to do something new, you write a notebook. It's faster to write, easier to reason about, and way less painful to maintain.

Examples

• Database query — Your service account has read access to the whole database, but you want someone to run a single canned report. Instead of setting up row-level security or creating a restricted db user, you write a notebook with the exact query and share it in run-mode. They get their report, nothing else.

• Kubernetes restart — Your service account can manage deployments across a namespace, but you just want on-call to be able to restart a specific service when it's misbehaving. One notebook, one button, no kubectl access required.

• S3 upload — Your service account has write access to a bucket, but you only want a user to upload a specific file to a specific path. The notebook defines exactly where the file goes—no wandering around the bucket, no accidental overwrites elsewhere.

In each case, the credential stays broad at the infrastructure level, but the notebook locks down what actually happens. You get least privilege without making your users go through the security hurdles.

Wanna Try It Out?

• Sign Up
• Contact Us
• Docs