Unanswered Questions tagged with AWS Control Tower

Content language: English

Sort by most recent

Browse through the questions and answers listed below or filter and sort to narrow down your results.

  • 1
  • 12 / page

Policies applied on organization trail logs bucket created by AWS Tower

Hello, We just setup AWS Tower on our organization. Everything ran smoothly but we detected a strange policy applied by AWS Tower on the bucket responsible to aggregate Cloudtrail trails from all of our organization. This bucket is located on the Log Archive account of Tower architecture. The policy is : ``` { "Sid": "AWSBucketDeliveryForOrganizationTrail", "Effect": "Allow", "Principal": { "Service": "cloudtrail.amazonaws.com" }, "Action": "s3:PutObject", "Resource": [ "arn:aws:s3:::CLOUDTRAIL_BUCKET/ORGANIZATION_ID/AWSLogs/ORGANIZATION_ID/*" ] } ``` This policy allows `cloudtrail` service to push objects on the provided path. Out of curiosity, we tried to configure a Cloudtrail trail located on non-related AWS account (by non-related I mean an AWS account that doesn't belong to the AWS organization) to use this S3 path to push data on. And it worked. Is there any reason why this policy doesn't have a `condition` field to restrict access to accounts that belong to the organization like : ``` "Condition": { "StringEquals": { "aws:PrincipalOrgID": [ "ORGANIZATION_ID" ]} } } ``` Our Tower landing zone version is 3.0. This version enabled Organization-based trail instead of Account-based trails, so I think this policy exists since this version. I know there are some non easily guessable variables (like the Org ID and the bucket name) in the process, but as a compliance tool, AWS Tower should restrict access to the organization itself as it's restricted to it by design. Thanks for your time
0
answers
1
votes
31
views
asked 8 days ago

AWS Control Tower 3.0 creates two Config Aggregators - why?

I created a new organization using AWS Control Tower (version 3.0). It seems that it has created two aggregators: * An accounts aggregator under the audit account named control `aws-controltower-GuardrailsComplianceAggregator`. This aggregator is defined to collect from specific accounts (all member accounts, excluding the management account), and from all regions. However, at least in my case, the authorizations given from these accounts to aggregation seem messed up - each account was only set up to authorize aggregation from 5 regions, and the aggregator indeed identifies the aggregation from some accounts and regions as failed as a result. FYI, I currently created my control tower landing zone on a single region, not sure why this setup happened. * An organization aggregator in the management account named `aws-controltower-ConfigAggregatorForOrganizations`. This organization aggregator automatically collects from all accounts and regions in the organization, and it is working well. Any idea why both aggregators were defined? I know that until a recent version of the landing zone, there was no support for organization aggregators. But now that it has been added, why keep the account-specific aggregator in the audit account (that seems to be misconfigured anyway)? On the flip side, given that the best practice is to use the audit account for, well, auditing - why is the organization aggregator defined on the management account and not the audit account? Doesn't that mean that to enjoy its aggregation I need to login to the management account? Thanks,
0
answers
0
votes
56
views
Spock
asked 3 months ago

Enforce Tags SCP for DynamoDB is not working

Hi, I followed this official guide from aws in order to implement a tagging strategy for resources in my AWS Organization https://aws.amazon.com/de/blogs/mt/implement-aws-resource-tagging-strategy-using-aws-tag-policies-and-service-control-policies-scps/ The example is for EC2 instances, I followed all steps and this worked, however when I wanted to replicate the steps for S3, RDS and DynamoDB it did not work. The following is the SCP I want to use in order to enforce the tag *test* to be on every created dynamodb table. This is exactly how it is done in the Guide for EC2. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "Statement1", "Effect": "Deny", "Action": [ "dynamodb:CreateTable" ], "Resource": [ "arn:aws:dynamodb:*:*:table/*" ], "Condition": { "Null": { "aws:RequestTag/test": "true" } } } ] } ``` However when I try to create a DynamoDB Table with the tag *test* I get the following error message. I am passing the tag test, however I still get a deny. ``` User: arn:aws:sts::<account>:assumed-role/<role>/<email> is not authorized to perform: dynamodb:CreateTable on resource: arn:aws:dynamodb:eu-central-1:<table>:<table> with an explicit deny. ``` I tried creating this SCP for the Services RDS, S3 and DynamoDB, only EC2 seems to work. Do you have an idea what the error could be or is anyone using this tagging strategy in their AWS Organization/AWS Control Tower. Would be interested to hear what your experience is as this seems really complicated to me to implement and does not work so far. Looking forward to hear form you people :)
0
answers
0
votes
49
views
asked 8 months ago
  • 1
  • 12 / page