• 沒有找到結果。

EC2 Image Builder

N/A
N/A
Protected

Academic year: 2022

Share "EC2 Image Builder"

Copied!
250
0
0

加載中.... (立即查看全文)

全文

(1)

EC2 Image Builder

User Guide

(2)

EC2 Image Builder: User Guide

Copyright © Amazon Web Services, Inc. and/or its affiliates. All rights reserved.

Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may not be affiliated with, connected to, or sponsored by Amazon.

(3)

Table of Contents

What is EC2 Image Builder? ... 1

Features of EC2 Image Builder ... 1

Supported operating systems ... 2

Supported image formats ... 2

Concepts ... 2

Pricing ... 4

Related AWS services ... 5

How EC2 Image Builder works ... 6

AMI elements ... 6

Default quotas ... 7

AWS Regions and Endpoints ... 7

Service integrations ... 7

Amazon CloudWatch Logs ... 7

Amazon EventBridge ... 8

AWS CloudTrail ... 9

Component management ... 9

Image testing ... 9

Semantic versioning ... 9

Resources created ... 10

Distribution ... 11

Sharing Resources ... 11

Compliance ... 11

Get started ... 12

Prerequisites ... 12

EC2 Image Builder service-linked role ... 12

Configuration requirements ... 12

Container repository (container image pipelines) ... 13

AWS Identity and Access Management (IAM) ... 13

Access EC2 Image Builder ... 14

Create an image pipeline (AMI) ... 14

Step 1: Specify pipeline details ... 14

Step 2: Choose recipe ... 15

Step 3: Define infrastructure configuration - optional ... 16

Step 4: Define distribution settings - optional ... 16

Step 5: Review ... 17

Step 6: Clean up ... 17

Create an image pipeline (Docker) ... 18

Step 1: Specify pipeline details ... 19

Step 2: Choose recipe ... 19

Step 3: Define infrastructure configuration - optional ... 20

Step 4: Define distribution settings - optional ... 21

Step 5: Review ... 21

Step 6: Clean up ... 21

Component manager ... 23

AWSTOE downloads ... 23

Supported Regions ... 24

Get started with AWSTOE ... 25

Verify signature ... 25

Step 1: Install AWSTOE ... 29

Step 2: Set AWS credentials ... 29

Step 3: Develop component documents locally ... 30

Step 4: Validate AWSTOE components ... 31

Step 5: Run AWSTOE components ... 31

Use component documents ... 33

(4)

Component document workflow ... 33

Component logging ... 34

Input and output chaining ... 35

Document schema and definitions ... 36

Document example schemas ... 38

Define variables ... 41

Use looping constructs ... 45

Action modules ... 53

General execution ... 53

File download and upload ... 57

File system operation ... 65

Software installation actions ... 93

System actions ... 105

Configure input ... 109

STIG components ... 112

Windows STIG components ... 112

Linux STIG components ... 116

SCAP compliance validator component ... 119

Command reference ... 120

run ... 121

validate ... 123

Manage resources ... 125

Components ... 125

List and view components ... 126

Create a component (console) ... 127

Create a component (AWS CLI) ... 128

Component parameters ... 134

Import a component (AWS CLI) ... 136

Clean up resources ... 137

Recipes ... 137

List and view image recipes ... 137

List and view container recipes ... 138

Create image recipes and versions ... 140

Create container recipes and versions ... 146

Clean up resources ... 150

Images ... 150

List and view images ... 150

Create images ... 151

Cancel an image creation (AWS CLI) ... 154

Clean up resources ... 155

Infrastructure configurations ... 155

List and view infrastructure configurations ... 156

Create and update infrastructure configurations ... 156

Distribution settings ... 158

List and view distribution settings ... 158

Create and update AMI distribution ... 159

Create and update container image distribution ... 164

Set up cross-account AMI distribution ... 166

Specify an AMI launch template ... 171

Import and export VM images ... 173

Import a VM into Image Builder (AWS CLI) ... 173

Distribute VM disks from your image build (AWS CLI) ... 174

Share resources ... 174

Working with shared resources ... 175

Prerequisites for sharing components, images, and image recipes ... 175

Related services ... 176

Sharing across Regions ... 176

(5)

Sharing a component, image, or image recipe ... 176

Unsharing a shared component, image, or recipe ... 178

Identifying a shared component, image, or recipe ... 178

Shared component, image, and recipe permissions ... 178

Billing and metering ... 179

Instance limits ... 179

Tag resources ... 179

Tag a resource (AWS CLI) ... 179

Untag a resource (AWS CLI) ... 180

List all of the tags for a specific resource (AWS CLI) ... 180

Delete resources ... 180

Delete resources (console) ... 181

Delete resources (AWS CLI) ... 182

Manage pipelines ... 184

List and view pipelines ... 184

List image pipelines (AWS CLI) ... 184

Get image pipeline details (AWS CLI) ... 185

AMI image pipelines ... 185

Create pipeline (AWS CLI) ... 185

Update pipeline (console) ... 186

Update pipeline (AWS CLI) ... 188

Run pipeline ... 189

Container image pipelines ... 190

Create pipeline (AWS CLI) ... 190

Update pipeline (console) ... 191

Update pipeline (AWS CLI) ... 193

Run pipeline ... 194

Use cron expressions ... 195

Supported values for cron expressions in Image Builder ... 195

Examples of cron expressions in EC2 Image Builder ... 197

Rate expressions ... 198

Use EventBridge rules ... 199

EventBridge terms ... 199

View EventBridge rules for your Image Builder pipeline ... 200

Use EventBridge rules to schedule a pipeline build ... 200

Monitor ... 202

CloudTrail logs ... 202

Image Builder information in CloudTrail ... 202

Security in EC2 Image Builder ... 204

VPC endpoints (AWS PrivateLink) ... 204

Considerations for Image Builder VPC endpoints ... 204

Creating an interface VPC endpoint for Image Builder ... 205

Creating a VPC endpoint policy for Image Builder ... 205

Data protection ... 206

Encryption and Key Management ... 206

Internetwork Traffic Privacy ... 207

Identity and Access Management ... 207

Audience ... 207

Authenticating with identities ... 207

How EC2 Image Builder works with IAM ... 207

Identity-Based Policies ... 211

Resource-Based Policies ... 213

Managed policies ... 213

Service-linked roles ... 227

Troubleshooting IAM ... 228

Compliance validation ... 230

Resilience ... 230

(6)

Infrastructure security ... 231

Configuration and Vulnerability ... 231

Best practices ... 232

Troubleshoot Image Builder ... 236

Troubleshoot pipeline builds ... 236

Troubleshooting scenarios ... 237

Document History ... 240

AWS glossary ... 244

(7)

What is EC2 Image Builder?

EC2 Image Builder is a fully managed AWS service that makes it easier to automate the creation, management, and deployment of customized, secure, and up-to-date server images that are pre- installed and pre-configured with software and settings to meet specific IT standards.

You can use the AWS Management Console, AWS CLI, or APIs to create custom images in your AWS account. When you use the AWS Management Console, the Image Builder wizard guides you through steps to:

• Provide starting artifacts

