Home
Support Forums

Restrict auth tokens to certain actions (create-deploy)

As far as I can tell personal access tokens allow any actions. We’d like to limit the allowed actions to only create a deploy in case a key leaks and a malicious actor e.g. deletes a site.

Context

We’d like to move from netlify’s CD platform to azure since Azure is twice as fast and has way more free minutes.
It seems like we can already do that with the netlify cli (build+deploy) but we need an access token. Since we’d also like to build pull requests from forks we would need to make that token available to these PRs. While there are certain measures in place to prevent leaking it’s never 100% safe. We’d be fine with potential leakage if that only results in deploys being created. But e.g. removing sites is to great of a risk.

2 Likes

Great suggestion, @eps1lon! We don’t have it implemented yet, but I have added your voice to our existing feature request.

However, you don’t have to do this in the way you describe; we already have good support for building PR’s against your repo though, without your contributors doing anything, as long as you (not they) configure builds from git.

But yes, “limited scope” access tokens to allow CLI usage are not available today. We’ll follow up in this thread if we make them available! Not clear that we will, but we’ll see what time brings :slight_smile:

1 Like

However, you don’t have to do this in the way you describe; we already have good support for building PR’s against your repo though

This is not our observation. Building on netlify is slow due to limited resources and requires extra payment from our side. Azure has stronger and cheaper resources which is why we want to offload building onto azure.

Thanks for that feedback!

Just wanted to add on that we’d love to have this feature.

We’re trying to move our build over to GitHub Actions, and we’d like to be able to run deploy previews on PRs from forks without exposing a token that could give a third-party access to our production deploys.

I recognize that this runs counter to Netlify’s business model. We’re a non-profit organization that’s strapped for cash, and 300 build minutes just isn’t enough to cover our needs. It’s unfortunate that we can’t currently outsource our deploy preview builds without risking access to our production deploys, since GitHub Actions offers unlimited build minutes for open-source repos.

1 Like

Do you have an open source project? We don’t sponsor nonprofits in general, but if it is open source, we’ll sponsor a pro account for you, which includes free collaborators, and more build minutes:

1 Like

Yes, we have an open source project.

What does “all internal pages” mean (from the Open Source Plan Policy you linked)? We’d be happy to link to Netlify, but we’re not willing to put it on our main page–given the nature of our specific homepage, we feel that it would be inappropriate to put such a link there.

hi @user1, i would suggest that you apply, and we can discuss in greater detail when we know a bit more about your project?

I second this. Not building inside Netlify is also interesting to remove duplicated work the overall CI. For instance, a team might already build its website inside another CI service in order to keep track of performance metrics on the build, e.g. the bundle size of the generated files.

Thanks for the suggestion! We’ve added your voice to the open feature request and we will follow up in this thread should we start providing such tokens.

This request seems also to be relevant to security considerations when creating Netlify widgets for Sanity, so I assume that it applies to a lot of similar use cases as well.

You can follow the relevant thread on Github regarding this here:
https://github.com/sanity-io/sanity-plugin-dashboard-widget-netlify/issues/14

I would be thankful if you could chime in and point us in a direction, if there are any ways around this security issue, that we have missed so far.

Have a wonderful day! :sunny:

Hi @User2,

Unfortunately there’s no news on this yet.

1 Like

Thank you for the info @hrishikesh! :slightly_smiling_face: