UPDATED 23:25 GMT January 7, 2021 with comment from Serverless CEO Austen Collins.
Popular open source tool Serverless has become embroiled in a row over an architectural change that has seen it start pulling cloud credentials off users' desktops and sending them to Serverless servers.
Users say they were unaware that this was happening and that it puts "a big target" on Serverless itself -- access to thousands of users' cloud credentials makes Serverless a juicy target for the maliciously minded.
(Serverless.inc is tool that lets developers deploy code to cloud providers like AWS, Azure, and GCP, as well as services like Apache OpenWhisk, Cloudflare Workers, or Kubernetes-based solutions like Knative.)
Serverless credentials row: what's happening, exactly?
Software architect and engineer Jim Heising, managing partner at Internet &.Co and former head of platform at IFTTT, told the The Stack: "A while back, Serverless introduced a feature to their product called Serverless Components. There was... all sorts of great information touting the benefits, so a number of us started using them.
"And to use them, all we had to do was just change a few lines in a configuration file, and voila! Things just worked like they always did.
The only place my AWS creds are stored is in my ~/.aws/credentials file. It just felt super super super sneaky for them to be lifted from there."But there is where the problem starts. What we didn't realize was that the simple act of using these components (changing a couple of lines in a configuration file) all the sudden turned Serverless into a cloud deployment tool. Instead of the tool communicating directly from our computer to our cloud service provider, it was now sending our code and super secret credentials to their servers first, where it was then deployed to our servers.
So the main issues are: 1) they changed their architecture pretty drastically without letting people know in a proper way, and 2) they didn't make you go through those hoops and formal process to hand credentials to them.
He added: "They basically took the code and credentials you thought were being used in confidence between your computer and your cloud provider and started transferring them to their servers without warning. Now their defense is that they do have a readme file on a github page that explains (all the way at the end of many, many, pages) that deploys are being done in the cloud, but most people would never happen on this readme. And most people don't seek out readme's every time a product makes an update."
Reddit there first...
The issue was flagged on Reddit, sparking debate and some disquiet among users. It soon brought in Serverless founder Austen Collins, who responded to concerns: "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: Where Do Components Run? and we discuss the cloud-based deployment approach elsewhere in the docs...
He added: "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." (Austen had not responded to a request to comment as we published).
https://twitter.com/garretro/status/1346832477059506176
Heising told The Stack: "I'm a big fan of Serverless, so I hope this makes them better in the long run so I can go back to using them. But my trust in them is definitely strained at the moment... and with very powerful credentials being sent to their servers and stored there (even if for short periods of time) they definitely have a big target on them now."
Serverless's CEO Austen Collins said in an emailed comment: "We're sad this feature wasn't communicated well enough to our users and we understand the sensitivity here. As Founder/CEO, I'll personally, utterly own this mistake.
"For clarity, this is only for a specific feature of the Framework and it cannot be used until the user has specifically logged into our SaaS dashboard. The CLI freezes until they've done this. A mere YAML change will not automatically shift the user experience.
"That said… it definitely could have been communicated better. Especially because we have been known to do things one way, and we've now learned we have to be extra careful when we try new things! At this time, the README is currently the documentation for this product, and while this new model is explained in other parts of the README, I personally put the full description in the F.A.Q. at the end, because we link to that section often to make users aware of the change, and I didn't want anyone accidentally breaking that link when updating the documentation.
"We've already extensively increased the communication throughout the README/docs and the CLI itself. Next, we will also require users to explicitly put credentials into our SaaS dashboard, and give them convenient ways to reduce permission scope and longevity.
"FWIW, the goal of all of this is to help developers speed up deployments to the cloud. We've built an engine that will deploy 95% faster than current IAC options. If we can speed up deployments, we can help developers work fast, on the real infra they use in production. This is the reason behind the change."
Serverless isn't the only platform to fall afoul of users concerned that potential privacy/compliance/security issues have not been communicated clearly enough. As The Stack's editor reported in June 2020, AWS customers had been sharing sensitive AI data sets including biometrical data and voice inputs with Amazon by default — and many didn’t even know.
The cloud provider was using customers’ “AI content” for its own product development purposes, it noted in its small print (overlooked by most customers) and and reserves the right to store this material outside the geographic regions that AWS customers have explicitly selected.
