Efficient AWS AMI Management: A Key to Robust Cloud Security

An Amazon Machine Image (AMI) is the foundational building block for launching secure and consistent virtual machines in your cloud environment. Regularly updating and patching these images or AMIs is a crucial pillar of cloud security, as outdated and unpatched systems are prime targets for hackers looking to infiltrate your environment.

However, refreshing AMIs can lead to significant operational overhead without the right tools and processes. Additionally, if AMIs are not updated regularly, major upgrades that skip several intermediate versions become riskier and require more extensive testing.

Stacklet’s governance-as-code platform, built on the Cloud Custodian project, provides comprehensive visibility and continuous enforcement of your AMI policies. As a result, Stacklet reduces risk and operational overhead and frees up your staff’s time in this mundane task.

Stacklet creates and maintains a real-time inventory of all the AMIs in your cloud environment using a cloud asset database (Stacklet AssetDB). Furthermore, Stacklet policies add the functionality of identifying non-compliant AMIs and allow you to take various actions or trigger remediation workflows for them so that the instances are updated and risks are minimized.

This blog will focus on AWS Amazon Machine Images (AMIs) but these same concepts can be extended to AWS Elastic Container Registry (ECR) and other Cloud Providers like Google Cloud Platform (GCP) and Microsoft Azure.

Real time Inventory and Configuration Tracking of Your AMI’s

Stacklet has the capability to detect which AWS AMIs are being used and their age, whether or not they are encrypted, whether they are properly tagged, etc. This data is updated in real time and stored in Stacklet AssetDB. You can access this data with an out of the box dashboards or build your own via simple SQL queries as needed. This significantly cuts down time in compliance reporting requests on AMI’s.

You can create your own policies or leverage out of the box one’s in Stacklet to detect in near real-time non-compliant AMI, e.g., AMIs which are outdated, unencrypted, etc. The cloud security team’s can create policies based on the AMI metadata stored in AssetDB or against real-time events.

Most companies will want different levels of remediation based upon the environment, e.g., Dev, Stage or PROD. Stacklet Policies are designed to be flexible based upon an account group, which in this case, would represent the different environments. This flexibility allows the cloud security and engineering teams to create one policy and apply it to all the account groups in your cloud environment.

Notification and Remediation of non-compliant AMI’s

Stacklet is designed for enterprise cloud environments. Stacklet has the ability to automate and manage fairly complex notification and remediation workflows. Furthermore, notifications can be customized both in terms of the workflow and the method used for notification, e.g., Slack, e-mail, Jira, etc.

Below is an example workflow from another Stacklet blog: Real-World Guide to Automating Remediation Workflows in the Cloud

A few key points:

• For each step in the workflow, you can have one or more notification mechanisms
• The workflow can be customized to fit the operation workflow of the customer

Remediation is arguably the most critical part of cloud security. Without remediation, technical backlogs will continue to grow. Detection of non-compliant resources will continue to generate many duplicate notifications, which will ultimately lead to alert fatigue. Alert fatigue is a double negative: it increases operational overhead and decreases the likelihood of AMI Policy enforcement.

Efficient remediation is a crucial step as it will help decrease operational overhead and improve the security of your cloud environment.

Fortunately, remediation of AMIs can be an integral part of your AMI policy: any AMI that violates the Stacklet policy can generate a notification (or multiple notifications/escalations) with the option of remediating the AMI.

Stacklet’s Advantage: Flexible and Efficient Remediation

A cloud environment is complex. Typically, there are several tiers, e.g., Dev, Staging, and PROD, which will typically require different levels of enforcement. The remediation workflows may also differ based on the environment, e.g., Dev vs. PROD and the application stack.

Fortunately, Stacklet policies support conditionals and variables, which allow you to apply the same policy across your entire cloud environment. Using Stacklet policy variables, you can customize how your policy is enforced in a given environment.

Example AMI Policy

A simple yet powerful Stacklet policy to remediate AMIs which are too old and are therefore obsolete. In this case, the remediation is to de-register the AMI so it can no longer be used.

Key points:

• The policy syntax is easy to read
• There is a remediation action; in this case, it is to de-register the image
• This policy uses an age variable environment-ageout
• By adding this variable, you can use the policy across all environments, such as Dev, Stage, and PROD.
  

The environment-ageout variable is a key example that underscores the flexibility of remediation. It plays a significant role in policy enforcement, allowing you to define variables for each environment based on the level of enforcement you desire. For instance, you can set it to 30 days for the Dev environment and 180 days for PROD.

Finally, you can also modify the notifications of a given policy in a specific environment.

Using Policies as an Enforcement Pipeline

Development teams are familiar with development pipelines, where changes move from Dev to Staging and then to PROD. Enforcement pipelines follow the same concept but apply Stacklet policies instead.

Here is an example of an enforcement pipeline. The policy can be more aggressive since there is no direct customer impact in the Dev environment. An aggressive Dev policy encourages the development teams to absorb the changes with the least risk. Once the enforcement is stable in Dev, apply the same policy to the Staging environment, perhaps with different parameters. Continue enforcing the policy across all environments.

Stacklet provides the capability to notify and remediate the policy in each environment. See the example above.

Summary

This blog has focused on AWS AMIs since this is one of the most common cloud use cases. However, cloud engineering and security teams can use Stacklet capabilities and workflows to extend to other technologies, e.g., AWS ECR and other cloud environments like GCP and Azure.

The flexibility of Stacklet policies can be applied to other crucial cloud security issues. For example, instances without proper tagging or encryption are significant concerns that Stacklet policies can address effectively.

Leveraging Stacklet policies can be a cornerstone to efficient and automated improvement in your cloud security!