Налаштування Azure VM: Terraform, VMSS та безпека

Уявіть: ви розгорнули VM через Portal, але через годину вона недоступна — забули відкрити порт у NSG. Або обрали B-series для продакшену, і через 10 хвилин CPU credits закінчилися — застосунок впав. Такі помилки коштують часу та грошей. Нерідко зустрічаємо ситуації, коли диск не шифрується, NSG дозволяє весь трафік, а пароль від VM зберігається у plain-файлі. Все це — прямий шлях до витоку даних або простою. Правильне налаштування усуває ці ризики та скорочує витрати на $150–250 на місяць для типового проекту за рахунок оптимізації SKU та використання VMSS. Ми підготували практичний посібник із налаштування production-ready VM. Наш досвід — понад 5 років в Azure, 50+ розгорнутих проектів.

Як вибрати розмір VM?

Azure пропонує десятки серій. Для більшості завдань підходить наступна таблиця. Неправильний вибір — часта причина переплати: B-series у продакшені може коштувати на 30% дорожче через простої, а Premium SSD на тестовому оточенні — зайві витрати.

B-series для dev — економія 60-70% порівняно з D-series. Але для продакшену не підходить: CPU credits вичерпуються під навантаженням.

Terraform-конфігурація

Ось приклад production-конфігурації VM з Terraform. Ключові моменти: тільки SSH-ключі, шифрування дисків, SystemAssigned identity, cloud-init.

resource "azurerm_linux_virtual_machine" "app" {
  name = "vm-app-prod-01"
  resource_group_name = azurerm_resource_group.app.name
  location = azurerm_resource_group.app.location
  size = "Standard_D4s_v5"
  admin_username = "azureuser"
  disable_password_authentication = true
  # тільки SSH ключ
  admin_ssh_key {
    username = "azureuser"
    public_key = data.azurerm_key_vault_secret.ssh_key.value
  }
  network_interface_ids = [azurerm_network_interface.app.id]
  os_disk {
    caching = "ReadWrite"
    storage_account_type = "Premium_LRS"
    disk_size_gb = 64
    disk_encryption_set_id = azurerm_disk_encryption_set.main.id
  }
  source_image_reference {
    publisher = "Canonical"
    offer = "0001-com-ubuntu-server-jammy"
    sku = "22_04-lts-gen2"
    version = "latest"
  }
  identity {
    type = "SystemAssigned"
  }
  custom_data = base64encode(file("cloud-init/app.yaml"))
  boot_diagnostics {}
  # у managed storage, зручно при дебазі
  tags = {
    environment = "production"
    managed-by = "terraform"
  }
}

Параметр disable_password_authentication = true гарантує, що паролі не використовуються. disk_encryption_set_id включає шифрування дисків з customer-managed ключами через Key Vault.

Чому варто використовувати Managed Identity?

Managed Identity — спосіб надати VM доступ до Azure-сервісів (Key Vault, Storage, ACR) без зберігання credentials на диску. На відміну від паролів або сертифікатів, identity автоматично ротується платформою. Увімкнули SystemAssigned — і VM отримала service principal. Managed Identity повністю виключає зберігання секретів на диску, що в 10 разів безпечніше за паролі. Згідно з офіційною документацією Microsoft, це стандарт для enterprise-проектів.

# Призначити роль Key Vault Secrets User
PRINCIPAL_ID=$(az vm show \
  --name vm-app-prod-01 \
  --resource-group my-rg \
  --query identity.principalId \
  --output tsv)
az role assignment create \
  --assignee $PRINCIPAL_ID \
  --role "Key Vault Secrets User" \
  --scope /subscriptions/.../resourceGroups/my-rg/providers/Microsoft.KeyVault/vaults/my-kv

На VM секрет читається через IMDS без додаткових credentials:

# Отримати токен через IMDS
TOKEN=$(curl -s "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net" \
  -H "Metadata: true" | jq -r '.access_token')

# Отримати секрет
curl -s "https://my-kv.vault.azure.net/secrets/db-password?api-version=7.4" \
  -H "Authorization: Bearer $TOKEN" | jq -r '.value'

Такий підхід виключає зберігання секретів у коді або репозиторії.

Чек-лист security hardening

Cloud-init для початкового налаштування

Cloud-init — де-факто стандарт для первинної конфігурації VM. За його допомогою встановлюються пакети, запускаються служби, записуються конфіги. Ми використовуємо YAML-файл, який підключається через custom_data. Детальніше про технологію читайте на Wikipedia.

---
# cloud-init/app.yaml
#cloud-config
package_update: true
package_upgrade: true
packages:
  - nginx
  - curl
  - jq
runcmd:
  - systemctl enable nginx
  - systemctl start nginx
  - curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
  # Встановлення Azure Monitor Agent
  - wget -qO- https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/installer/scripts/install_omsagent.sh | sh
write_files:
  - path: /etc/nginx/sites-available/app
    content: |
      server {
        listen 80;
        location /health {
          return 200 'ok';
        }
        location / {
          proxy_pass http://127.0.0.1:8080;
        }
      }

resource "azurerm_linux_virtual_machine_scale_set" "app" {
  name = "vmss-app-prod"
  resource_group_name = azurerm_resource_group.app.name
  location = var.location
  sku = "Standard_D4s_v5"
  instances = 2
  upgrade_mode = "Rolling"

  rolling_upgrade_policy {
    max_batch_instance_percent = 20
    max_unhealthy_instance_percent = 20
    max_unhealthy_upgraded_instance_percent = 5
    pause_time_between_batches = "PT0S"
  }

  automatic_os_upgrade_policy {
    enable_automatic_os_upgrade = true
    disable_automatic_rollback = false
  }

  # ... решта конфігурації аналогічна VM
}