About brichbourg

The access policy the CFN creates.  Below is what the Subscriber role policy looks like.   { "Version": "2012-10-17", "Statement": [ { "Action": [ "sts:AssumeRole" ], "Resource": [ "*" ], "Effect": "Allow", "Sid": "STSAccumRole" }, { "Action": [ "lambda:Invoke", "lambda:InvokeFunction" ], "Resource": [ "*" ], "Effect": "Allow", "Sid": "InvokeLambda" }, { "Action": [ "iam:UpdateAssumeRolePolicy", "iam:GetRole", "iam:PassRole" ], "Resource": [ "*" ], "Effect": "Allow", "Sid": "IAMActions" }, { "Action": [ "cloudformation:*" ], "Resource": [ "*" ], "Effect": "Allow", "Sid": "CloudFormationActions" }, { "Action": [ "ec2:*" ], "Resource": [ "*" ], "Effect": "Allow", "Sid": "EC2FullAccess" }, { "Action": [ "states:ListExecutions", "states:StartExecution" ], "Resource": [ "*" ], "Effect": "Allow", "Sid": "StateMachineActions" }, { "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": [ "*" ], "Effect": "Allow", "Sid": "Logs" }, { "Action": [ "s3:GetBucketAcl", "s3:GetBucketLocation", "s3:GetObject", "s3:GetObjectAcl", "s3:ListBucket", "s3:PutObject", "s3:PutObjectAcl", "s3:PutObjectTagging", "s3:DeleteBucket", "s3:DeleteBucketPolicy", "s3:DeleteObject" ], "Resource": [ "*" ], "Effect": "Allow", "Sid": "S3Actions" }, { "Action": [ "dynamodb:CreateTable", "dynamodb:DeleteItem", "dynamodb:DescribeTable", "dynamodb:GetItem", "dynamodb:GetRecords", "dynamodb:ListTables", "dynamodb:PutItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:TagResource", "dynamodb:UpdateItem", "dynamodb:UpdateTable" ], "Resource": [ "*" ], "Effect": "Allow", "Sid": "DynamoDbActions" }, { "Action": [ "sqs:ChangeMessageVisibility", "sqs:DeleteMessage", "sqs:GetQueueUrl", "sqs:ListQueues", "sqs:ReceiveMessage", "sqs:SendMessage" ], "Resource": [ "*" ], "Effect": "Allow", "Sid": "SQSActions" }, { "Action": [ "sns:Publish" ], "Resource": [ "*" ], "Effect": "Allow", "Sid": "SNSACtions" } ] } ... View more

Root failed as well.  The way we got it to work was to apply admin access to the Subscriber and Transit Lambda execution roles in IAM.   ... View more

I'm about to try root with the customer today.  Root and IAM user works fine in my personal lab account for both US-EAST-1 and US-EAST-2, just not in two of my customer's accounts.   ... View more

I was actually able to get this working a few days ago when I deployed into my lab account as the root user.  Worked in us-east-2 and us-east-1.     I am deploying to a customer account today again, and I get the same error message in S3.  Created an IAM role to give the cloudTrailLambda function admin access (just for testing) and now the solution works.   I am still seeing another error message in the Cloudtrail logs for cloudTrailLambda, but once we gave it admin access the VPN tunnels to a test VPC were created and connected to the PANs.   The only difference between my lab and my customer's environment is I am deploying with my company's AWS account using an an assumed role that has admin access, and I used my root account for my lab.   Even though it is working with the modified Lambda role right now, we are going to attempt to re-deploy tomorrow under the customer's root account to see if that keeps these issues from occuring. ... View more

  I got the solution to finally deploy in US-EAST-2.    ... View more