Skip to main content

​
EKS Audit Logs Pipeline

​
Overview

EKS Audit Logging allows RAD Security to collect, process, and analyze audit logs directly from EKS control plane to provide comprehensive security insights within the RAD platform. All resources required on customer AWS account are created by RAD Connect with special flag enable_eks_audit_logs_pipeline set to true. If more than one region needs to be connected, additional configuration is required.

​
Key Features

  • Audit Log Collection: Collects audit logs from EKS clusters into a customer-managed S3 bucket
  • Data Synchronization: Syncs audit logs from customer S3 bucket into per-tenant S3 buckets on RAD side
  • Multi-Region Support: Supports multiple AWS regions with proper configuration
  • Automated Processing: Processes and analyzes audit logs for security insights

​
Data Flow

This is how audit logs reach the RAD platform:
  1. EKS Control Plane → CloudWatch Log Groups (/aws/eks/CLUSTER_NAME)
  2. CloudWatch → Kinesis Firehose Delivery Stream
  3. Kinesis Firehose → Customer S3 Bucket
  4. Customer S3 → RAD Security Platform (processed and analyzed)
EKS Audit Logging needs to be enabled for logs to be ingested into RAD. EKS will automatically send the logs to the CloudWatch Log Group /aws/eks/CLUSTER_NAME. A Kinesis Firehose Delivery Stream is used to read from the Log Groups from CloudWatch and send them to a bucket within the same region and account. RAD’s Audit Log Processor will read the data from the bucket, process it, and then store it within an S3 Bucket for each customer.

​
AWS Resources Created

​
Regional Resources

The following components get created within a Customer’s AWS Account:
  • CloudWatch: A special subscription filter is created to gather all relevant Log Groups for EKS
  • Kinesis Firehose: Used to send the logs from CloudWatch to the Customer S3 Bucket
  • Customer S3 Bucket: Used to store audit logs. It is created on the customer’s AWS account and is used to store logs collected by Kinesis Firehose from multiple EKS clusters. Audit logs from multiple EKS clusters end up in a single S3 bucket. The IAM Role rad-audit-logs is granted permission to read from the S3 Bucket that gets created.

​
Global Resources

  • IAM Roles are created:
    • rad-cloudwatch-logs is required for CloudWatch to be able to forward logs into a Firehose instance
    • rad-firehose is required for Firehose to be able to store audit logs in S3 bucket
Multi-Region Consideration: To prevent duplicate global resources, special configuration is needed to connect a second region for audit logging.

​
Configuring Multiple Regions

To connect a second region, a second copy of the module needs to be defined. secondary_region and enable_eks_audit_logs_pipeline need to be set to true. If secondary_region is not set to true, the module will attempt to make duplicate IAM Roles and account registrations within RAD for Cloud Connect. The module will reuse the rad-firehose IAM Role by passing the output eks_audit_log_firehose_role_arn from the first module to the input eks_audit_logs_firehose_iam_role_arn of the second. The same thing is needed for the rad-cloudwatch-logs IAM Role. That relies on the eks_audit_log_cloudwatch_role_arn input and eks_audit_logs_cloudwatch_iam_role_arn output. To configure a second region within the same state in Terraform, a second AWS Provider needs to be created and passed to the second definition of the RAD AWS Module.

​
Terraform Configuration Example

provider "rad-security" {
  access_key_id        = "REDACTED"
  secret_key           = "REDACTED"
}

provider "aws" {
  alias  = "us-west-2"
  region = "us-west-2"
}

module "rad-security-connect" {
  source  = "rad-security/rad-security-connect/aws"
  version = "0.5.0"

  providers = {
    aws = aws.us-west-2
  }

  aws_external_id                = "123456"
  enable_eks_audit_logs_pipeline = true

  tags = {
    "CreatedBy" : "Terraform"
  }
}

provider "aws" {
  alias  = "eu-west-1"
  region = "eu-west-1"
}

module "rad-security-connect-eu-west-1" {
  source  = "rad-security/rad-security-connect/aws"
  version = "0.5.0"
  
  providers = {
    aws = aws.eu-west-1
  }

  secondary_region                  = true
  enable_eks_audit_logs_pipeline    = true
  eks_audit_log_firehose_role_arn   = module.rad-security-connect.eks_audit_logs_firehose_iam_role_arn
  eks_audit_log_cloudwatch_role_arn = module.rad-security-connect.eks_audit_logs_cloudwatch_iam_role_arn

  tags = {
    "CreatedBy" : "Terraform"
  }
}

​
Prerequisites

Before enabling EKS Audit Logs Pipeline:
  • EKS Cluster: Active EKS cluster with audit logging enabled
  • AWS Permissions: Sufficient IAM permissions to create required resources
  • RAD Connect: RAD Connect module configured with enable_eks_audit_logs_pipeline = true

​
Security Considerations

  • Data Privacy: Audit logs are processed and stored securely within RAD’s infrastructure
  • Access Control: IAM roles follow least privilege principles
  • Encryption: Data is encrypted in transit and at rest
  • Compliance: Meets AWS and industry compliance requirements

​
Troubleshooting

​
Common Issues

  1. Missing IAM Permissions: Ensure sufficient permissions for resource creation
  2. Region Configuration: Verify proper multi-region setup if applicable
  3. CloudWatch Log Groups: Confirm EKS audit logging is enabled
  4. S3 Bucket Access: Check bucket permissions and policies

​
Monitoring

Monitor the following components:
  • CloudWatch Log Groups: Verify logs are being generated
  • Kinesis Firehose: Check delivery stream status
  • S3 Bucket: Monitor log storage and access
  • RAD Platform: Verify logs are being processed and analyzed

​
Next Steps

After enabling EKS Audit Logs Pipeline:
  1. Review Security Findings: Check the Evidence Room for audit-based security insights
  2. Configure Alerts: Set up notifications for critical audit events
  3. Enable Compliance Monitoring: Activate compliance monitoring based on audit data
  4. Set Up Workflows: Create automated responses to audit-based security events
For additional AWS integration options, see: