How to design SAM deployer policy? to enforce SAM

2020-04-30 16:19发布

问题:

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?

回答1:

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.