Red Hat® Summit and AnsibleFest, together again May 6-9.
Let Ansible keep an eye on your AWS environment
Let Ansible keep an eye on your AWS environment
In a cloud model, the security of the environment and compliance becomes the responsibility of both the end users and the cloud provider. This is what we call the shared responsibility model in which every part of the cloud, including the hardware, data, configurations, access rights, and operating system, are protected. Depending on the local legislation and the origin of the data that is handled (for instance laws like HIPAA, the GDPR in Europe, or the Californian CCPA), you may have to enforce strict rules on your environment and log events for audit purposes. AWS CloudTrail will help you to achieve this goal. The service can collect and record any kind of information coming from your environment and store or send the events to a destination for audit. In addition to security and compliance, this service helps keep track of resource consumption.
Ansible's CloudTrail module is used to leverage the various features of the CloudTrail service to monitor and audit user activities and API calls in the AWS environment. A trail is a configuration that lets us describe an event filter and decide where the matching entries should be sent. The recent 5.0.0 release of the Amazon.aws collection comes with a new Cloudtrail module. This module helps create, configure, and delete a trail. The final destination of a trail can be an S3 bucket or a CloudWatch log. We have also paired the cloudtrail module with a cloudtrail_info module, which helps collect the information of all or a specific trail.
In this blog post, we are going to take a few configuration use cases and show how Ansible's CloudTrail module can be used to automate the same.
To download the amazon.aws collection, you can download it from
- Ansible Galaxy - Community
- Ansible automation hub - Fully supported and signed with your Red Hat subscription
Use Case 1 - Get maximum visibility
Unless a trail is used for a specific activity in a specific region, it is the best practice to enable CloudTrail for all regions. By doing so, we maximize the visibility of the AWS environment so there is no weakness (unmonitored region) that can be exploited by an attacker. This will also make sure that we receive the event history for any new region that AWS will launch in the future.
- name: create multi-region trail amazon.aws.cloudtrail: state: present name: myCloudTrail s3_bucket_name: mylogbucket region: us-east-1 is_multi_region_trail: true tags: environment: dev
The cloudtrail_info module can be used to get all the information about a particular trail or all the trails present. If a trail name is not provided as input to this module, this module will get the information of all trails, including shadow trails, by default. The shadow trails can be skipped by setting [include_shadow_trails] to [False].
# Gather information about the multi-region trail - amazon.aws.cloudtrail_info: trail_names: - arn:aws:cloudtrail:us-east-1:123456789012:trail/myCloudTrail include_shadow_trails: False register: trail_info trail_info : "trail_list": [ { "has_custom_event_selectors": false, "has_insight_selectors": false, "home_region": "us-east-1", "include_global_service_events": true, "is_logging": true, "is_multi_region_trail": true, "is_organization_trail": false, "latest_delivery_attempt_succeeded": "", "latest_delivery_attempt_time": "", "latest_notification_attempt_succeeded": "", "latest_notification_attempt_time": "", "log_file_validation_enabled": false, "name": "myCloudTrail", "resource_id": "arn:aws:cloudtrail:us-east-1:123456789012:trail/myCloudTrail", "s3_bucket_name": "mylogbucket", "start_logging_time": "2022-09-29T11:41:41.752000-04:00", "tags": {"environment": "dev"}, "time_logging_started": "2022-09-29T15:41:41Z", "time_logging_stopped": "", "trail_arn": "arn:aws:cloudtrail:us-east-1:123456789012:trail/myCloudTrail" } ]
Use Case 2 - Manage access to S3 buckets
For this use case, we will manage the access given to the S3 buckets where the trail logs are stored. As mentioned earlier, shared responsibility includes sharing the security of the resources as well. S3 buckets are prone to incorrect configurations and are the major source of data leaks. S3 buckets configured with public access allow anyone on the internet to access the data. Ansible's s3_bucket module can be used to set CloudTrail's S3 bucket permissions and policies. This S3 bucket can be passed to the CloudTrail module, which will be used as the destination for the trail-generated logs.
- amazon.aws.s3_bucket: name: mys3bucket state: present public_access: block_public_acls: true ignore_public_acls: true block_public_policy: false restrict_public_buckets: false - name: Create trail with secured s3 bucket amazon.aws.cloudtrail: state: present name: myCloudTrail s3_bucket_name: mys3bucket region: us-east-1 tags: environment: dev
Use Case 3 - Maintain CloudTrail logs integrity
CloudTrail logs are collected to verify the compliance and security of the AWS environment. It is always possible that an attacker can gain access and tamper with these logs to obscure their presence. By enabling log file validation, a digital signature of the log file is generated, which is used to check if the log files are valid and not tampered with.
- name: create a trail with log file validation amazon.aws.cloudtrail: state: present name: myCloudTrail s3_bucket_name: mylogbucket region: us-east-1 log_file_validation_enabled: true tags: environment: dev # Gather information about the trail - amazon.aws.cloudtrail_info: trail_names: - arn:aws:cloudtrail:us-east-1:123456789012:trail/myCloudTrail include_shadow_trails: False register: trail_info trail_info : "trail_list": [ { "has_custom_event_selectors": false, "has_insight_selectors": false, "home_region": "us-east-1", "include_global_service_events": true, "is_logging": true, "is_multi_region_trail": fail, "is_organization_trail": false, "latest_delivery_attempt_succeeded": "", "latest_delivery_attempt_time": "", "latest_notification_attempt_succeeded": "", "latest_notification_attempt_time": "", "log_file_validation_enabled": true, "name": "myCloudTrail", "resource_id": "arn:aws:cloudtrail:us-east-1:123456789012:trail/myCloudTrail", "s3_bucket_name": "mylogbucket", "start_logging_time": "2022-09-29T11:41:41.752000-04:00", "tags": {"environment": "dev"}, "time_logging_started": "2022-09-29T15:41:41Z", "time_logging_stopped": "", "trail_arn": "arn:aws:cloudtrail:us-east-1:123456789012:trail/myCloudTrail" } ]
Use Case 4 - Encrypt the logs
By default, the S3 buckets are protected by an A[mazon server-side encryption method and Amazon S3-managed encryption keys. To add an extra layer of security, you can use the AWS Key Management Service. This is directly manageable and helps protect the log files from any attacker's survey of the environment.
- name: Create an LMS key using lookup for policy JSON amazon.aws.kms_key: alias: my-kms-key policy: "{{ lookup('template', 'kms_iam_policy_template.json.j2') }}" state: present register: kms_key_for_logs - name: Create a CloudTrail with kms_key for encryption amazon.aws.cloudtrail: state: present name: myCloudTrail s3_bucket_name: mylogbucket kms_key_id: "{{ kms_key_for_logs.key_id }}"
Similar to the use cases mentioned above, many parameters allow the CloudTrail logs to be secure, compliant, and manageable. To get more information on how to configure CloudTrail and get the configuration information of an existing trail, please refer to amazon.aws.cloudtrail and amazon.aws.cloudtrail_info.
Now you can see four awesome use cases for Red Hat Ansible Automation Platform and CloudTrail and how they can easily and seamlessly work together to accomplish cloud automation tasks. If you want more blogs on Ansible and AWS, please let us know!
