如何设计 SAM 部署策略?强制 SAM 生成的 AWS 资源处于 PermissionBoundary
How to design SAM deployer policy? to enforce SAM generated AWS resources to be in PermissionBoundary
我们 someAWSAccount
假设 someaccountrole
在 AWS 中具有实例配置文件名称 p
。
在此帐户 (someAWSAccount
) 中创建了名称为 some-permission-boundary
的托管策略。在此帐户中创建此边界策略的目的如下所述。
要求是,
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: hello-world/
Handler: app.LambdaHandler
Runtime: nodejs8.10
Events:
MySQSEvent:
Type: SQS
Properties:
Queue: !GetAtt SomeQueue.Arn
BatchSize: 10
PermissionsBoundary: "arn:aws:iam::${AWS::AccountId}:policy/some-permission-boundary"
SomeQueue:
Type: AWS::SQS::Queue
通过强制 SAM 模板将 PermissionsBoundary: "arn:aws:iam::${AWS::AccountId}:policy/some-permission-boundary"
作为Properties
列表的一部分,
以便在
中创建的任何 AWS 资源类型(如 Lambda、SQS、角色、策略等...)
sam deploy --template-file above-SAM-template --stack-name somestack --profile p
应遵守arn:aws:iam::${AWS::AccountId}:policy/some-permission-boundary
中提到的规则
开发人员编写这些 SAM 模板,安全团队需要确保 sam deploy
在 PermissionsBoundary
属性 成为 SAM Properties
列表的一部分之前不起作用模板。
因此,为此,我们正在考虑在 someAWSAaccount
中设计另一个托管策略,确保 sam deploy
在 SAM 模板没有此条目时失败:sam deploy --template-file above-SAM-template --profile p
执行此规则的部署策略(托管策略)应该是什么样的?应为哪个 Principal
分配此部署策略?
或
您是否建议另一种方法?
我不确定你到底想在这里实现什么。由于我们谈论的是权限边界,我们只是限制访问,而不是授予任何权限。
如果您有开发人员并且您希望限制他们访问某些资源以及他们创建的 lambda 函数以具有这些限制,那么最安全的方法(如果适用于您的用例)可能是创建AWS Organizations,在组织内部创建开发账户,使用SCP(service control policy)对整个账户进行限制。这样,无论向您的开发人员(该账户中的 IAM 用户,包括 root)添加了哪些权限,或向这些 lambda 函数添加了任何 IAM 角色,他们将永远无法执行超出附加到该账户或组织单元的 SCP 中指定的操作该帐户是其中的一部分。
基本上,您正在将权限边界从特定用户或角色转移到整个帐户,因此您不必担心该帐户中的某个人不会遵守它。
我们 someAWSAccount
假设 someaccountrole
在 AWS 中具有实例配置文件名称 p
。
在此帐户 (someAWSAccount
) 中创建了名称为 some-permission-boundary
的托管策略。在此帐户中创建此边界策略的目的如下所述。
要求是,
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: hello-world/
Handler: app.LambdaHandler
Runtime: nodejs8.10
Events:
MySQSEvent:
Type: SQS
Properties:
Queue: !GetAtt SomeQueue.Arn
BatchSize: 10
PermissionsBoundary: "arn:aws:iam::${AWS::AccountId}:policy/some-permission-boundary"
SomeQueue:
Type: AWS::SQS::Queue
通过强制 SAM 模板将 PermissionsBoundary: "arn:aws:iam::${AWS::AccountId}:policy/some-permission-boundary"
作为Properties
列表的一部分,
以便在
中创建的任何 AWS 资源类型(如 Lambda、SQS、角色、策略等...)sam deploy --template-file above-SAM-template --stack-name somestack --profile p
应遵守arn:aws:iam::${AWS::AccountId}:policy/some-permission-boundary
开发人员编写这些 SAM 模板,安全团队需要确保 sam deploy
在 PermissionsBoundary
属性 成为 SAM Properties
列表的一部分之前不起作用模板。
因此,为此,我们正在考虑在 someAWSAaccount
中设计另一个托管策略,确保 sam deploy
在 SAM 模板没有此条目时失败:sam deploy --template-file above-SAM-template --profile p
执行此规则的部署策略(托管策略)应该是什么样的?应为哪个 Principal
分配此部署策略?
或
您是否建议另一种方法?
我不确定你到底想在这里实现什么。由于我们谈论的是权限边界,我们只是限制访问,而不是授予任何权限。
如果您有开发人员并且您希望限制他们访问某些资源以及他们创建的 lambda 函数以具有这些限制,那么最安全的方法(如果适用于您的用例)可能是创建AWS Organizations,在组织内部创建开发账户,使用SCP(service control policy)对整个账户进行限制。这样,无论向您的开发人员(该账户中的 IAM 用户,包括 root)添加了哪些权限,或向这些 lambda 函数添加了任何 IAM 角色,他们将永远无法执行超出附加到该账户或组织单元的 SCP 中指定的操作该帐户是其中的一部分。
基本上,您正在将权限边界从特定用户或角色转移到整个帐户,因此您不必担心该帐户中的某个人不会遵守它。