使用Serverless在部署阶段(CodePipeline)将秘密传递给lambda吗?

我有一个以GitHub为源的CodePipeline,进行了设置。我试图在CodePipeline执行的Deployment阶段将单个秘密参数(在这种情况下为Stripe秘密密钥,当前在.env文件中定义->下面的说明)传递给特定的Lambda,但没有成功。

在我的案例中,部署阶段基本上是一个运行Deployment.sh脚本的CodeBuild项目:

#! /bin/bash npm install -g serverless@1.60.4 serverless deploy --stage $env -v -r eu-central-1

说明:

我尝试使用serverless-dotenv-plugin来完成此操作,该服务器的目的是在本地完成部署,但通过CodePipeline完成部署后,它会在lambda的执行过程中返回错误,原因如下:

由于CodePipeline的Source设置为GitHub(未提交.env文件),所以每当将更改提交到git存储库时,都会触发CodePipeline的执行。到部署阶段时,所有节点模块都已安装(连同它们的serverless-dotenv-plugin),当执行serverless deploy --stage $env -v -r eu-central-1命令时,serverless-dotenv-plugin将搜索存储我的机密的.env文件,因为没有.env文件,所以找不到它,因为我们不在“本地”范围内,并且当lambda需要此秘密触发器时,它将引发如下错误:

使用Serverless在部署阶段(CodePipeline)将秘密传递给lambda吗?

所以我的问题是,可以使用dotenv / serverless-dotenv-plugin来做到这一点,还是应该放弃这种方法?我应该使用SSM参数存储还是Secrets Manager?如果是,有人可以解释一下吗? :)

hechacn 回答:使用Serverless在部署阶段(CodePipeline)将秘密传递给lambda吗?

因此,在对该主题进行进一步调查后,我认为我已经找到了解决方案。 SSM参数存储与秘密管理器是一个完全不同的主题,但是出于我的目的,我选择SSM Paremeter存储来解决此问题。基本上可以通过两种方式完成。

1。使用AWS参数存储

只需在您的AWS Parameter Store Console中添加密钥,然后将serverless.yml中的值作为Lambda环境变量引用即可。 Serverless Framework能够在部署时从您的AWS Parameter Store帐户中获取值。

provider: environement: stripeSecretKey: ${ssm:stripeSecretKey}

最后,您可以像以前一样在代码中引用它:

const stripe = Stripe(process.env.stripeSecretKey);

PROS::此文件可以与本地.env文件一起用于本地和远程使用,同时保持Lambda代码相同,即。 process.env.stripeSecretKey

缺点::由于解密了机密,然后在部署时将其设置为Lambda环境变量,因此,如果您转至Lambda控制台,则可以用纯文本格式查看机密值。 (这表示一些安全问题)

这使我想到了第二种方法,我发现它更安全,最终选择了:

2。存储在AWS Parameter Store中,并在运行时解密 为避免在AWS Lambda控制台中以纯文本形式公开秘密,您可以改为在运行时对其进行解密。方法如下:

  • 与上述步骤一样,在您的AWS Parameter Store Console中添加机密。

  • 更改您的Lambda代码以直接调用参数存储并在运行时解密该值:

    import stripePackage from 'stripe'; const aws = require('aws-sdk'); const ssm = new aws.SSM();

    const stripeSecretKey = ssm.getParameter( {Name: 'stripeSecretKey',WithDecryption: true} ).promise(); const stripe = stripePackage(stripeSecretKey.Parameter.Value);

小技巧::如果您的Lambda被定义为异步函数,请确保在ssm.getParameter(..之前使用 await 关键字。 。)。promise();)

优点:您的秘密在任何时候都不会以纯文本形式公开。

缺点::您的Lambda代码确实变得更加复杂,并且由于需要从存储中获取值而增加了延迟。 (但是考虑到这只是一个参数并且它是免费的,所以我认为这是一个很好的权衡)

对于结论,我只想提及所有这些以便工作,这需要您调整lambda的策略,以便它可以访问Systems Manager和存储在Parameter Store中的机密,但这很容易通过CloudWatch进行检查。

希望这可以帮助某人,快乐的编码:)

本文链接:https://www.f2er.com/2764500.html

大家都在问