Open julian-price opened 3 days ago
I have attached an archive of the code changes - archive.zip.
The code has purposefully been written as additive; that is to say, it will generate the Org shared keys only if an environment variable is set at build time, but by default the solution will not be changed from the original.
Following on from my comment in https://github.com/aws-solutions/automated-security-response-on-aws/issues/178#issuecomment-2363130018, this enhancement request centres on provisioning a single CMK KMS key per region, shared to an AWS Organization to remediate findings with. For obvious reasons, this type of deployment would only be applicable where the sharr solution was deployed in an AWS Organization, but it would greatly reduce the costs of running the solution (in my case about 90% of the costs would be saved by deploying in this manner).
I have implemented a version of the solution locally that creates shared keys.
Changes Made
DEPLOY_TO_AWS_ORG
environment variable was added to theSolutionDeployStack
which, if set via the -o switch in thebuild-s3-dist.sh
script will generate a version of the sharr solution that uses KMS kets shared to the Organization.MemberStack
was changed to take an optionalsharedKeyAccount
parameter along with a boolean property (deployToOrg
) denoting whether the solution is to be deployed to an Org. If true, then theMemberRemediationKey
construct just looks up the key from its alias ARN; if false, the key is created by theMemberRemediationKey
construct. The key ARN, whether shared or not still gets stored in an SSM parameter in each member account.OrganizationSharedKeyStack
was created that takes anOrganizationIdParam
parameter and creates a key (using the same key creation method as theMemberRemediationKey
construct).SolutionDeployStack
was modified to create theOrganizationSharedKeyStack
and add tagging (https://github.com/aws-solutions/automated-security-response-on-aws/issues/202)