• Add and remove software

• Customize settings and scripts

• Run selected tests

• Distribute images to AWS Regions

The images you build are created in your account and you can configure them for operating system patches on an ongoing basis.

For troubleshooting and debugging your image deployment, you can configure build logs to be added to your Amazon Simple Storage Service (Amazon S3) bucket. You can also configure the instance-building application to send logs to CloudWatch. To receive notifications of image build status, and associate an Amazon Elastic Compute Cloud (Amazon EC2) key pair with your instance to perform manual debugging and inspection, you can configure an SNS topic.

Along with a final image, Image Builder creates an image recipe, which is a combination of the source image and components for building and testing. You can use the image recipe with existing source code version control systems and continuous integration/continuous deployment pipelines for repeatable automation.

Section Contents

• Features of EC2 Image Builder (p. 1)

• Supported operating systems (p. 2)

• Supported image formats (p. 2)

• Concepts (p. 2)

• Pricing (p. 4)

• Related AWS services (p. 5)

Features of EC2 Image Builder

EC2 Image Builder provides the following features:

Increase productivity and reduce operations for building compliant and up-to-date images Image Builder reduces the amount of work involved in creating and managing images at scale by automating your build pipelines. You can automate your builds by providing your build execution schedule preference. Automation reduces the operational cost of maintaining your software with the latest operating system patches.

Increase service uptime

(8)

Supported operating systems

Image Builder allows you to test your images before deployment with both AWS-provided and customized tests. AWS will distribute your image only if all of the configured tests have succeeded.

Raise the security bar for deployments

Image Builder allows you to create images that remove unnecessary exposure to component security vulnerabilities. You can apply AWS security settings to create secure, out-of-the-box images that meet industry and internal security criteria. Image Builder also provides collections of settings for companies in regulated industries. You can use these settings to help you quickly and easily build compliant images for STIG standards. For a complete list of STIG components available through Image Builder, see EC2 Image Builder STIG components (p. 112).

Centralized enforcement and lineage tracking

Using built-in integrations with AWS Organizations, Image Builder enables you to enforce policies that restrict accounts to run instances only from approved AMIs.

Simplified sharing of resources across AWS accounts

EC2 Image Builder integrates with AWS Resource Access Manager (AWS RAM) to allow you to share certain resources with any AWS account or through AWS Organizations. EC2 Image Builder resources that can be shared are:

• Components

• Images

• Image recipes

• Container recipes

For more information, see Share EC2 Image Builder resources (p. 174).

Supported operating systems

Image Builder supports the following operating systems:

• Amazon Linux 2

• Windows Server 2019/2016/2012 R2

• Windows Server version 2004, and 20H2

• Red Hat Enterprise Linux (RHEL) 8 and 7

• CentOS 8 and 7

• Ubuntu 20, 18, and 16

• SUSE Linux Enterprise Server (SUSE) 15

Supported image formats

For your custom AMI images, you can choose an existing AMI as a starting point. For Docker container images, you can choose from public images hosted on DockerHub, existing container images in Amazon ECR, or Amazon-managed container images.

Concepts

The following terms and concepts are central to your understanding and use of EC2 Image Builder.

(9)

AMI

An Amazon Machine Image (AMI) is the basic unit of deployment in Amazon EC2, and is one of the types of images you can create with Image Builder. An AMI is a pre-configured virtual machine image that contains the operating system (OS) and preinstalled software to deploy EC2 instances. For more information, see Amazon Machine Images (AMI).

Image pipeline

An image pipeline provides an automation framework for building secure AMIs and container images on AWS. The Image Builder image pipeline is associated with an image recipe or container recipe that defines the build, validation, and test phases for an image build lifecycle.

An image pipeline can be associated with an infrastructure configuration that defines where your image is built. You can define attributes, such as instance type, subnets, security groups, logging, and other infrastructure-related configurations. You can also associate your image pipeline with a distribution configuration to define how you would like to deploy your image.

Managed image

A managed image is a resource in Image Builder that consists of an AMI or container image, plus metadata, such as version and platform. The managed image is used by Image Builder pipelines to determine which base image to use for the build. In this guide, managed images are sometimes referred to as "images," however, an image is not the same as an AMI.

Image recipe

An Image Builder image recipe is a document that defines the base image and the components that are applied to the base image to produce the desired configuration for the output AMI image. You can use an image recipe to duplicate builds. Image Builder image recipes can be shared, branched, and edited using the console wizard, the AWS CLI, or the API. You can use image recipes with your version control software to maintain shareable, versioned image recipes.

Container recipe

An Image Builder container recipe is a document that defines the base image and the components that are applied to the base image to produce the desired configuration for the output container image.

You can use a container recipe to duplicate builds. You can share, branch, and edit Image Builder image recipes by using the console wizard, the AWS CLI, or the API. You can use container recipes with your version control software to maintain shareable, versioned container recipes.

Base image

The base image is the selected image and operating system used in your image or container recipe document, along with the components. The base image and the component definitions combined produce the desired configuration for the output image.

Components

A component defines the sequence of steps required to either customize an instance prior to image creation (a build component), or to test an instance that was launched from the created image (a test component).

A component is created from a declarative, plain-text YAML or JSON document that describes the runtime configuration for building and validating, or testing an instance that is produced by your pipeline. Components run on the instance using a component management application. The component management application parses the documents and runs the desired steps.

After they are created, one or more components are grouped together using an image recipe or container recipe to define the plan for building and testing a virtual machine or container image. You

(10)

Pricing

can use public components that are owned and managed by AWS, or you can create your own. For more information about components, see AWS Task Orchestrator and Executor component manager (p. 23).

Component document

A declarative, plain-text YAML or JSON document that describes configuration for a customization you can apply to your image. The document is used to create a build or test component.

Runtime stages

EC2 Image Builder has two runtime stages: build and test. Each runtime stage has one or more phases with configuration defined by the component document.

Configuration phases

The following list shows the phases that run during the build and test stages:

Build stage:

Build phase

An image pipeline begins with the build phase of the build stage when it runs. The base image is downloaded, and configuration that is specified for the build phase of the component is applied to build and launch an instance.

Validate phase

After the instance is launched and all of the build phase customizations are applied, the validation phase begins. During the validation phase, Image Builder validates that customizations are applied successfully, based on configuration that is specified for the validate phase of the component. If the instance validation is successful, the instance is turned off, an image is created, and Image Builder continues to the test stage.

Test stage:

Test phase

The test stage has only one phase – test. During this phase, an instance is launched from the image that was created after the validation phase completed successfully. Image Builder runs test components during this phase to verify that the instance is healthy, and is functioning as expected.

Pricing

There is no cost to use EC2 Image Builder to create custom AMI or container images. However, standard pricing applies for other services that are used in the process. The following list includes the usage of some AWS services that can incur costs when you create, build, store, and distribute your custom AMI or container images, depending on your configuration.

• Launching an EC2 instance

• Storing logs on Amazon S3

• Validating images with Amazon Inspector

• Storing Amazon EBS Snapshots for your AMIs

• Storing container images in Amazon ECR

• Pushing and pulling container images into and out of Amazon ECR

