EC2 Image Builder для Golden AMI в AWS

🔐 EC2 patching в ізольованому середовищі: що робити, коли немає доступу до інтернету?

У попередній статті ми розібрали, як за допомогою AWS Systems Manager (SSM) можна побудувати процес патчингу для EC2-ворклоадів. Це зручно, коли інстанси мають вихід в інтернет через NAT Gateway або через TGW.

Але що робити, коли ми працюємо в ізольованому AWS-середовищі?

🕸️ Початкові умови

vpc without access to internet

Уявімо AWS Account, в якому:

• ❌ немає NAT Gateway
• ❌ немає Internet Gateway
• ❌ немає публічних IP

Але при цьому є сервіси, що працюють на EC2:

• GitLab Runners
• EKS worker-nodes
• 3rd-party програми
• будь-який інший workload

Ми отримуємо сповіщення від AWS Security Hub про те, що наш EC2 workload містить вразливості.

Security Hub findings

Нам потрібно їх виправити.

---

🤔 Чи працює SSM у такому середовищі?

Так, можна використовувати SSM, якщо:

• EC2 має доступ до SSM endpoints через VPC endpoints
• та всі потрібні пакети доступні у вашому середовищі (наприклад, через локальний package registry a.k.a. Nexus)

Але для цього потрібно:

• підтримувати дзеркала репозиторіїв (apt/yum/whatever)
• автоматизувати оновлення цих репозиторіїв (звідки і як завантажувати ці оновлення)

Це додатковий адміністративний тягар.

---

💡 Підхід із Golden AMIs (baked images)

Суть підходу:

• патчинг виконується не на цільових EC2, а на окремому EC2 під час створення нового AMI в іншому акаунті, який ізольований від інших, але має доступ до інтернету. Це може бути «такий собі акаунт для різних адміністративних речей».
• далі ви використовуєте цей образ як базу для нових інстансів, де вам потрібно

Переваги:

• простіший аудит і контроль
• менше людського фактора завдяки автоматизації
• легше масштабувати
• можна розповсюджувати один образ на багато акаунтів

📘 AWS дозволяє шарити AMI між акаунтами: 👉 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html

---

🔄 Як виглядає pipeline?

1. Запускаємо EC2 зі свіжим базовим образом (наприклад, aws/debian)
2. Встановлюємо патчі, сертифікати, агентів, виконуємо конфігурацію
3. Зупиняємо EC2
4. Створюємо AMI snapshot
5. Вказуємо, кому поширити (через Account ID)
6. Якщо образ зашифрований за допомогою KMS, потрібно також поширити доступ до ключа

Sharing AMI

---

🧱 Але ж це купа ручної роботи…

Можна автоматизувати за допомогою будь-яких інструментів, які взаємодіятимуть з EC2 та AMI через AWS CLI/API.

Так, саме тому AWS створив спеціальний сервіс: EC2 Image Builder.

✅ EC2 Image Builder

Це managed-сервіс для автоматизації створення AMI-образів.

EC2 image builder components

Переваги:

• використовує ваші EC2 runner-и або керовані build-середовища
• build components - скрипти для кастомізації збірок
• test components - для тестування наших AMI
• можливість вмикати автоматичний cross-account/organization AMI sharing
• можна запускати вручну, за розкладом (через EventBridge) або через Lambda
• підтримка KMS

pipeline with ec2 image builder

---

Як налаштувати

1. Створити EC2 Image Builder pipeline (запускатиметься руками/api/cli або за розкладом)
2. Створити recipe (AMI або Docker), вказати base image, customizations (user-data), build & test components
3. За потреби змінити Image Building Workflow
4. Сконфігурувати Infra (ec2, instance-type або використати вже підготовлену ec2)
5. Налаштувати Distribution в інший акаунт або організацію

---

🛡️ Як правильно поширити зашифрований AMI?

Щоб розшарити зашифрований AMI, потрібно виконати два обов’язкові кроки.

🔑 Політика KMS-ключа (з боку source-акаунта)

У політиці KMS-ключа (CMK) потрібно явно дозволити використання ключа з іншого акаунта:

{
  "Sid": "Allow use of the key",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::<target_account_id>:root"
  },
  "Action": [
    "kms:Encrypt",
    "kms:Decrypt",
    "kms:ReEncrypt*",
    "kms:GenerateDataKey*",
    "kms:DescribeKey"
  ],
  "Resource": "*"
}

Створюємо IAM Role з predefined name і потрібною політикою

Щоб Image Builder міг виконати крос-акаунтну дистрибуцію, потрібно створити IAM-роль у target-акаунті з точною назвою EC2ImageBuilderDistributionCrossAccountRole.

Додати полісі Ec2ImageBuilderCrossAccountDistributionAccess, а також полісі для ключа:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowRoleToPerformKMSOperationsOnBehalfOfTheDestinationAccount",
      "Effect": "Allow",
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey",
        "kms:CreateGrant",
        "kms:ListGrants",
        "kms:RevokeGrant"
      ],
      "Resource": "arn:aws:kms:eu-central-1:<account_id>:key/<key_id>"
    }
  ]
}

---

🧩 Висновок

📦 Якщо ваш ворклоад працює в середовищі без доступу до інтернету, підхід із EC2 Image Builder + Golden AMI + cross-account sharing:

• масштабується
• стандартизує процес
• дає більше контролю та безпеки
• зменшує ризики помилок під час ручного патчингу

Посилання

• https://docs.aws.amazon.com/imagebuilder/latest/userguide/what-is-image-builder.html

---

Вперше опубліковано на LinkedIn 2 квітня 2025 р.: оригінал.