You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following on from my comment in #178 (comment), 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
A DEPLOY_TO_AWS_ORG environment variable was added to the SolutionDeployStack which, if set via the -o switch in the build-s3-dist.sh script will generate a version of the sharr solution that uses KMS kets shared to the Organization.
The MemberStack was changed to take an optional sharedKeyAccount parameter along with a boolean property (deployToOrg) denoting whether the solution is to be deployed to an Org. If true, then the MemberRemediationKey construct just looks up the key from its alias ARN; if false, the key is created by the MemberRemediationKey construct. The key ARN, whether shared or not still gets stored in an SSM parameter in each member account.
A new OrganizationSharedKeyStack was created that takes an OrganizationIdParam parameter and creates a key (using the same key creation method as the MemberRemediationKey construct).
The SolutionDeployStack was modified to create the OrganizationSharedKeyStack and add tagging (Solution tagging #202)
The text was updated successfully, but these errors were encountered:
julian-price
changed the title
Deploy single (pre-region) CMK KMS keys and share to all accounts in the AWS Organization
Deploy single (per-region) CMK KMS keys and share to all accounts in the AWS Organization
Oct 10, 2024
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 #178 (comment), 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 (Solution tagging #202)The text was updated successfully, but these errors were encountered: