Allowed AMIs in Amazon EC2 (Part 1)

By Ashwin Venugopal -

 





Control the Discovery and Use of AMIs in Amazon EC2 with Allowed AMIs

To manage the discovery and utilization of Amazon Machine Images (AMIs) by users in your AWS account, the Allowed AMIs feature can be utilized. This feature enables you to define criteria that AMIs must fulfill to be visible and accessible within your account. Once these criteria are activated, users launching instances will only see and be able to use AMIs that meet the established standards. For instance, you could create a list of trusted AMI providers as part of the criteria, ensuring that only AMIs from these providers are visible and available for use.

Prior to activating the Allowed AMIs settings, you can turn on audit mode to see which AMIs will be visible and available for use. This allows you to adjust the criteria as necessary to make sure that only the intended AMIs are accessible to users within your account. Furthermore, you can execute the describe-instance-image-metadata command and apply filters to the response to find any instances that were initiated with AMIs that do not satisfy the defined criteria.

You set the Allowed AMIs configurations at the account level, either explicitly in the account or via a declarative policy. These configurations need to be established in every AWS Region where you want to manage the discovery and utilization of AMIs. By using a declarative policy, you can implement the configurations across several Regions at once, as well as across multiple accounts simultaneously. If a declarative policy is being utilized, you are unable to change the settings directly within an account.

Key benefits of Allowed AMIs

  • Compliance and security: Users can only discover and use AMIs that meet the specified criteria, reducing the risk of non-compliant AMI usage.

  • Efficient management: By reducing the number of allowed AMIs, managing the remaining ones becomes easier and more efficient.

  • Centralized account-level implementation: Configure the Allowed AMIs settings at the account level, either directly within the account or through a declarative policy. This provides a centralized and efficient way to control AMI usage across the entire account.

How Allowed AMIs works

You define parameters that automatically filter and identify which AMIs are available and can be utilized within your account. You outline the parameters in a JSON configuration, and then activate them by executing the enable API operation.

JSON Configuration for the Allowed AMIs Criteria

The core configuration for Allowed AMIs is the JSON configuration that defines the criteria for allowed AMIs.

Supported Criteria

At present, the criteria that are supported consist solely of AMI providers. Acceptable values include aliases specified by AWS and AWS account IDs, as detailed below:

  • amazon - An alias that identifies AMIs created by AWS Allowed AMIs 201 Amazon Elastic Compute Cloud User Guide

  • aws-marketplace - An alias that identifies AMIs created by verified providers in the AWS Marketplace

  • aws-backup-vault - An alias that identifies backup AMIs that reside in logically air-gapped AWS Backup vault accounts. If you use the AWS Backup logically air-gapped vault feature, ensure this alias is included as an AMI provider.

  • AWS account IDs - One or more 12-digit AWS account IDs

  • none - Indicates that only AMIs created by your account can be discovered and used. Public or shared AMIs can't be discovered and used. If you specify none, you can't specify an alias or account ID.

How criteria are evaluated

The criteria in the JSON configuration are assessed with an "or" condition. This indicates that an AMI only needs to correspond with one of the designated providers in any ImageCriteria object to be deemed permissible. For instance, if you define both Amazon and an AWS account ID as providers, AMIs from either of these sources will be permitted.

Limits for the JSON Configuration

  • ImageCriteria objects: Maximum of 10 ImageCriteria objects can be specified in a single configuration.

  • ImageProviders values: Maximum of 200 values across all ImageCriteria objects.

Conclusion

Allowed AMIs and their various features are discussed in detail. 














































Comments

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different...
Read more

Deployment (Part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Azure Resources Microsoft Sentinel needs following resources to be created: Subscription (if a dedicated subscription(s) will be used) Resource group(s) Log Analytics workspace(s) Automation rules/playbook Alert rules Workbooks Microsoft Sentinel offers hundreds of alert rules, workbooks, and automation playbook templates along with hunting scripts. The templates can be used to activate/deploy schedule alerts, create customized dashboards, create automation playbooks and perform threat-hunting activities. Generally, once deployed, the resources created have to be adjusted to match the existing environment, configure local credentials, etc. Methods of deployment: Manual- Administrator can manually configures the Microsoft Sentinel resources with the help of Azure portal. Any manual process has the inherent risks of human operator error, lack of compliance with potential change control procedures, and u...
Read more

Deployment (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 3, please click  here Microsoft Sentinel Content Hub Content in Microsoft Sentinel includes any of the following types: Data connectors offer log ingestion from different sources into Microsoft Sentinel. Parsers give log formatting/transformation into ASIM formats, supporting usage across various Microsoft Sentinel content types and scenarios. Workbooks provide monitoring, visualization, and interactively with data in Microsoft Sentinel, highlighting meaningful insights for users.  Analytics rules give alerts that point to relevant SOC actions via incidents.  Hunting Queries are used by SOC teams to proactively hunt for threats in Microsoft Sentinel. Notebooks help SOC teams in using advanced hunting features in Jupyter and Azure Notebooks. Watchlists support the ingestion of specific data for enhanced threat detection and reduced alert fatigue.  Playbooks and Azure Logic Apps Custom Connectors provide featu...
Read more