• If Systems Manager Advanced Tier is turned on, and Amazon EC2 instances run with on-premises activation, you might be charged for resources through Systems Manager

(11)

Related AWS services

EC2 Image Builder uses other AWS services to build images. Depending on your Image Builder image recipe or container recipe configuration, the following services might be used.

AWS License Manager

AWS License Manager allows you to create and apply license configurations from an account license configuration store. For each AMI, you can use Image Builder to attach to a preexisting license configuration that your AWS account has access to as part of the Image Builder workflow. License configurations can be applied only to AMIs. Image Builder can use only preexisting license configurations and cannot directly create or modify license configurations. License Manager settings will not replicate across AWS Regions that must be enabled in your account, for example, between the ap-east-1 (Asia Pacific: Hong Kong) and the me-south-1 (Middle East: Bahrain) Regions.

AWS Organizations

AWS Organizations allows you to apply Service Control Policies (SCP) on accounts in your organization.

You can create, manage, enable, and disable individual policies. Similar to all other AWS artifacts and services, Image Builder honors the policies defined in AWS Organizations. AWS provides template SCPs for common scenarios, such as enforcing constraints on member accounts to launch instances with only approved AMIs.

Amazon Inspector

Image Builder uses Amazon Inspector as the default vulnerability scanning agent to establish security baselines for Amazon Linux 2, Windows Server 2012, and Windows Server 2016. For more information, see What is Amazon Inspector?

AWS Systems Manager Automation

An AWS Systems Manager automation document defines the actions that AWS Systems Manager performs on your managed instances and AWS resources. Systems Manager documents use JSON or YAML and include steps and parameters that you specify. The steps you specify run in sequential order.

Automation documents are AWS Systems Manager documents of type Automation, as opposed to Command and Policy documents. For more information, see AWS Systems Manager Automation.

AWS Resource Access Manager

AWS Resource Access Manager (AWS RAM) lets you share your resources with any AWS account or through AWS Organizations. If you have multiple AWS accounts, you can create resources centrally and use AWS RAM to share those resources with other accounts. EC2 Image Builder allows sharing for the following resources: components, images, and image recipes. For more information about AWS RAM, see the AWS Resource Access Manager User Guide. For information about sharing Image Builder resources, see Share EC2 Image Builder resources (p. 174).

Amazon CloudWatch Logs

You can use Amazon CloudWatch Logs to monitor, store, and access your log files from EC2 instances, AWS CloudTrail, Amazon Route 53, and other sources.

Amazon Elastic Container Registry (Amazon ECR)

Amazon ECR is a managed AWS container image registry service that is secure, scalable, and reliable.

Container images you create with Image Builder are stored in Amazon ECR in your default Region, and in any Regions where you distribute the container image. For more information about Amazon ECR, see the Amazon Elastic Container Registry User Guide.

(12)

AMI elements

How EC2 Image Builder works

When you use the EC2 Image Builder pipeline console wizard to create a custom image, a wizard guides you through the following steps.

1.Specify pipeline details – Enter information about your pipeline, such as a name, description, tags, and a schedule to run automated builds. You can choose manual builds, if you prefer.

2.Choose recipe – Choose between building an AMI, or building a container image. For both types of output images, you enter a name and version for your recipe, select a base image, and choose components to add for building and testing. You can also choose automatic versioning, to ensure that you always use the latest available Operating System (OS) version for your base image. Container recipes additionally define Dockerfiles, and the target Amazon ECR repository for your output Docker container image.

NoteComponents are the building blocks that are consumed by an image recipe or a container recipe. For example, packages for installation, security hardening steps, and tests. The selected base image and components make up an image recipe.

3.Define infrastructure configuration – Image Builder launches EC2 instances in your account to customize images and run validation tests. The Infrastructure configuration settings specify infrastructure details for the instances that will run in your AWS account during the build process.

4.Define distribution settings – Choose the AWS Regions to distribute your image to after the build is complete and has passed all its tests. The pipeline automatically distributes your image to the Region where it runs the build, and you can add image distribution for other Regions.

The images that you build from your custom base image are in your AWS account. You can configure your image pipeline to produce updated and patched versions of your image by entering a build schedule. When the build is complete, you can receive notification through Amazon Simple Notification Service (SNS). In addition to producing a final image, the Image Builder console wizard generates a recipe that can be used with existing version control systems and continuous integration/continuous deployment (CI/CD) pipelines for repeatable automation. You can share and create new versions of your recipe.

Section contents

• AMI elements (p. 6)

• Default quotas (p. 7)

• AWS Regions and Endpoints (p. 7)

• Image Builder service integrations (p. 7)

• Component management (p. 9)

• Semantic versioning (p. 9)

• Resources created (p. 10)

• Distribution (p. 11)

• Sharing Resources (p. 11)

• Compliance (p. 11)

AMI elements

An Amazon Machine Image (AMI) is a preconfigured virtual machine (VM) image that contains the OS and software to deploy EC2 instances.

(13)

An AMI includes the following elements:

• A template for the root volume of the VM. When you launch an Amazon EC2 VM, the root device volume contains the image to boot the instance. When instance store is used, the root device is an instance store volume created from a template in Amazon S3. For more information, see Amazon EC2 Root Device Volume.

• When Amazon EBS is used, the root device is an EBS volume created from an EBS snapshot.

• Launch permissions that determine the AWS accounts that can launch VMs with the AMI.

• Block device mapping data that specifies the volumes to attach to the instance after launch.

• A unique resource identifier for each Region, for each account.

• Metadata payloads such as tags, and properties, such as Region, operating system, architecture, root device type, provider, launch permissions, storage for the root device, and signing status.

• An AMI signature for Windows images to protect against unauthorized tampering. For more information, see Instance Identity Documents.

Default quotas

To view the default quotas for Image Builder, see Image Builder Endpoints and Quotas.

AWS Regions and Endpoints

To view the service endpoints for Image Builder, see Image Builder Endpoints and Quotas.

Image Builder service integrations

EC2 Image Builder integrates with the following AWS services to provide detailed event metrics, logging, and monitoring to help you track your activity and troubleshoot image build issues.

Amazon CloudWatch Logs – Monitor, store, and access your Image Builder log files. You can optionally save your logs to an S3 bucket. For more information about CloudWatch Logs, see What Is Amazon CloudWatch Logs? in the Amazon CloudWatch Logs User Guide.

Amazon EventBridge – Connect to a stream of real-time event data from Image Builder activities in your account. For more information about EventBridge, see What Is Amazon EventBridge? in the Amazon EventBridge User Guide.

AWS CloudTrail – Monitor Image Builder events that are sent to CloudTrail. For more information about CloudTrail, see What Is AWS CloudTrail? in the AWS CloudTrail User Guide.

Service integrations

• Amazon CloudWatch Logs (p. 7)

• Amazon EventBridge (p. 8)

• AWS CloudTrail (p. 9)

Amazon CloudWatch Logs

CloudWatch Logs support is enabled by default. Logs are retained on the instance during the build process, and streamed to CloudWatch Logs. The instance logs are removed from the instance before image creation.

(14)

Amazon EventBridge

