IAM Permissions for Publishing Logs to CloudWatch LogsĀ – Logging and Monitoring – SCS-C02 Study Guide

IAM Permissions for Publishing Logs to CloudWatch Logs

There is a specific set of permissions that must be enabled for a user or service to send logs to the CloudWatch Logs service:

  • logs:CreateLogDelivery
  • logs:PutResourcePolicy
  • logs:DescribeResourcePolicies
  • logs:DescribeLogGroups

If you have CloudWatch Logs being sent to a log group in CloudWatch Logs, you also need the logs:CreateLogDelivery permission.

IAM Permissions for Publishing Logs to S3 Buckets

If you want to send logs to an S3 bucket, then you must enable the following permissions:

  • logs:CreateLogDelivery
  • s3:GetBucketPolicy
  • s3:PutBucketPolicy

IAM Permissions for Publishing Logs to Kinesis Data Firehose

There is a specific set of permissions that must be enabled for a user or service to send logs to the Kinesis Data Firehose service:

  • logs:CreateLogDelivery
  • firehose:TagDeliveryStream
  • iam:CreateServiceLinkedRole

If you are setting up the service for the first time, you also need to add the permissions of logs:CreateLogDelivery and firehose:TagDeliveryStream.

You just looked at a triad of options available for different AWS services that help you build your account. There is a separate set of logs generated when users (and services) gain authentication and authorization to the AWS platform and when they carry out additions, subtractions, or modifications to the underlying infrastructure. The service capturing all of this is called CloudTrail. In the next section, you will learn how CloudTrail captures activity at the API level.

Logging API Activity with CloudTrail

The service in AWS that enables governance, compliance, risk auditing, and operational auditing is CloudTrail. It does all this by recording the API calls performed either through the AWS Management Console, the AWS CLI, any of the AWS SDKs, or any third-party tool that uses the AWS API. CloudTrail can work in a single account within a single Region, or it can be used to monitor all Regions within that same single account. You can also configure the service to collect events from multiple accounts and then aggregate them in a single bucket for storage. When a company utilizes AWS Organizations often, they oftentimes utilize a specialized account for logging or auditing. Here, the logs from all other accounts in the organization flow into the auditing account, where access is limited except for a select group of individuals.

Figure 7.6: CloudTrail API log flow

To understand how CloudTrail logging works and the information that it captures, review the following components of the service first:

  • Trails: These are the fundamental building blocks of CloudTrail itself, and they contain the configurable options you want to monitor and track. For example, you can create a trail that monitors single or multiple Regions.
  • Events: Each time an API call is made, AWS CloudTrail intercepts and captures that API request and stores it as an event. These events record vital data relating to the API request, which is then stored within a log file. A new event is created for every API request made.
  • Log files: Log files are created approximately every 5 minutes and are delivered to and stored in a target S3 bucket as defined within the associated trail.
  • API activity filters: These provide a search and filter functionality when looking at your API activity history from within the AWS Management Console.

When looking at the different components of the CloudTrail service, one of the main ones to be sure you understand is events.