今年1月，有人对我们的无服务器组件服务如何使用存储在用户默认配置文件中的AWS凭证提出了担忧。这些担忧是有道理的，并对Serverless Framework如何处理凭证造成了额外的困惑。
作为回应，我们立即更新了我们的文档，并为组件用户增加了更清晰的CLI提示。 现在，在与客户合作以确保成功的迁移路径之后，我们已经从我们的组件服务中完全删除了本地AWS配置文件访问。
归根结底，我们本可以把这个功能设计得更好。 我们对此真的很抱歉。 以下是所发生的事情，以及我们如何修复它。
我们做错了什么
自2015年以来，无服务器框架的模式一直是使用本地存储的凭证将无服务器应用程序从你的机器上直接部署到你自己的云基础设施账户上--这种开源功能从未改变。
然而，我们在去年推出了一项名为无服务器组件的新服务。 这是一项可选的高级服务，需要在serverless.com上创建一个账户并从CLI上登录，以便部署你的应用程序。
组件使用云引擎进行部署，我们公司在自己的安全AWS账户中托管该引擎。 这使得Component用户可以通过源代码缓存等创新技术快速部署，以帮助开发者将变化快速传送到云端。
为了进行部署，Component引擎需要访问用户的源代码和亚马逊网络服务账户凭证。许多用户要求我们自动导入存储在他们的 "默认 "AWS配置文件中的AWS凭证，这是一个由AWS工具、无服务器框架和其他工具支持的惯例。 但组件服务与这些工具不同，因为它在部署过程中引入了一个中间人。这就是我们绊倒的地方。
没有明确指定Components证书的用户可能在不知情的情况下将其默认配置文件中的证书通过我们的云引擎。组件服务也内置于无服务器框架的CLI中，这给框架本身如何处理凭证带来了额外的困惑。我们记录了使用组件服务的不同之处，但最终我们应该更彻底地审查这些设计决策。
我们如何修复它
我们在无服务器公司建立的每项服务和功能都必须让开发者能够安全、可靠地快速移动，并对他们使用的工具充满信心。这意味着，永远不要有惊喜。
为了消除任何进一步混淆的风险，我们已经从组件服务中删除了所有本地凭证处理。
现在，组件需要假设一个AWS IAM角色，组件可以用它来生成临时访问凭证，以执行部署。 此外，组件用户必须通过新的Providers功能，在Serverless Dashboard中明确设置他们的IAM角色。
最后，我们正在努力从无服务器框架CLI中删除组件服务，以更好地分离关注点，使凭证处理更加明确。
如果你有任何问题、担忧或反馈，请联系我们：support@serverless.com。
