Настройка 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
}