Build logs are streamed to following the Image Builder CloudWatch Logs group and stream:

• LogGroup: "/aws/imagebuilder/<ImageName>

• LogStream: <ImageVersion>/<ImageBuildVersion>["x.x.x/x"]

You can opt out of CloudWatch Logs streaming by removing the following permissions associated with the instance profile.

"Statement": [ {

"Effect": "Allow", "Action": [

"logs:CreateLogStream", "logs:CreateLogGroup", "logs:PutLogEvents"

],

"Resource": "arn:aws:logs:*:*:log-group:/aws/imagebuilder/*"

} ]

For advanced troubleshooting, you can run predefined commands and scripts using AWS Systems Manager Run Command. For more information, see Troubleshoot EC2 Image Builder (p. 236).

Amazon EventBridge

Amazon EventBridge is a serverless event bus service that you can use to connect your Image Builder application with related data from other AWS services. In EventBridge, a rule matches incoming events and sends them to targets for processing. A single rule can send an event to multiple targets, which then run in parallel.

EventBridge enables you to automate your AWS services and respond automatically to system events such as application availability issues or resource changes. Events from AWS services are delivered to EventBridge in near real time. You can set up rules that react to incoming events to initiate actions;

for example, sending an event to a Lambda function when the status of an EC2 instance changes from pending to running. These are called patterns. To create a rule based on an event pattern, see Creating Amazon EventBridge rules that react to events in the Amazon EventBridge User Guide.

Actions that can be automatically initiated include the following:

• Invoke an AWS Lambda function

• Invoke Amazon EC2 Run Command

• Relay the event to Amazon Kinesis Data Streams

• Activate an AWS Step Functions state machine

• Notify an Amazon SNS topic or an AWS SMS queue

You can also set up scheduling rules for the default event bus to perform an action at regular intervals, such as running an Image Builder pipeline to refresh an image on a quarterly basis. There are two types of schedule expressions:

cron expressions – The following example of a cron expression schedules a task to run every day at noon UTC+0:

cron(0 12 * * ? *)

For more information about using cron expressions with EventBridge, see Cron expressions in the Amazon EventBridge User Guide.

(15)

rate expressions – The following example of a rate expression schedules a task to run every 12 hours:

rate(12 hour)

For more information about using rate expressions with EventBridge, see Rate expressions in the Amazon EventBridge User Guide.

For more information about how EventBridge integrates with Image Builder image pipelines, see Use EventBridge rules with Image Builder pipelines (p. 199).

AWS CloudTrail

This service supports AWS CloudTrail, which is a service that records AWS calls for your AWS account and delivers log files to an Amazon S3 bucket. By using information collected by CloudTrail, you can determine what requests were successfully made to AWS services, who made the request, when it was made, and so on. For more information about CloudTrail integration with Image Builder, see Logging EC2 Image Builder API calls using AWS CloudTrail (p. 202).

To learn more about CloudTrail, including how to turn it on and find your log files, see the AWS CloudTrail User Guide.

Component management

EC2 Image Builder uses a component management application AWS Task Orchestrator and Executor (AWSTOE) that helps you orchestrate complex workflows, modify system configurations, and test your systems with YAML-based script components. Because AWSTOE is a standalone application, it does not require any additional setup. It can run on any cloud infrastructure and on premises. To get started using AWSTOE as a standalone application, see Get started with AWSTOE (p. 25).

Image Builder uses AWSTOE to perform all on-instance activities. These include building and validating your image before taking a snapshot, and testing the snapshot to ensure that it functions as expected before creating the final image. For more information about how Image Builder uses AWSTOE to manage its components, see Manage components with AWSTOE (p. 125). For more information about creating components with AWSTOE, see AWS Task Orchestrator and Executor component manager (p. 23).

Image testing

You can use AWSTOE test components to validate your image, and ensure that it functions as expected, prior to creating the final image.

Generally, each test component consists of a YAML document that contains a test script, a test binary, and test metadata. The test script contains the orchestration commands to start the test binary, which can be written in any language supported by the OS. Exit status codes indicate the test outcome. Test metadata describes the test and its behavior; for example, the name, description, paths to test binary, and expected duration.

Semantic versioning

Image Builder uses semantic versioning to organize resources and ensure that they have unique IDs. The semantic version has four nodes:

<major>.<minor>.<patch>/<build>

You can assign values for the first three, and can filter on all of them.

(16)

Resources created

Semantic versioning is included in each object's Amazon Resource Name (ARN), at the level that applies to that object as follows:

1. Versionless ARNs and Name ARNs do not include specific values in any of the nodes. The nodes are either left off entirely, or they are specified as wildcards, for example: x.x.x.

2. Version ARNs have only the first three nodes: <major>.<minor>.<patch>

3. Build version ARNs have all four nodes, and point to a specific build for a specific version of an object.

Assignment: For the first three nodes you can assign any positive integer value, including zero, with an upper limit of 2^30-1, or 1073741823 for each node. Image Builder automatically assigns the build number to the fourth node.

Patterns: You can use any numeric pattern that adheres to the assignment requirements for the nodes that you can assign. For example, you might choose a software version pattern, such as 1.0.0, or a date, such as 2021.01.01.

Selection: With semantic versioning, you have the flexibility to use wildcards (x) to specify the most recent versions or nodes when selecting the base image or components for your recipe. When you use a wildcard in any node, all nodes to the right of the first wildcard must also be wildcards.

For example, given the following recent versions: 2.2.4, 1.7.8, and 1.6.8, version selection using wildcards produces the following results:

• x.x.x = 2.2.4

• 1.x.x = 1.7.8

• 1.6.x = 1.6.8

• x.2.x is not valid, and produces an error

• 1.x.8 is not valid, and produces an error

Resources created

When you create a pipeline, no resources external to Image Builder are created, unless the following is true:

• When an image is created through the pipeline schedule

• When you choose Run Pipeline from the Actions menu in the Image Builder console

• When you run either of these commands from the API or AWS CLI: StartImagePipelineExecution or CreateImage

The following resources are created during the image build process:

AMI image pipelines

• EC2 instance (temporary)

• Systems Manager Inventory Association (through Systems Manager State Manager) EnhancedImageMetadata is Enabled) on the EC2 instance

• Amazon EC2 AMI

• The Amazon EBS Snapshot associated with Amazon EC2 AMI

Container image pipelines

• Docker container running on an EC2 instance (temporary)

(17)

• Systems Manager Inventory Association (through Systems Manager State Manager) EnhancedImageMetadata is Enabled) on the EC2 instance

• Docker container image

• Dockerfile

After the image has been created, all of the temporary resources are deleted.

Distribution

EC2 Image Builder can distribute AMIs or container images to any AWS Region. The image is copied to each Region that you specify in the account used to build the image.

For AMI output images, you can define AMI launch permissions to control which AWS accounts are permitted to launch EC2 instances with the created AMI. For example, you can make the image private, public, or share with specific accounts. If you both distribute the AMI to other Regions, and define launch permissions for other accounts, the launch permissions are propagated to the AMIs in all of the Regions in which the AMI is distributed.

