如何设计SAM部署者策略？强制SAM生成的AWS资源位于PermissionBoundary中 [英] How to design SAM deployer policy? to enforce SAM generated AWS resources to be in PermissionBoundary

问题描述

我们有 someAWSAccount 假定 someaccountrole 的实例配置文件名称为 p



在该帐户中创建了名称为 some-permission-boundary 的托管策略（ someAWSAccount ）。

---

需求为

 资源：
 HelloWorldFunction：
类型：AWS :: Serverless :: Function 
属性：
 CodeUri：你好-world / 
处理程序：app.LambdaHandler 
运行时：nodejs8.10 
事件：
 MySQSEvent：
类型：SQS 
属性：
队列：！GetAtt SomeQueue.Arn 
 BatchSize：10 
 PermissionsBoundary： arn：aws：iam :: $$ {AWS :: AccountId}：policy / some-permission-boundary 
 
 SomeQueue：
类型：AWS :: SQS :: Queue 
  

---

通过强制SAM模板具有 PermissionsBoundary：强制对从上述SAM模板生成的AWS资源实施一些规则 ：aws：iam :: $ {AWS :: AccountId}：policy / some-permission-boundary 作为 Propertie的一部分s 列表

，以便在其中创建的任何AWS资源类型（例如Lambda，SQS，角色，策略等） / p>

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 属性是属性列表的一部分之前不起作用

因此，为此，我们正在考虑在 someAWSAaccount 中设计另一个托管策略，以确保如果SAM模板没有此条目，则 sam deploy 失败： sam deploy --template-file above-SAM-template --profile p

---

部署者策略应采取什么措施（托管策略）的样子，要执行此规则？应该使用此部署者策略分配哪个 Principal ？

或

您是否建议使用其他方法？

解决方案

我不确定您要在此实现什么。因为我们在谈论权限边界，所以我们仅限制访问，而不授予任何权限。

如果您有开发人员，并且想限制他们访问某些资源以及他们创建的lambda函数以拥有这些限制，那么可能是最安全的方法（ （如果适用于您的用例）是创建AWS组织，在组织内创建开发账户，并使用SCP（服务控制策略）限制整个账户。这样，无论将哪些权限添加到您的开发人员（该帐户中的IAM用户（包括root），还是添加到这些lambda函数的任何IAM角色），他们都将无法执行超出该帐户或组织单位所附SCP规定的任务该帐户是其中的一部分。

基本上，您是将权限范围从特定的用户或角色转移到整个帐户，因此您不必担心该帐户中的某人不会兑现

we have someAWSAccount assuming someaccountrole with instance profile name p in AWS.

Managed policy by name some-permission-boundary is created in this account(someAWSAccount). Purpose of creating this boundary policy in this account is mentioned below.

---

Requirement is,

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

---

to enforce some rules to AWS resources generated from above SAM template, by enforcing SAM template to have PermissionsBoundary: "arn:aws:iam::${AWS::AccountId}:policy/some-permission-boundary" as part of Properties list,

so that any AWS resource type( like Lambda, SQS, roles, policies etc...) that are created amidst

sam deploy --template-file above-SAM-template --stack-name somestack --profile p

should be in compliance with rules mentioned in arn:aws:iam::${AWS::AccountId}:policy/some-permission-boundary

---

Developers write these SAM tempates and security team need to make sure that sam deploy does not work until this PermissionsBoundary property is part of the Properties list of SAM template.

So, for this, we are thinking to design another managed policy in someAWSAaccount that make sure sam deploy fails if SAM template does not have this entry: sam deploy --template-file above-SAM-template --profile p

---

What should the deployer policy(managed policy) look like, to enforce this rule? Which Principal should get assigned with this deployer policy?

or

Do you suggest an alternate approach?

解决方案

I am not sure what exactly you are trying to achieve here. Since we are talking about permission boundary we are only restricting access, not granting any permissions.

If you have developers and you want to restrict them from having access to some resources as well as lambda functions that they create to have these restrictions then probably the most secure way (if applicable to your use case) is to create AWS Organizations, create development account within the organization and use SCP (service control policy) to restrict the whole account. That way, no matter which permissions are added to your developers (IAM users in that account including root) or any IAM role added to those lambda functions, they will never be able to do more than specified within SCP attached to that account or organizational unit that the account is part of.

Basically, you are moving permission boundaries from the particular user or role to the whole account so you don't have to worry that someone in that account is not going to honor it.

这篇关于如何设计SAM部署者策略？强制SAM生成的AWS资源位于PermissionBoundary中的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！