我有一个用例,Account-A
中的IAM用户可以访问Account-B
中S3存储桶中的文件。
我想从Account-A
中的Lambda函数访问这些文件。
在访问文件时是否需要提及IAM用户的凭证?还有其他选择吗?
答案 0 :(得分:3)
您可以将 IAM角色与AWS Lambda函数关联。该函数运行时,将使用与该IAM角色关联的权限。
如果您的Lambda函数在Account-A
中运行,并且需要访问Account-B
中的Amazon S3对象,则有两种选择:
Account-B
中的存储桶添加存储桶策略,该策略允许IAM角色访问对象或 Account-B
中添加一个IAM角色,该角色有权访问存储桶,并授予Lambda函数承担该角色的权限。然后,Lambda函数将具有临时凭据以访问存储桶。在这种情况下,您具有可以访问Amazon S3中的对象的IAM用户的事实无济于事,因为Lambda函数从IAM角色而不是IAM用户获得其权限。
答案 1 :(得分:0)
执行此操作的最佳方法是在Account-A
中创建具有该功能所需的任何权限的Lambda执行角色,例如在Account-B
中担任跨帐户角色。在大多数情况下,如果Account-B
愿意向Account-A
中的IAM用户授予权限,则可以通过提供具有类似权限的IAM角色来承担责任。这比使用IAM访问密钥安全得多,因为没有永久的凭据泄漏,只有临时的凭据会在最长12小时后过期。
如果由于某种原因您无法在Account-B
中进行任何更改,则可以直接使用现有用户。最简单的方法是将访问密钥ID和秘密访问密钥硬编码到Lambda中,但这从秘密管理的角度引入了很多问题。现在,如果您的代码泄漏了,则Account-B
存储桶中的数据将受到破坏。 AWS Secrets Manager是一个不错的本机选项,用于将密钥存储在代码之外,但需要学习一些API调用才能将其合并到您的函数中。