Cross-Account event forwarding within an AWS Organization

In today’s multi-account AWS environments, centralizing logs and events across various services and accounts within an AWS Organization is not just a best practice, it’s a necessity for streamlined operations, security monitoring, and compliance. However, achieving this centralization often comes with challenges such as automating cross-account permission or resource deployments.

In this small blog post, we dive deep into the concept of Cross-Account Event Forwarding within an AWS Organization, a powerful strategy designed to centralize the management and analysis of logs and events. By leveraging AWS services such as CloudTrail, S3, and AWS Lambda, alongside robust IAM policies, organizations can create a seamless, automated pipeline for log collection and analysis across all accounts within their AWS Organization. To make things more tangible we will focus on the use case of processing of public certificates upon creation or deletion.

Required AWS Resources

Resource-based Policy — To allow all of the accounts in the AWS Organization to put events in the central event bus we need to ensure sufficient permissions are in place yet ensure that they are restricted enough to adhere to the least-privilege principles. This can be achieved by putting a resource-based policy on the event bus in the central account that adheres to the following format.

{
  "Version": "02-23-2024",
  "Statement": [{
    "Sid": "AllowPutEventsFromWorkloads",
    "Effect": "Allow",
    "Principal": "*",
    "Action": "events:PutEvents",
    "Resource": "arn:aws:events:eu-west-1:{central-account-id}:event-bus/default",
    "Condition": {
      "StringEquals": {
        "aws:PrincipalOrgID": "{your-organization-id}"
      }
    }
  }]
}

This resource-based policy allows IAM entities to put events in the default event bus of our central account only if they are part of the AWS Organization.

IAM Role for Eventbridge — A resource-based policy specifies who is allowed to perform actions on that resource. While you can specify that certain accounts can put events onto the event bus, the entity (user, service or role) in the workload account still needs the appropriate permissions to initiate the putEvents action. Therefore we still need to create a IAM role in the workload accounts that allows events.amazonaws.com to perform the events:putEvents action on arn:aws:events:eu-west-1:{central-account-id}:event-bus/default

Cloudtrail Trail — to ensure that management events are being captured in the first place, a CloudTrail Trail should be deployed in each account so that the Event Rules are able to capture the management actions of “RequestCertificate” and “DeleteCertificate” type.

Processing — to centrally process the events we decouple the event rule and processing logic with an Amazon SNS (FIFO) queue or Amazon SQS FIFO. Finally, this use case is built to allow organizations to synchronize the creation and deletion of AWS Certificates with a third-party Public Certificate Authority (CA). This ensures that deployments of new accounts and networks can be fully automated and guarantees TLS encryption is possible up to the account level entrypoint (such as an Application Load Balancer).

co-authored by Cedric De Schepper