Using serverless.com? Your AWS creds and code are being shared with them | Hacker News Reader

Using serverless.com? Your AWS creds and code are being shared with them

16 pointsalphamacaroon7 comments

Was anyone else under the impression that when you build and deploy using the serverless framework that it was all done locally on your machine? I sure was. But apparently all your code and your AWS credentials are uploaded to their servers where it is built and deployed.

I’ve been having trouble with a deployment using a serverless-component, so I figured I'd load it up in the node debugger— thought I’d be able to step into the component itself and see what was going on.

But to my surprise I couldn’t actually debug it, because the component doesn’t actually exist on my computer…

Apparently the serverless cli is sending a request to a server, and the request seems to include everything serverless needs to build and deploy the actual service— which includes my AWS credentials.

Does anyone else find this a bit strange and concerning? I could see maybe if they made it clear that this was happening, but I've never seen anything in their docs or architecture that says things are built and deployed remotely.

I wanted to see what you meant, so I signed up for an account and followed the prompts to deploy their stock express.js example.

At the AWS provider setup, there was a “?” next to “Provider Credentials”. Hovering over showed this text: “ Providers are a simple way for your team to store and use credentials for cloud platforms across your apps. Looking to use local credentials instead?”

The last sentence links to docs for using local credentials.

This seems to make clear what’s going on.

Edit: To add, maybe I’m just not hip with new front end strategies, but in my mind, if a website asks me to enter data into it and submit a form, I assume the server operator is getting that data. I’d consider that the default, and even sites which claim to keep my data client-side I approach with hesitancy.

Agreed. But the problem is— I've never once given serverless my credentials...

The specific instance in this case is that there is portion of serverless (called serverless-components) where it appears to boost them from your `~/.aws/credentials` file, which seems very inappropriate.

The other scary part to all of this is that the AWS credentials for deployments are usually pretty super-powered.

If I was a hacker, I guess I know what servers I'd have my sights set on right now. A goldmine for super-powered AWS creds (and source code).

Yes, we do this, like other build engines, CI/CD products, and other cloud services. We try to be clear about what's happening and why in this section of the documentation: https://github.com/serverless/components#where-do-components... and we discuss the cloud-based deployment approach elsewhere in the docs.

Further, this is all designed to support and facilitate our upcoming component-scoped permissions, which will significantly reduce required permissions for the Framework, compared to what Serverless Framework Traditional requires.

We'll add more clarity in the docs specifically on credentials and try to make this known upfront.

I’m not sure I’m understanding what’s happening here, I’m using the serverless command line app to deploy a lambda function to AWS from my local terminal. Nowhere in that process is serverless.com required to be involved. Are my AWS credentials being pushed to serverless.com when I do a deploy? If so, how do I disable this? We’re in a regulated industry and serverless.com is not an approved vendor of ours and should not be receiving any of our AWS credentials.

I apologize for the confusion. The original post is misleading and I should have clarified this in my response above (I'm juggling a newborn ATM).

The Serverless Framework open-source experience does not do this. But there are premium features, like Serverless Framework Components (which this post is actually referring to) which do this.

When you use these premium features you must log into the Serverless Framework SaaS offering via your CLI, accept a TOS, etc.

At the same time, we need to make sure our communication on these SaaS offerings and how they work is more clear. With respects to that, we'll collect all of the feedback we can to get this right!

Got it, thanks for the clarification.

Reply on news.ycombinator.com