You can also use your AWS Organizations account to enforce limitations on member accounts to launch instances only with approved and compliant AMIs. For more information, see Managing the AWS accounts in Your Organization.

To update your distribution settings using the Image Builder console, follow the steps to Create a new image recipe version (console) (p. 140), or Create a new container recipe version (console) (p. 146).

Sharing Resources

To share components, recipes, or images with other accounts or within AWS Organizations, see Share EC2 Image Builder resources (p. 174).

Compliance

For CIS, EC2 Image Builder uses Amazon Inspector to perform assessments for exposure, vulnerabilities, and deviations from best practices and compliance standards. For example, it assesses unintended network accessibility, unpatched CVEs, public internet connectivity, and remote root login enablement.

Amazon Inspector is offered as a test component that you can choose to add to your image recipe. For more information about Amazon Inspector, see the Amazon InspectorUser Guide. For hardening, EC2 Image Builder validates using STIG. For a complete list of STIG components available through Image Builder, see EC2 Image Builder STIG components (p. 112). For more information, see Center for Internet Security (CIS) Benchmarks.

(18)

Prerequisites

Get started with EC2 Image Builder

This chapter helps you set up your environment and create an automated image pipeline or container pipeline for the first time, using the EC2 Image Builder Create image pipeline console wizard.

Contents

• Prerequisites (p. 12)

• Access EC2 Image Builder (p. 14)

• Create an image pipeline using the EC2 Image Builder console wizard (p. 14)

• Create a container image pipeline using the EC2 Image Builder console wizard (p. 18)

Prerequisites

Verify the following prerequisites to create an image pipeline with EC2 Image Builder. Unless specifically stated otherwise, prerequisites are required for all types of pipelines.

EC2 Image Builder service-linked role

EC2 Image Builder uses a service-linked role to grant permissions to other AWS services on your behalf.

You don't need to manually create a service-linked role. When you create your first Image Builder resource in the AWS Management Console, the AWS CLI, or the AWS API, Image Builder creates the service-linked role for you. For more information about the service-linked role that Image Builder creates in your account, see Using service-linked roles for EC2 Image Builder (p. 227).

Configuration requirements

• Image Builder supports AWS PrivateLink.

• Image Builder supports EC2-Classic.

• The instances that Image Builder uses to build images and run tests must have access to the Systems Manager service. All build activity is orchestrated by Systems Manager Automation. Installation requirements depend on your operating system.

To see the installation requirements for your base image, choose the tab that matches your base image operating system.

Linux

For Amazon EC2 Linux instances, Image Builder installs the Systems Manager Agent on the build instance if it is not already present, and removes it before creating the image.

Windows

Image Builder does not install the Systems Manager Agent on Amazon EC2 Windows Server build instances. If your base image did not come preinstalled with the Systems Manager Agent, you must launch an instance from your source image, manually install Systems Manager on the instance, and create a new base image from your instance.

To manually install the Systems Manager agent on your Amazon EC2 Windows Server instance, see Manually install Systems Manager Agent on EC2 instances for Windows Server in the AWS Systems Manager User Guide.

(19)

Container repository (container image pipelines)

For container image pipelines, the recipe defines the configuration for the Docker images that are produced and stored in the target container repository. You must create the target repository before you create the container recipe for your Docker image.

Image Builder uses Amazon ECR as its target repository for container images. To create an Amazon ECR repository, follow the steps described in Creating a repository in the Amazon Elastic Container Registry User Guide.

AWS Identity and Access Management (IAM)

The IAM role that you associate with your instance profile must have permissions to run the build and test components included in your image. The following IAM role policies must be attached to the IAM role that is associated with the instance profile:

• EC2InstanceProfileForImageBuilder

• EC2InstanceProfileForImageBuilderECRContainerBuilds

• AmazonSSMManagedInstanceCore

