Security Configurations for Log Collection: IAM & Permissions

This guide covers the critical security configurations required to enable robust logging and auditing within an AWS environment, specifically focusing on IAM roles, resource-based policies, and cross-account log aggregation for the AWS Certified DevOps Engineer Professional exam.

Learning Objectives

After studying this guide, you should be able to:

• Configure IAM Roles for EC2 instances and on-premises servers to securely transmit logs to CloudWatch and S3.
• Design Resource-based Policies that allow services like VPC Flow Logs and CloudTrail to write to centralized buckets.
• Implement Cross-Account Logging using IAM roles and STS for centralized security auditing.
• Apply KMS Encryption to logs at rest and in transit while ensuring the principal has the necessary key permissions.

Key Terms & Glossary

• IAM Role: An identity you can create in your account that has specific permissions but no permanent credentials.
• Trust Policy: A JSON policy document that defines which principals (services or accounts) can assume the role.
• Service-Linked Role (SLR): A unique type of IAM role that is linked directly to an AWS service, predefined by the service for specific actions (e.g., Security Hub).
• Log Destination: An AWS resource (like a Kinesis stream or S3 bucket) configured to receive logs from another source.
• IAM PassRole: A permission that allows a user to pass an IAM role to an AWS service (e.g., passing a role to an EC2 instance).

The "Big Idea"

In a distributed DevOps environment, visibility is the foundation of security. However, the mechanism used to collect visibility data (logs) must itself be secure. If the logging pipeline is misconfigured, an attacker could disable logging to hide their tracks or exfiltrate sensitive data via the log stream. Secure configuration ensures that only authorized entities can write logs and that those logs remain immutable and encrypted.

Formula / Concept Box

Hierarchical Outline

1. Identity-Based Security for Agents
   • EC2 Instance Profiles: Attaching roles to instances to avoid hardcoding keys.
   • On-Premises Connectivity: Using IAM users with long-term keys or IAM Roles Anywhere for hybrid logging.
2. Resource-Based Security
   • S3 Bucket Policies: Restricting s3:PutObject to specific VPC CIDRs or service principals.
   • CloudWatch Logs Resource Policies: Allowing Route 53 or Lambda to write logs across accounts.
3. Cross-Account Collection Patterns
   • Centralized Logging Account: Using a dedicated "Log Archive" account.
   • Organization-level CloudTrail: Aggregating logs from all accounts into one master bucket.
4. Encryption and Compliance
   • KMS Key Policies: Granting the service principal (e.g., logs.amazonaws.com) the right to use a Customer Managed Key (CMK).

Visual Anchors

Log Collection Architecture

IAM Role Components

Definition-Example Pairs

• Term: Least Privilege for Logging

• Definition: Granting only the minimum permissions necessary for an entity to write logs without allowing it to delete or modify existing logs.

• Example: Creating a policy that allows logs:CreateLogStream and logs:PutLogEvents but explicitly omits logs:DeleteLogGroup or logs:DeleteLogStream.

• Term: IAM Permissions Boundary

• Definition: A managed policy that sets the maximum permissions that an identity-based policy can grant to an IAM entity.

• Example: A DevOps admin creates a boundary for a junior developer that prevents them from creating any role that doesn't include specific logging permissions.

Worked Examples

Scenario: Centralizing CloudTrail Logs

Goal: Configure Account A (Production) to send CloudTrail logs to a bucket in Account B (Security).

Step 1: Create the S3 Bucket in Account B. Enable encryption and versioning on the bucket central-audit-logs-account-b.

Step 2: Apply a Bucket Policy in Account B. This policy allows the CloudTrail service to write to the bucket from Account A.

Step 3: Configure CloudTrail in Account A. Specify the S3 bucket from Account B as the destination. CloudTrail uses the service principal, so no additional IAM role is needed on the CloudTrail itself for basic S3 delivery.

Checkpoint Questions

1. Which IAM policy element allows an EC2 instance to assume a role assigned to it?
2. To encrypt CloudWatch logs using a Customer Managed Key (CMK), where must the permission to use the key be granted?
3. What is the difference between an Identity-based policy and a Resource-based policy in the context of S3 logging?
4. How does sts:AssumeRole differ from iam:PassRole?

[!TIP] Answers: 1. The Trust Policy. 2. In the KMS Key Policy, granting logs.amazonaws.com permission. 3. Identity-based is attached to the user/role; Resource-based is attached to the S3 bucket itself. 4. AssumeRole returns temporary credentials; PassRole allows a service to use a role on your behalf.

Muddy Points & Cross-Refs

• Confused about KMS permissions? Remember that when a service (like CloudWatch) is performing encryption, the service principal needs permission in the KMS Key Policy, not just the user who created the log group.
• Logging from On-Premises? Refer to AWS IAM Roles Anywhere to avoid long-term access keys. It uses X.509 certificates to issue temporary credentials.
• Troubleshooting failed log delivery? Check the S3 Bucket Policy first. If s3:x-amz-acl is missing in the CloudTrail request or the bucket policy requires it, the delivery will fail.

Comparison Tables

Identity-Based vs. Resource-Based Policies

[!IMPORTANT] For the DOP-C02 exam, always prioritize Service-Linked Roles over custom roles if the AWS service supports them, as they are managed by AWS and reduce configuration errors.