Does Serverless, Inc ever see my AWS credentials?

I’m trying to sell my company on serverless, but we handle PHI so security’s tight. Our compliance director and CTO had concerns about passing our AWS key and secret to another company.

When doing a serverless deploy, do AWS credentials ever actually pass through to Serverless, Inc?

If not, can someone point me to where in the code I can prove that?

Thanks!

1 Like

Hi there and welcome to the community!

Nope. They never ever do. Whether you do a local deployment using AWS access key and ID or via a role allocated to a deployment profile in the dashboard. We make API requests into your AWS account using your credentials but they are never stored or sent anywhere else.

And with the framework being fully open source and having had a reasonably sized community looking through the code quite a bit, you are welcome to audit the framework itself or get a third party to do so for you if you need to be sure; one of the advantages an open source framework gives you.

When it comes to the Dashboard, you setup a link from our AWS account to your own using an IAM role you have complete control over on your account. So even there, we never see any credentials, its a pure IAM interaction over API that you can disconnect at any time. If you want to see more details about how that role works, we have a video as a part of our free course that describes the process: https://serverless.com/learn/tutorial/what-happens-on-deployment/

If you have any more specific questions please feel free. I was trying to answer as generally as I could.

1 Like

Thank you for the response!

Thanks for this helpful reply!

Is this still the case for Serverless Components? The docs say that component deployment happens “in the cloud” but I’m afraid I don’t understand what that means. Is it running in the SLS cloud? On an SLS account on AWS? On our account on AWS using SLS code? Which servers and accounts do our AWS credentials pass through during deployment?

I had a quick look through the code but couldn’t figure out the deployment architecture and data flow. I really like what SLS is doing, so it would be very helpful to understand this aspect better.

Components are different. They are also being created for a different purpose. Components are designed to fulfill the needs for very specific use cases and also to improve the developer experience massively with goals such as super fast deployment times, live coding in the cloud so you don’t need local emulation as well as live debugging with logs.

I say all this because the only way we found to make those goals feasible and drastically reduce deployment times to make testing in the cloud feel local was to actually move the deployment process off of a developers local machine and make deployments happen in AWS itself so that all the API calls are made on AWS’s local network which massively speeds up deployment.

What this means for your question is that in component’s case, when you deploy a component, at that moment the credentials in your .env is passed to the deployment engine in AWS, deployment is made to your AWS account and the credentials are then deleted by the fact the deployment container is essentially destroyed. So while your credentials are passed from your local machine along with your component configuration, this needs to be done each time.

We are hoping to leverage the same technique we use in the dashboard for the original V1 framework for components with a role and no need for credentials, but at this point we are trying accelerate release of components so folks can get use out of them and we can start getting some feedback to improve where it needs it.

Hope that helps answer the questions

1 Like

That’s very helpful thanks! I can understand how running on AWS would speed things up, I’ve found that true as well for some of our own internal development tasks that operate on AWS services.

I understand from your response how the credentials are used in an ephemeral way during component deployment (as opposed to AWS keys being permanently recorded in our SLS account, for example). Using a role instead of credentials sounds good, so I’m looking forward to that when it’s ready.

The reason I am interested in components is because we are looking to deploy Nextjs on AWS, and SLS support for Nextjs seems to have effectively moved from a V1 style plugin to a component (via a wonderful contributor project).

So just to clarify a little further, the deployment engine is a container created and managed by Serverless Inc? And is the software running on the container open or closed source? If it’s open source, which GitHub repo has the source code?

1 Like

At this point I can say the best way to deploy components is using the new dashboard we have been hard at work on. It uses relatively the same process of creating cross account access that generates temporary access credentials for deployment purposes.