Сколько RAM нужно для step-ca

MAATRIX

Если вы разворачиваете внутренний PKI для mTLS между сервисами, для VPN-инфраструктуры или чтобы наконец избавиться от самоподписанных сертификатов с предупреждениями в браузере — step-ca от Smallstep решает это без танцев с OpenSSL вручную. Вопрос в том, сколько ресурсов закладывать под сервер: сам процесс лёгкий, но нагрузка зависит не от «размера CA», а от того, сколько клиентов дёргают его за сертификатами и как часто.

Из чего состоит step-ca и почему он в принципе лёгкий

step-ca — это один статический бинарник на Go, который поднимает HTTPS API (ACME, JWK, X5C, OIDC-провижионеры) и хранит состояние либо во встроенной BadgerDB, либо во внешней MySQL/PostgreSQL. Никакой JVM, никакого interpreter overhead — процесс стартует за доли секунды и в состоянии простоя держит память в районе десятков мегабайт.

Это принципиально отличает его от связки типа Vault + PKI secrets engine или от полноценного EJBCA на Java, где сама платформа уже съедает сотни мегабайт до первого запроса. step-ca ближе по духу к Caddy (тот же автор экосистемы, тот же подход «маленький бинарник, разумные дефолты»).

Расход памяти растёт по трём осям:

• База данных бэкенда. BadgerDB встраивается в процесс и держит LSM-дерево и индексы в памяти — при росте числа выданных сертификатов (журнал отзыва, история) её footprint увеличивается постепенно. Внешняя MySQL/Postgres выносит это за пределы процесса step-ca, но добавляет отдельный сервис со своим потреблением.
• Конкурентные TLS-хендшейки и криптография. Каждый выпуск сертификата — это подпись приватным ключом CA (обычно ECDSA P-256, реже RSA). Пиковая нагрузка кратковременная, но при одновременной ротации сотен клиентов (например, все ACME-клиенты в кластере продлевают сертификаты в одно окно) процесс кратковременно потребляет заметно больше CPU и памяти, чем в простое.
• Количество активных провижионеров и политик. JWK-провижионеры с большим списком разрешённых SAN, ACME-провижионеры с политиками allow/deny — это данные, которые step-ca держит в памяти конфигурации.

Сценарии использования и ориентировочные требования

Ниже — не измеренные бенчмарки, а практический ориентир по опыту эксплуатации; у вас цифры будут отличаться в зависимости от версии, бэкенда БД и профиля нагрузки.

Для домашней лаборатории или тестового стенда за глаза хватит 512 МБ — step-ca спокойно живёт рядом с парой других контейнеров на минимальном VPS. Для боевого внутреннего CA, который выпускает сертификаты для реальных production-сервисов, закладывайте 1–2 ГБ: это не про постоянное потребление, а про запас на пиковую нагрузку и на то, чтобы OOM killer не тронул процесс во время массовой ротации.

Docker-развёртывание с разумными лимитами

step-ca официально поставляется как Docker-образ. Базовый docker-compose.yml с ограничением ресурсов:

services:
  step-ca:
    image: smallstep/step-ca:latest
    container_name: step-ca
    restart: unless-stopped
    ports:
      - "9000:9000"
    volumes:
      - ./step:/home/step
    environment:
      - DOCKER_STEPCA_INIT_NAME=Internal CA
      - DOCKER_STEPCA_INIT_DNS_NAMES=ca.internal.example.com
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 512M
        reservations:
          memory: 256M

Инициализация CA (создание корневого и промежуточного сертификата, генерация JWK-провижионера) делается один раз через step ca init — либо интерактивно, либо через переменные DOCKER_STEPCA_INIT_*, как выше. После первого запуска приватные ключи корневого CA стоит вынести с диска сервера в HSM или хотя бы офлайн-хранилище — но это уже вопрос безопасности, а не памяти.

