Add GuardDutyMasterExecutioniRole.yml CFN stack

GuardDutyMasterExecutionRole.yml

@@ -0,0 +1,27 @@
+AWSTemplateFormatVersion: 2010-09-09
+Description: Configure the GuardDutyMasterExecutionRole to allow GuardDuty enabling script Assume Role into target accounts from the Guard Duty Master account.
+
+Parameters:
+  AdministratorAccountId:
+    Type: String
+    Description: AWS Account ID of the administrator account (the account in which StackSet will be created).
+    MaxLength: 12
+    MinLength: 12
+
+Resources:
+  ExecutionRole:
+    Type: AWS::IAM::Role
+    Properties:
+      RoleName: GuardDutyMasterExecutionRole
+      AssumeRolePolicyDocument:
+        Version: 2012-10-17
+        Statement:
+          - Effect: Allow
+            Principal:
+              AWS:
+                - !Ref AdministratorAccountId
+            Action:
+              - sts:AssumeRole
+      Path: /
+      ManagedPolicyArns:
+        - arn:aws:iam::aws:policy/AmazonGuardDutyFullAccess

README.md

@@ -8,4 +8,12 @@ one public and two private subnets, each divided between two AZs, as well as an
 Internet Gateway for the public subnet and a VPC Flow Log. Actual VPC CIDR 
 assignment and subnet IPs are parameterized. This is intended for use as a StackSet
 to deploy to multiple client accounts, wherein each client account gets a different
-parameter set to define it's VPC IP range.
+parameter set to define it's VPC IP range.
+
+## GuardDutyMasterExecutionRole.yml
+For deployment into all accounts that will run GuardDuty and report findings back
+to the Master account. This can be deployed via StackSets from the Master (assuming
+you have the necessary StackSet execution roles created on Master and client accounts).
+This allows the GuardyDuty setup script to assume role into the client accounts through
+the Master account in order to enable GuardDuty in the clients and accept the 
+invitation from the Master.