AWS Transit VPC GitHub Solution Question #2 - Access Denied

[brichbourg]

Has anyone encounted an access denied error for the cloudTrailLambda getting to the Transit VPC S3 bucket?

[INFO] 2018-05-21T15:52:58.460Z 085dd5fc-5d0f-11e8-ba39-23960ea84bc5 Starting new HTTPS connection (1):

maskednamed-transitvpccloudtrail-us-east-1-acctnumber.s3.amazonaws.com

An error occurred (AccessDenied) when calling the GetObject operation: Access Denied

[jperry1]

Typically as long as the S3 bucket is created with the default settings and in the same region it will work. Maybe try launching it one more time using the same S3 Bucket. You need to have listbucket and getobject permissions set so if there was any deviation from the base permissions you could get an error. 

https://www.paloaltonetworks.com/documentation/81/virtualization/virtualization/bootstrap-the-vm-ser...

[brichbourg]

I'm getting errors from the CloudTrail based bucket that is created, not the bootstrap bucket I created manually before.  I've launched this many times and I continue to get the same permission error on that bucket.

Right now I am just trying to get it to work within the same account.

The CFNs are creating, these are just errors I see on the Lambda function afterwards. 

[jmeurer]

Can you run a test in a Region other than East 1.  I have seen something similar in East 1.

[brichbourg]

Yeah I can try that, but my client has resources in US-EAST-1, so this will still be an issue.

Stay by, I will try US-EAST-2 

[jperry1]

As you are aware also the Cloudtrail bucket name should be unique as well. I have seen issues in conflict of the bucketname being used causing issues. If you are not using part of your username,account name or something to make the Cloudtrail bucket unique I suggest you do so. But as noted in the previous comment it could be a regional issue as well.

[brichbourg]

CT bucket has the account number in the name.

[brichbourg]

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

[jmeurer]

Could you retest.  There was an API call on the AWS side that was not working and appears to be resolved.

[brichbourg]

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.

[jperry1]

Did it work when you later tried to apply again using an AWS assumed role? If it worked did bootstrapping work using assumed role and root role?

[brichbourg]

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.  

[jperry1]

Thanks for the reply. When you have a moment i would like to know what type of rights were being used on the account that failed. What permissions for the account that failed are

1. attached directly

2. attached from group

thanks @brichbourg

[brichbourg]

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.  

[jperry1]

Would you be able to tell me what the access level was prior to making it admin access?