Если вы храните приватный ключ через внешний KMS (например, step-kms-plugin с AWS KMS или PKCS#11-модулем), сам step-ca становится ещё легче — подпись уходит на сторону KMS, а процесс step-ca только маршрутизирует запросы. Это стоит держать в голове, если сравниваете softkms (ключ на диске, всё в одном процессе) и cloudkms — разница в footprint небольшая, но она есть.

Автоматическая ротация: где реальная нагрузка

Главная причина ставить step-ca вместо ручной генерации сертификатов через easy-rsa — короткоживущие сертификаты с автопродлением. По умолчанию step-ca выдаёт сертификаты на 24 часа, и это осознанное решение: короткий срок жизни снижает ущерб от компрометации ключа, но требует, чтобы продление происходило само, без участия человека.

Схема ротации обычно выглядит так:

# на клиенте — systemd timer, который раз в час проверяет срок действия
step ca renew --daemon /etc/step/certs/server.crt /etc/step/certs/server.key

Либо через step-ca в связке с ACME-провижионером и стандартным ACME-клиентом:

step ca provisioner add acme --type ACME

# certbot или acme.sh указывают на step-ca как на ACME-сервер
certbot certonly --server https://ca.internal.example.com/acme/acme/directory ...

Для памяти это значит следующее: если у вас 5 хостов и продление раз в день — нагрузка незаметна. Если у вас 500 хостов с суточными сертификатами и все клиенты продлевают их по одному и тому же cron-расписанию (например, все в полночь по UTC) — вы получаете всплеск одновременных запросов раз в сутки. Решение простое и стандартное для ACME-инфраструктуры — джиттер (случайная задержка перед продлением), который step ca renew --daemon и большинство ACME-клиентов уже умеют делать из коробки. Без джиттера пиковая память может кратковременно вырасти в 1.5–2 раза относительно простоя — на процесс подписи сотен сертификатов за секунды.

Если планируете PKI внутри Kubernetes, логичнее не гонять step-ca напрямую с каждым подом, а поставить перед ним cert-manager со step-issuer — он сам сериализует запросы и снимает часть пиковой нагрузки с CA.

Внешняя БД против встроенной BadgerDB

Для одиночного CA с умеренным объёмом сертификатов BadgerDB — разумный дефолт: меньше движущихся частей, меньше памяти на отдельный процесс СУБД. Но у неё есть ограничение — BadgerDB не поддерживает горизонтальное масштабирование step-ca на несколько инстансов (нет распределённых блокировок между процессами), и при интенсивной записи (много выдач/отзывов) она склонна раздувать файлы на диске, что периодически требует компакции.

Если вам нужна отказоустойчивость (два-три инстанса step-ca за балансировщиком) или просто спокойствие за консистентность данных при большом потоке запросов — переходите на MySQL или PostgreSQL:

{
  "db": {
    "type": "mysql",
    "dataSource": "step-ca:password@tcp(db.internal:3306)/step_ca",
    "database": "step_ca"
  }
}

В этом случае память самого step-ca становится ещё предсказуемее (она не растёт с историей БД), но вы добавляете отдельный сервис — который на VPS с 2 ГБ RAM для MySQL стоит планировать отдельно, не в остаточной памяти после step-ca. Разумный минимум для связки step-ca + MySQL на одном сервере — 2 ГБ RAM суммарно, с чётким разделением через docker-compose лимиты, чтобы один сервис не вытеснял другой при пиках.

Мониторинг потребления и типичные грабли

step-ca отдаёт метрики в формате Prometheus, если включить это в конфиге:

{
  "metrics": true
}

Дальше — стандартный Prometheus + Grafana, про которые у нас есть отдельный разбор установки. Из полезных сигналов: количество активных горутин, latency выдачи сертификатов, размер очереди на подпись. Резкий рост latency при стабильной нагрузке обычно означает, что CPU (а не память) стал узким местом — RSA-подпись заметно тяжелее ECDSA, и если провижионер настроен на RSA-2048 вместо ECDSA P-256, при том же потоке запросов CPU нагружается сильнее.

Для быстрой проверки без Prometheus достаточно docker stats step-ca — если RSS процесса стабильно растёт без плато при том же профиле нагрузки, это повод проверить размер BadgerDB на диске (du -sh step/db) и запустить компакцию, либо задуматься о переезде на внешнюю БД, как описано выше.

Отдельно стоит следить за диском: журнал выданных и отозванных сертификатов растёт линейно со временем, и на дешёвом VPS с 10–20 ГБ диска это может стать проблемой раньше, чем нехватка памяти. Если у сервера есть swap, он спасёт от разового всплеска при массовой ротации, но полагаться на него как на постоянную стратегию не стоит — задержка при уходе в своп для CA, который должен отвечать быстро на ACME-запросы, ощутима.

Частые вопросы