If you configure logging, the instance profile specified in your infrastructure configuration must have s3:PutObject permissions for the target bucket (arn:aws:s3:::BucketName/*). For example:

{ "Version": "2012-10-17", "Statement": [

{

"Effect": "Allow", "Action": [

"s3:PutObject"

],

"Resource": "arn:aws:s3:::bucket-name/*"

} ] }

Attach policy

The following steps guide you through the process of attaching the IAM policies to an IAM role to grant the preceding permissions.

1. Sign in to the AWS Management Console and open the IAM console at https://

console.aws.amazon.com/iam/.

2. In the left navigation pane, choose Policies.

3. Filter the list of policies with EC2InstanceProfileForImageBuilder

4. Select the bullet next to the policy, and from the Policy actions dropdown list, select Attach.

5. Select the name of the IAM role to which to attach the policy.

6. Choose Attach policy.

7. Repeat steps 3-6 for the EC2InstanceProfileForImageBuilderECRContainerBuilds and AmazonSSMManagedInstanceCore policies.

NoteIf you want to copy an image created with Image Builder to another account, you must create the EC2ImageBuilderDistributionCrossAccountRole role in all of the target accounts,

(20)

Access EC2 Image Builder

and attach the Ec2ImageBuilderCrossAccountDistributionAccess policy (p. 223) managed policy to the role. For more information, see Share EC2 Image Builder resources (p. 174).

Access EC2 Image Builder

You can manage EC2 Image Builder from one of the following interfaces.

EC2 Image Builder console landing page. From the EC2 Image Builder console.

AWS Command Line Interface (AWS CLI). You can use the AWS CLI to access AWS API operations.

For more information, see Installing the AWS Command Line Interface in the AWS Command Line Interface User Guide.

AWS Tools for SDKs. You can use AWS SDKs and Tools to access and manage Image Builder using your preferred language.

Create an image pipeline using the EC2 Image Builder console wizard

This tutorial walks you through creating an automated pipeline to build and maintain a customized EC2 Image Builder image using the Create image pipeline console wizard. To help you move through the steps efficiently, default settings are used when they are available, and optional sections are skipped.

Create image pipeline workflow

• Step 1: Specify pipeline details (p. 14)

• Step 2: Choose recipe (p. 15)

• Step 3: Define infrastructure configuration - optional (p. 16)

• Step 4: Define distribution settings - optional (p. 16)

• Step 5: Review (p. 17)

• Step 6: Clean up (p. 17)

Step 1: Specify pipeline details

1. Open the EC2 Image Builder console at https://console.aws.amazon.com/imagebuilder/.

2. To begin creating your pipeline, choose Create image pipeline.

3. In the General section, enter your Pipeline name (required).

Tip

Enhanced metadata collection is turned on by default. To ensure compatibility between components and base images, keep it turned on.

4. In the Build schedule section, you can keep the defaults for the Schedule options. Note that the Time zone shown for the default schedule is Universal Coordinated Time (UTC). For more information about UTC time, and to find the offset for your time zone, see Time Zone Abbreviations – Worldwide List.

For Dependency update settings, choose the Run pipeline at the scheduled time if there are dependency updates option. This setting causes your pipeline to check for updates before starting the build. If there are no updates, it skips the scheduled pipeline build.

(21)

NoteTo ensure that your pipeline recognizes dependency updates and builds as expected, you must use semantic versioning (x.x.x) for your base image and components. To learn more about semantic versioning for Image Builder resources, see Semantic versioning (p. 9).

5. Choose Next to proceed to the next step.

Step 2: Choose recipe

1. Image Builder defaults to Use existing recipe in the Recipe section. For your first time through, choose the Create new recipe option.

2. In the Image type section, choose the Amazon Machine Image (AMI) option to create an image pipeline that will produce and distribute an AMI.

3. In the General section, enter the following required boxes:

Name – your recipe name

Version – your recipe version (use the format <major>.<minor>.<patch>, where major, minor, and patch are integer values). New recipes generally start with 1.0.0.

4. In the Source image section, keep the default values for Select image, Image Operating System (OS), and Image origin. This results in a list of Amazon Linux 2 AMIs, managed by Amazon, for you to choose from for your base image.

a. From the Image name dropdown, choose an image.

b. Keep the default for Auto-versioning options (Use latest available OS version).

NoteThis setting ensures that your pipeline uses semantic versioning for the base image, to detect dependency updates for automatically scheduled jobs. To learn more about semantic versioning for Image Builder resources, see Semantic versioning (p. 9).

5. In the Instance configuration section, keep the default values for the Systems Manager agent.

This results in Image Builder removing the Systems Manager agent after the build and tests are complete, before creating the new image.

Keep User data blank for this tutorial. You can use this area at other times to provide commands, or a command script to run when you launch your build instance. However, it replaces any commands that Image Builder might have added to ensure that Systems Manager is installed. When you do use it, make sure that the Systems Manager agent is preinstalled on your base image, or that you include the install in your user data.

6. In the Components section, you must choose at least one build component.

In the Build components – Amazon Linux panel, you can browse through the components listed on the page. Use the pagination control in the upper right corner to navigate through additional components that are available for your base image OS. You can also search for specific components, or create your own build component using the Component manager.

For this tutorial, choose a component that updates Linux with the latest security updates, as follows:

a. Filter the results by entering the word update in the search bar that's located at the top of the panel.

b. Select the check box for the update-linux build component.

c. Scroll down, and in the upper right corner of the Selected components list, choose Expand all . d. Keep the default for Versioning options (Use latest available component version).

(22)

Step 3: Define infrastructure configuration - optional

NoteThis setting ensures that your pipeline uses semantic versioning for the selected component, to detect dependency updates for automatically scheduled jobs. To learn more about semantic versioning for Image Builder resources, see Semantic versioning (p. 9).

If you had selected a component that has input parameters, you would also see the parameters in this area. Parameters are not covered in this tutorial. For more information about using input parameters in your components, and setting them in your recipes, see Manage AWSTOE component parameters with EC2 Image Builder (p. 134).

Reorder components (optional)

If you have chosen more than one component to include in your image, you can use the drag-and- drop action to rearrange them into the order in which they should run during the build process.

1. Scroll back up to the list of available components.

2. Select the check box for the update-linux-kernel-mainline build component (or any other component of your choice).

3. Scroll down to the Selected components list, to see that there are at least two results.

4. Newly added components might not have their versioning or input parameter settings expanded.

To expand Versioning options or Input parameters settings, you can either choose the arrow next to the name of the setting, or you can toggle the Expand all switch off and on to expand all of the settings for all of the selected components.

5. Choose one of the components, and drag it up or down to change the order in which the components will run.

6. To remove the update-linux-kernel-mainline component, choose X from the upper right corner of the component box.

7. Repeat the previous step to remove any other components you might have added, leaving only the update-linux component selected.

7. Choose Next to proceed to the next step.

Step 3: Define infrastructure configuration - optional

Image Builder launches EC2 instances in your account to customize images and run validation tests. The Infrastructure configuration settings specify infrastructure details for the instances that will run in your AWS account during the build process.

In the Infrastructure configuration section, the Configuration options default to Create infrastructure configuration using service defaults. This creates an IAM role and associated instance profile that are used by build instances to configure your EC2 AMIs. You can also create your own custom infrastructure configuration, or use settings that you have already created. For this tutorial, we are using the default settings.

• Choose Next to proceed to the next step.

Step 4: Define distribution settings - optional

Distribution settings include specific Region settings for encryption, launch permissions, accounts that can launch the output AMI, the output AMI name, license configurations, and Windows AMI faster launching configuration.

(23)

In the Distribution settings section, the Configuration options default to Create distribution settings using service defaults. This option will distribute the output AMI to the current Region. For this tutorial, we are using the default settings. For more information about configuring your distribution settings, see Manage EC2 Image Builder distribution settings (p. 158).

• Choose Next to proceed to the next step.

Step 5: Review

The Review section displays all of the settings you have configured. To edit information in any given section, choose the Edit button located in the top right corner of the step section. For example, if you want to change your pipeline name, choose the Edit button in the top right corner of the Step 1:

Pipeline details section.

1. When you have reviewed your settings, choose Create pipeline to create your pipeline.

2. You can see success or failure messages at the top of the page, as your resources are created for distribution settings, infrastructure configuration, your new recipe, and the pipeline. To see details for a resource, including the resource identifier, choose View details.

3. After you have viewed the details for a resource, you can view details about other resources by choosing the resource type from the navigation pane. For example, to see details for your new pipeline, choose Image pipelines from the navigation pane. If your build was successful, your new pipeline is displayed in the Image pipelines list.

Step 6: Clean up

Your Image Builder environment, just like your home, needs regular maintenance to help you find what you need, and complete your tasks without wading through clutter. Make sure to regularly clean up temporary resources that you created for testing. Otherwise, you might forget about those resources, and then later, not remember what they were used for. By then, it might not be clear if you can safely get rid of them.

Tip

To prevent dependency errors when you delete resources, make sure to delete your resources in the following order:

1. Image pipeline 2. Image recipe

3. All remaining resources

To clean up the resources that you created for this tutorial, follow these steps:

Delete the pipeline

1. To see a list of the build pipelines created under your account, choose Image pipelines from the navigation pane.

2. Select the check box next to Pipeline name to select the pipeline that you want to delete.

3. At the top of the Image pipelines panel, on the Actions menu, choose Delete.

4. To confirm the deletion, enter Delete in the box, and choose Delete.

Delete the recipe

1. To see a list of the recipes created under your account, choose Image recipes from the navigation pane.

(24)

Create an image pipeline (Docker)

2. Select the check box next to Recipe name to select the recipe that you want to delete.

3. At the top of the Image recipes panel, on the Actions menu, choose Delete recipe.

4. To confirm the deletion, enter Delete in the box, and choose Delete.

Delete infrastructure configuration

1. To see a list of the infrastructure configurations created under your account, choose Infrastructure configuration from the navigation pane.

2. Select the check box next to Configuration name to select the infrastructure configuration that you want to delete.

3. At the top of the Infrastructure configurations panel, choose Delete.

4. To confirm the deletion, enter Delete in the box, and choose Delete.

Delete distribution settings

1. To see a list of the distribution settings created under your account, choose Distribution settings from the navigation pane.

2. Select the check box next to Configuration name to select the distribution settings that you created for this tutorial.

3. At the top of the Distribution settings panel, choose Delete.

4. To confirm the deletion, enter Delete in the box, and choose Delete.

Delete the image

Follow these steps to verify that you have deleted any image that was created from the tutorial pipeline.

This tutorial is not likely to create an image unless enough time has elapsed since you created your pipeline that it runs, according to the build schedule.

1. To see a list of the images created under your account, choose Images from the navigation pane.

2. Choose the image Version for the image that you want to remove. This opens the Image build versions page.

3. Select the check box next to the Version for any image that you want to delete. You can select more than one image version at a time.

4. At the top of the Image build versions panel, choose Delete version.

5. To confirm the deletion, enter Delete in the box, and choose Delete.

Create a container image pipeline using the EC2 Image Builder console wizard

This tutorial walks you through creating an automated pipeline to build and maintain a customized EC2 Image Builder Docker image using the Create image pipeline console wizard. To help you move through the steps efficiently, default settings are used when they are available, and optional sections are skipped.

Create image pipeline workflow

• Step 1: Specify pipeline details (p. 19)

• Step 2: Choose recipe (p. 19)

• Step 3: Define infrastructure configuration - optional (p. 20)

• Step 4: Define distribution settings - optional (p. 21)

• Step 5: Review (p. 21)

(25)

• Step 6: Clean up (p. 21)

Step 1: Specify pipeline details

1. Open the EC2 Image Builder console at https://console.aws.amazon.com/imagebuilder/.

2. To begin creating your pipeline, choose Create image pipeline.

3. In the General section, enter your Pipeline name (required).

TipEnhanced metadata collection is turned on by default. To ensure compatibility between components and base images, keep it turned on.

4. In the Build schedule section, you can keep the defaults for the Schedule options. Note that the Time zone shown for the default schedule is Universal Coordinated Time (UTC). For more information about UTC time, and to find the offset for your time zone, see Time Zone Abbreviations – Worldwide List.

For Dependency update settings, choose the Run pipeline at the scheduled time if there are dependency updates option. This setting causes your pipeline to check for updates before starting the build. If there are no updates, it skips the scheduled pipeline build.

NoteTo ensure that your pipeline recognizes dependency updates and builds as expected, you must use semantic versioning (x.x.x) for your base image and components. To learn more about semantic versioning for Image Builder resources, see Semantic versioning (p. 9).

5. Choose Next to proceed to the next step.

Step 2: Choose recipe

1. Image Builder defaults to Use existing recipe in the Recipe section. For your first time through, choose the Create new recipe option.

2. In the Image type section, choose the Docker image option to create a container pipeline that will produce a Docker image and distribute it to Amazon ECR repositories in target Regions.

3. In the General section, enter the following required boxes:

Name – your recipe name

Version – your recipe version (use the format <major>.<minor>.<patch>, where major, minor, and patch are integer values). New recipes generally start with 1.0.0.

4. In the Source image section, keep the default values for Select image, Image Operating System (OS), and Image origin. This results in a list of Amazon Linux 2 container images, managed by Amazon, for you to choose from for your base image.

a. From the Image name dropdown, choose an image.

b. Keep the default for Auto-versioning options (Use latest available OS version).

Note

This setting ensures that your pipeline uses semantic versioning for the base image, to detect dependency updates for automatically scheduled jobs. To learn more about semantic versioning for Image Builder resources, see Semantic versioning (p. 9).

5. In the Components section, you must choose at least one build component.

In the Build components – Amazon Linux panel, you can browse through the components listed on the page. Use the pagination control in the upper right corner to navigate through additional components that are available for your base image OS. You can also search for specific components, or create your own build component using the Component manager.

(26)

Step 3: Define infrastructure configuration - optional

For this tutorial, choose a component that updates Linux with the latest security updates, as follows:

a. Filter the results by entering the word update in the search bar that's located at the top of the panel.

b. Select the check box for the update-linux build component.

c. Scroll down, and in the upper right corner of the Selected components list, choose Expand all . d. Keep the default for Versioning options (Use latest available component version).

Note

This setting ensures that your pipeline uses semantic versioning for the selected component, to detect dependency updates for automatically scheduled jobs. To learn more about semantic versioning for Image Builder resources, see Semantic versioning (p. 9).

If you had selected a component that has input parameters, you would also see the parameters in this area. Parameters are not covered in this tutorial. For more information about using input parameters in your components, and setting them in your recipes, see Manage AWSTOE component parameters with EC2 Image Builder (p. 134).

Reorder components (optional)

If you have chosen more than one component to include in your image, you can use the drag-and- drop action to rearrange them into the order in which they should run during the build process.

1. Scroll back up to the list of available components.

2. Select the check box for the update-linux-kernel-mainline build component (or any other component of your choice).

3. Scroll down to the Selected components list, to see that there are at least two results.

4. Newly added components might not have their versioning expanded. To expand Versioning options, you can either choose the arrow next to Versioning options, or you can toggle the Expand all switch off and on to expand versioning for all of the selected components.

5. Choose one of the components, and drag it up or down to change the order in which the components will run.

6. To remove the update-linux-kernel-mainline component, choose X from the upper right corner of the component box.

7. Repeat the previous step to remove any other components you might have added, leaving only the update-linux component selected.

6. In the Dockerfile template section, select the Use example option. In the Content panel, notice the contextual variables where Image Builder places build information or scripts, based on your container image recipe.

7. In the Target repository section, you must specify the name of an existing Amazon ECR repository that you created as a prerequisite for this tutorial.

NoteThe target repository must exist in Amazon ECR for all target Regions prior to distribution.

8. Choose Next to proceed to the next step.

Step 3: Define infrastructure configuration - optional

Image Builder launches EC2 instances in your account to customize images and run validation tests. The Infrastructure configuration settings specify infrastructure details for the instances that will run in your AWS account during the build process.

(27)

In the Infrastructure configuration section, the Configuration options default to Create infrastructure configuration using service defaults. This creates an IAM role and associated instance profile that are used by build instances to configure your EC2 AMIs. You can also create your own custom infrastructure configuration, or use settings that you have already created. For this tutorial, we are using the default settings.

• Choose Next to proceed to the next step.

Step 4: Define distribution settings - optional

Distribution settings consist of the target Regions, and the target Amazon ECR repository name. Output Docker images are deployed to the named Amazon ECR repository in each Region.

In the Distribution settings section, the Configuration options default to Create distribution settings using service defaults. This option will distribute the output Docker image to the Amazon ECR repository in the current Region. For this tutorial, we are using the default settings.

• Choose Next to proceed to the next step.

Step 5: Review

The Review section displays all of the settings you have configured. To edit information in any given section, choose the Edit button located in the top right corner of the step section. For example, if you want to change your pipeline name, choose the Edit button in the top right corner of the Step 1:

Pipeline details section.

1. When you have reviewed your settings, choose Create pipeline to create your pipeline.

2. You can see success or failure messages at the top of the page, as your resources are created for distribution settings, infrastructure configuration, your new recipe, and the pipeline. To see details for a resource, including the resource identifier, choose View details.

3. After you have viewed the details for a resource, you can view details about other resources by choosing the resource type from the navigation pane. For example, to see details for your new pipeline, choose Image pipelines from the navigation pane. If your build was successful, your new pipeline is displayed in the Image pipelines list.

Step 6: Clean up

Your Image Builder environment, just like your home, needs regular maintenance to help you find what you need, and complete your tasks without wading through clutter. Make sure to regularly clean up temporary resources that you created for testing. Otherwise, you might forget about those resources, and then later, not remember what they were used for. By then, it might not be clear if you can safely get rid of them.

TipTo prevent dependency errors when you delete resources, make sure to delete your resources in the following order:

1. Image pipeline 2. Image recipe

3. All remaining resources

To clean up the resources that you created for this tutorial, follow these steps:

(28)

Step 6: Clean up

Delete the pipeline

1. To see a list of the build pipelines created under your account, choose Image pipelines from the navigation pane.

2. Select the check box next to Pipeline name to select the pipeline that you want to delete.

3. At the top of the Image pipelines panel, on the Actions menu, choose Delete.

4. To confirm the deletion, enter Delete in the box, and choose Delete.

Delete the container recipe

1. To see a list of the container recipes created under your account, choose Container recipes from the navigation pane.

2. Select the check box next to Recipe name to select the recipe that you want to delete.

3. At the top of the Container recipes panel, on the Actions menu, choose Delete recipe.

4. To confirm the deletion, enter Delete in the box, and choose Delete.

Delete infrastructure configuration

1. To see a list of the infrastructure configurations created under your account, choose Infrastructure configuration from the navigation pane.

2. Select the check box next to Configuration name to select the infrastructure configuration that you want to delete.

3. At the top of the Infrastructure configurations panel, choose Delete.

4. To confirm the deletion, enter Delete in the box, and choose Delete.

Delete distribution settings

1. To see a list of the distribution settings created under your account, choose Distribution settings from the navigation pane.

2. Select the check box next to Configuration name to select the distribution settings that you created for this tutorial.

3. At the top of the Distribution settings panel, choose Delete.

4. To confirm the deletion, enter Delete in the box, and choose Delete.

Delete the image

Follow these steps to verify that you have deleted any image that was created from the tutorial pipeline.

This tutorial is not likely to create an image unless enough time has elapsed since you created your pipeline that it runs, according to the build schedule.

1. To see a list of the images created under your account, choose Images from the navigation pane.

2. Choose the image Version for the image that you want to remove. This opens the Image build versions page.

3. Select the check box next to the Version for any image that you want to delete. You can select more than one image version at a time.

4. At the top of the Image build versions panel, choose Delete version.

5. To confirm the deletion, enter Delete in the box, and choose Delete.

(29)

AWS Task Orchestrator and Executor component manager

EC2 Image Builder uses the AWS Task Orchestrator and Executor (AWSTOE) application to orchestrate complex workflows, modify system configurations, and test your systems without writing code. This application uses a declarative document schema. Because it is a standalone application, it does not require additional server setup. It can run on any cloud infrastructure and on premises.

To install AWSTOE, choose the download link for your architecture and platform.

Contents

• AWSTOE downloads (p. 23)

• Supported Regions (p. 24)

• Get started with AWSTOE (p. 25)

• Use component documents in AWSTOE (p. 33)

• Action modules supported by AWSTOE component manager (p. 53)

• Configure input for the AWSTOE run command (p. 109)

• EC2 Image Builder STIG components (p. 112)

• AWSTOE command reference (p. 120)

AWSTOE downloads

Architecture Platform Download link Example

386 AL2, RHEL 8 and 7,

Ubuntu 18 and 16, CentOS 7, SUSE 15

https://

awstoe-

<region>.s3.<region>.amazonaws.com/

latest/linux/386/

awstoe

https://awstoe- us-east-1.s3.us-

east-1.amazonaws.com/

latest/linux/386/

awstoe

AMD64 Windows Server

2019/2016/2012 R2/

version 1909

https://

awstoe-

<region>.s3.<region>.amazonaws.com/

latest/windows/

amd64/awstoe.exe

https://awstoe- us-east-1.s3.us-

east-1.amazonaws.com/

latest/windows/

amd64/awstoe.exe

AMD64 AL2, RHEL 8 and 7,

Ubuntu 18 and 16, CentOS 7, SUSE 15

https://

awstoe-

<region>.s3.<region>.amazonaws.com/

latest/linux/

amd64/awstoe

https://awstoe- us-east-1.s3.us-

east-1.amazonaws.com/

latest/linux/amd64/

awstoe

ARM64 AL2, RHEL 8 and 7,

Ubuntu 18 and 16, CentOS 7, SUSE 15

https://

awstoe-

<region>.s3.<region>.amazonaws.com/

https://awstoe- us-east-1.s3.us-

east-1.amazonaws.com/

(30)

Supported Regions

Architecture Platform Download link Example

latest/linux/

arm64/awstoe

latest/linux/arm64/

awstoe

Supported Regions

AWSTOE is supported as a standalone application in the following Regions.

Region name Region

US East (Ohio) us-east-2

US East (N. Virginia) us-east-1

AWS GovCloud (US-East) us-gov-east-1

AWS GovCloud (US-West) us-gov-west-1

US West (N. California) us-west-1

US West (Oregon) us-west-2

Africa (Cape Town) af-south-1

Asia Pacific (Hong Kong) ap-east-1

Asia Pacific (Mumbai) ap-south-1

Asia Pacific (Osaka) ap-northeast-3

Asia Pacific (Seoul) ap-northeast-2

Asia Pacific (Singapore) ap-southeast-1

Asia Pacific (Sydney) ap-southeast-2

Asia Pacific (Tokyo) ap-northeast-1

Canada (Central) ca-central-1

Europe (Frankfurt) eu-central-1

Europe (Ireland) eu-west-1

Europe (London) eu-west-2

Europe (Milan) eu-south-1

Europe (Paris) eu-west-3

Europe (Stockholm) eu-north-1

Middle East (Bahrain) me-south-1

South America (São Paulo) sa-east-1

China (Beijing) cn-north-1

China (Ningxia) cn-northwest-1

參考文獻

相關文件

 image processing, visualization and interaction modules can be combined to complex image processing networks using a graphical

Once you have created a complete dialog with widgets or arbitrary window hier- archy, the Interface Builder generates the source code needed to recreate it programmati- cally and

(a) In your group, discuss what impact the social issues in Learning Activity 1 (and any other socials issues you can think of) have on the world, Hong Kong and you.. Choose the

After teaching the use and importance of rhyme and rhythm in chants, an English teacher designs a choice board for students to create a new verse about transport based on the chant

Light rays start from pixels B(s, t) in the background image, interact with the foreground object and finally reach pixel C(x, y) in the recorded image plane. The goal of environment

(It is also acceptable to have either just an image region or just a text region.) The layout and ordering of the slides is specified in a language called SMIL.. SMIL is covered in

If necessary, you might like to guide students to read over the notes and discuss the roles and language required of a chairperson or secretary to prepare them for the activity9.

contributions to the nearby pixels and writes the final floating point image to a file on disk the final floating-point image to a file on disk. • Tone mapping operations can be