Перейти к основному содержанию
Это руководство развертывает полный стек AgentEye на выделенный кластер Kubernetes:
  • ClickHouse 24.8 — каноническое хранилище аналитики событий и оценок (StatefulSet с постоянным томом 100Gi). Обязателен: сервер отказывается запускаться без него.
  • PostgreSQL 16 — хранилище реляционных данных/метаданных для организаций, ключей API, пользователей, панелей, сохраненных запросов и аутентификации (StatefulSet с постоянным томом 50Gi)
  • Redis 7.2 — опциональный общий кэш и бэкэнд ограничения скорости; сервер и панель корректно деградируют при его недоступности
  • AgentEye Server — Rust API для приема событий, аналитики и управления ключами (2 реплики)
  • AgentEye Dashboard — Next.js веб-интерфейс (2 реплики)
  • AI помощник (сервис агента) — опциональный помощник только для чтения в панели на порту 9100; неактивен до настройки конечной точки LLM
  • Traefik (public) — контроллер входящего трафика для трафика сборщика, защищенный mTLS
  • Traefik (dashboard) — контроллер входящего трафика для панели, только для VPN/IP-разрешенного списка
  • cert-manager — TLS сертификаты и CA для mTLS
  • Резервная копия CronJob — ежедневный комбинированный дамп PostgreSQL + ClickHouse в 03:00 UTC
  • Монитор обновления сертификатов — предупреждения при приближении истечения сертификатов клиента
Примерное время: 60-90 минут для первого развертывания. Для модели управляемого развертывания, где Exosphere берет это на себя, см. enterprise-docs/managed-deployment.md.

Предварительные условия

Запустите каждую команду проверки перед началом. Каждая проверка должна пройти.
ТребованиеМинимумКоманда проверкиОжидаемый результат
Кластер Kubernetes1.27+kubectl versionServer Version >= v1.27
Kustomize (поставляется с kubectl)Kustomize v1.14+ (поставляется в kubectl 1.27+)kubectl kustomize --helpВыводит текст справки
Helmv3helm versionVersion:"v3.x.x"
cluster-admin RBACkubectl auth can-i create namespacesyes
Класс хранилища по умолчаниюkubectl get storageclassПо крайней мере одна строка отмечена (default)
Поддержка LoadBalancerЗависит от облака (EKS, GKE, AKS поддерживают по умолчанию)
GitHub PATecho $AGENTEYE_TOKENНе пусто (см. enterprise-docs/github-token.md)
opensslopenssl versionOpenSSL 1.x или 3.x
Бакет облачного хранилищаДля резервных копий PostgreSQL + ClickHouse (S3, GCS или Azure Blob)
Размер кластера: минимум 3 узла, по 4 vCPU / 8 ГБ ОЗУ каждый. Полные требования см. в enterprise-docs/managed-deployment.md.

Запустить все проверки сразу

Форма развертывания

Конечная точка приема работает на имени хоста, которым вы управляете (например, ingest.your-company.example). cert-manager запрашивает общедоступный сертификат TLS от Let’s Encrypt через HTTP-01, поэтому сборщики проверяют сертификат сервера в системном хранилище доверия без привязки CA для каждого клиента. Конечная точка панели работает так же: она работает на втором имени хоста, которым вы управляете (например, agenteye.your-company.example), указывающем на LoadBalancer Traefik панели, и cert-manager выпускает его сертификат Let’s Encrypt через этот LoadBalancer. Браузеры получают доверенный сертификат без предупреждения.
Выпуск сертификата и обновление проверяются через HTTP-01, поэтому оба LoadBalancer должны быть доступны из общественного интернета на порту 80. Если вам нужно ограничить IP-адреса для LoadBalancer панели, сначала согласуйте решатель DNS-01 с поддержкой — в противном случае обновления молча не срабатывают и сертификат истекает.

Получение манифестов

Проверьте это:
Ожидается: файл существует. Если нет, клонирование не удалось — проверьте ваш AGENTEYE_TOKEN. Структура каталогов:
Base содержит каждый ресурс, необходимый для полного развертывания, включая сертификаты Let’s Encrypt для двух общедоступных имен хостов, которые вы настраиваете на этапе 3.1. Overlay применяет патчи к базе для конкретной среды (например, пользовательские теги образов, лимиты ресурсов, подключение переменных). Каталог third-party содержит файлы значений Helm для внешней инфраструктуры.
Мониторинг здоровья (опционально): проверка готовности сервера уже отражает здоровье Postgres + ClickHouse, и third-party/robusta/ добавляет опциональное оповещение об отказе pod в Slack на уровне Kubernetes. См. enterprise-docs/health-monitoring.md.

Этап 1 — Инфраструктура третьих лиц (~30 мин)

1.1 Установка cert-manager

cert-manager управляет TLS сертификатами для HTTPS и приватным CA, используемым для сертификатов клиента mTLS.
Проверьте это:
Ожидается: 3 pod’а, все Runningcert-manager, cert-manager-cainjector, cert-manager-webhook.
Ожидается: по крайней мере certificates.cert-manager.io, clusterissuers.cert-manager.io, issuers.cert-manager.io. Если не удалось: Pod’ы в CrashLoopBackOff обычно означают, что CRD не были установлены. Повторно запустите с --set crds.install=true. Если pod’ы webhook не прошли проверку готовности, подождите 30 секунд и проверьте снова — они могут требовать немного времени на запуск.

1.2 Установка Traefik — контроллер входящего трафика для общественного приема

Этот экземпляр Traefik обрабатывает трафик сборщика на внешнем LoadBalancer. Он завершает TLS и обеспечивает mTLS (проверку сертификата клиента) на конечной точке приема.
Проверьте это:
Ожидается: 1 pod Running.
Ожидается: IngressClass существует (это не класс по умолчанию). Если не удалось: Проверьте kubectl describe pod -n traefik-public <pod-name> на предмет ошибок извлечения образа или ограничений ресурсов.

1.3 Установка Traefik — контроллер панели

Этот экземпляр Traefik обслуживает панель на выделенном LoadBalancer, ограниченном списком разрешенных IP-адресов.
Два механизма разрешения списков поставляются для этого экземпляра. Это руководство использует values-dashboard.yaml, который ограничивает доступ переносимым полем service.loadBalancerSourceRanges. Параллельный values-internal.yaml также предоставляется для окружений AWS, которые предпочитают аннотацию service.beta.kubernetes.io/aws-load-balancer-source-ranges. Выберите один и используйте его постоянно; шаги ниже предполагают values-dashboard.yaml.
Перед установкой отредактируйте third-party/traefik/values-dashboard.yaml для установки разрешенных IP-адресов источника. Поле loadBalancerSourceRanges управляет тем, какие IP-адреса могут получить доступ к панели. По умолчанию установлено 0.0.0.0/0 (все IP-адреса); ограничьте его вашим VPN, офисом или известными IP-адресами исходящего трафика.

Разрешить один IP-адрес

Разрешить несколько IP-адресов

Добавьте одну запись для каждого IP-адреса или блока CIDR. Суффикс /32 соответствует одному адресу IPv4; блок CIDR (например, /24) соответствует диапазону. Вы можете смешивать отдельные IP-адреса и диапазоны свободно:
Советы при ведении списка:
  • Держите одну запись на строку и добавляйте краткий комментарий # для идентификации владельца каждого IP-адреса или назначения; это то, что будущие операторы используют для определения необходимости записи.
  • Всегда используйте нотацию CIDR. Простой IP-адрес как 203.0.113.10 отклоняется облачным поставщиком; используйте 203.0.113.10/32.
  • Для диапазонов IPv6 используйте эквивалент /128 (один адрес) или больший CIDR, например 2001:db8::1/128. Не все облачные поставщики поддерживают диапазоны источников IPv6; проверьте документацию LoadBalancer вашего поставщика.
  • Список это OR: трафик разрешен, если источник соответствует любой записи.
После редактирования файла перейдите к helm install ниже. Если контроллер уже установлен, запустите helm upgrade с теми же флагами или примените патч Service во время выполнения (следующий раздел).

Обновить список разрешений во время выполнения

Вы можете изменить разрешенные IP-адреса без обновления Helm, применив патч Service напрямую. Патч заменяет весь список; всегда включайте каждый IP-адрес, который вы хотите сохранить, а не только новый. Для замены списка новым набором IP-адресов:
Для безопасного добавления IP-адреса без потери существующих записей сначала прочитайте текущий список, затем примените патч с объединенным набором:
Патчи во время выполнения не сохраняются обратно в values-dashboard.yaml. Для сохранения изменения при будущих обновлениях Helm также обновите файл значений и зафиксируйте его.
Затем установите:
Проверьте это:
Ожидается: 1 pod Running.
Ожидается: IngressClass существует.

1.4 Ожидание LoadBalancer’ов

Оба экземпляра Traefik нуждаются в внешних IP-адресах перед продолжением.
Проверьте это: Оба сервиса показывают EXTERNAL-IP (не <pending>). Если все еще ожидание, наблюдайте за назначением:
Нажмите Ctrl+C после появления IP-адреса. Назначение IP обычно занимает 2-5 минут. Если не удалось: <pending> через 10 минут обычно означает, что облачный поставщик не может выделить LoadBalancer. Проверьте: теги подсети (EKS требует kubernetes.io/role/elb), конфигурацию VPC, квоты услуги и что правильная аннотация внутреннего LB установлена для внутреннего экземпляра.

Этап 2 — Создание секретов (~10 мин)

Все секреты создаются вручную перед развертыванием приложения. Это гарантирует, что конфиденциальные значения никогда не появляются в файлах манифестов.

2.1 Создание пространства имен

Проверьте это:
Ожидается: статус Active.

2.2 Секрет для извлечения образа

Этот секрет аутентифицируется с ghcr.io для извлечения контейнерных образов AgentEye. См. enterprise-docs/github-token.md для генерации PAT.
Проверьте это:
Ожидается: kubernetes.io/dockerconfigjson. Проверьте это (глубоко) — убедитесь, что токен может действительно извлекать образы: Используйте тег образа server, указанный в kustomization.yaml вашего overlay (в настоящее время v0.0.1-beta.48 в обоих поставляемом overlay acme и базовом развертывании). Замените тег ниже на тот, который вы развертываете, чтобы эта проверка не дрейфовала между выпусками:
Ожидается: ok выводится в логах. Если не удалось: ErrImagePull или 401 Unauthorized означает, что PAT недействителен или не имеет области read:packages. Повторно проверьте enterprise-docs/github-token.md.

2.3 Учетные данные PostgreSQL

Важно: Мы используем -hex (не -base64) для создания пароля. Выходные данные Base64 могут содержать +, / и =, которые нарушают строку подключения DATABASE_URL. Подробности см. в enterprise-docs/troubleshooting.md.
Сохраните POSTGRES_PASSWORD в менеджер секретов немедленно. Вам это понадобится, если вы когда-либо восстанавливаете из резервной копии или подключаетесь к базе данных напрямую.
Проверьте это:
Ожидается: секрет существует.
Ожидается: 48 (24 hex байта = 48 символов).

2.4 Ключ администратора API

Ключ администратора - это начальный учетные данные. Сервер обновляет его при каждом запуске со всеми разрешениями. Используйте его для создания областных ключей сборщика на этапе 7. Полную модель разрешений см. в enterprise-docs/api-keys.md.
Сохраните ADMIN_KEY в менеджер секретов немедленно.
Проверьте это:
Ожидается: секрет существует.

2.5 Конфигурация аутентификации (вход на панель)

Панель использует электронную почту + OTP для входа пользователя. Без этого секрета сервер все еще запускается и путь ADMIN_KEY API продолжает работать, но ни один пользователь не может войти через пользовательский интерфейс. Все ключи упоминаются как optional: true в базовом манифесте, поэтому частичные секреты (или вообще отсутствие секрета) нормальны; сервер возвращается к задокументированным значениям по умолчанию. Упаковка всего в один секрет agenteye-auth держит поверхность аутентификации ротируемой в одном месте.
КлючНазначение
ADMIN_EMAILПользователь администратора начальной загрузки. Обновляется при каждом запуске со всеми разрешениями и защищен от удаления/редактирования разрешений через панель. Без него администратор не может быть созданный начальный и первый вход невозможен.
ALLOWED_EMAILSСписок разрешений через запятую. Поддерживает точные адреса (user@example.com) и подстановочные знаки для доменов (*@example.com). Без него ни один пользователь не может войти или быть создан.
SMTP_HOST, SMTP_PORT, SMTP_USERNAME, SMTP_PASSWORD, SMTP_FROMРетрансляция SMTP для отправки кодов OTP. Если SMTP_HOST не установлен, коды OTP записываются в stdout сервера вместо отправки по электронной почте (полезно для первоначальной дымовой проверки). Предоставьте все ключи SMTP вместе для реальной доставки электронной почты.
SMTP_TLSОдин из starttls (по умолчанию), tls или none.
DEFAULT_ORG_NAME, DEFAULT_ORG_SLUGОпционально. Дайте встроенной организации default дружественное отображаемое имя и слаг URL, так что она находится, например, в /acme вместо /default. Применяется только при первой загрузке; после переименования org с agenteye-orgctl org rename (см. §7.6) эти параметры игнорируются. Слаг должен быть 1-40 строчных буквоцифровых символов с одиночными внутренними дефисами. Оставьте оба неустановленными, чтобы сохранить общий default.
Сохраните учетные данные SMTP в менеджер секретов.
Проверьте это:
Ожидается: ключи, которые вы заполнили, появляются в выводе.

2.6 Ключ изоляции организаций для нескольких клиентов (опционально)

Пропустите это для развертывания с одним клиентом; сервер работает на встроенной разработке по умолчанию и отлично служит одной организации default. Перед созданием второй организации установите сильный, стабильный ORG_CH_SECRET: пароль ClickHouse каждой организации получается как HMAC(ORG_CH_SECRET, org_id), поэтому общедоступное значение разработки по умолчанию дало бы общедоступные производные учетные данные для каждой организации. Команда agenteye-orgctl org create (см. §7.6 Подготовка организаций) отказывается запускаться, пока сервер остается на встроенном значении разработки по умолчанию.
Сервер читает это через опциональный secretKeyRef, поэтому кластер с одним клиентом, который никогда его не создает, все еще нормально запускается. Держите значение стабильным и идентичным во всех репликах; его ротация делает недействительным пароль производного ClickHouse каждой организации до тех пор, пока переинициализация начальной загрузки не переприведет пользователей (перезагрузка с постоянным значением везде заживает его). См. deploy/base/server/secret.example.yaml.
Сохраните ORG_CH_SECRET в менеджер секретов и не ротируйте его случайно.

2.7 Проверка всех секретов

Ожидаемый выход (среди любых стандартных секретов):
Четыре основных секрета (agenteye-admin-key, agenteye-auth, agenteye-image-pull, agenteye-postgres) должны присутствовать перед продолжением. agenteye-org-ch-secret требуется только для развертываний с несколькими клиентами (см. §2.6).

Этап 3 — Развертывание приложения (~5 мин)

3.1 Конфигурирование общедоступных имен хостов

cert-manager нужны имена хостов приема и панели перед запросом их сертификатов Let’s Encrypt. Скопируйте шаблон и установите оба:
domain.env находится в gitignore; это остается локально для каждого развертывания. Сборка kustomize громко не срабатывает, если один из ключей отсутствует.
DNS должен сначала разрешиться. Вам не нужно указывать DNS на LB’ы сейчас (они не существуют до завершения этапа 1.2), но выпуск ACME на шаге 3.2 будет повторно пытаться до тех пор, пока каждое имя хоста разрешится на его LoadBalancer. Вы можете либо установить DNS сейчас (используя имена хостов LB, захваченные на этапе 1.4), либо продолжить и добавить записи на этапе 4.

3.2 Применение манифестов

Примените базу непосредственно для нового установления или overlay если вы его вырезали для этой среды (overlay’ы просто закрепляют теги образов, переменные среды и лимиты ресурсов; они наследуют сертификаты и маршрутизацию базы):
Overlay включает базу автоматически; примените один, не оба.

3.3 Ожидание pod’ов

Ожидание ограничено основными pod’ами уровня данных. Опциональные pod’ы agent (AI помощник) и redis появляются рядом с ними; помощник остается неактивным до предоставления его конечной точки LLM (см. enterprise-docs/assistant.md), а Redis является кэшем, лучшего качества, поэтому ни то, ни другое не нужно готовиться для платформы для обслуживания трафика. Проверьте это:
Ожидается (опциональные pod’ы agent и redis также появляются и достигают Running):
Если не удалось:
Статус Pod’аВероятная причинаКоманда отладки
ImagePullBackOffПлохой секрет для извлечения образа или PATkubectl describe pod <name> -n agenteye
CrashLoopBackOffПлохие переменные среды (например, DATABASE_URL)kubectl logs <name> -n agenteye
PendingНедостаточно CPU/памяти или нет узловkubectl describe pod <name> -n agenteye (проверьте Events)

3.4 Проверка хранилища

Ожидается оба со статусом Bound:
PVCЕмкостьОснова
postgres-data-postgres-050GiХранилище реляционных данных/метаданных PostgreSQL
clickhouse-data-clickhouse-0100GiХранилище аналитики событий + оценок ClickHouse
PVC redis-data-redis-0 (1Gi) также появляется для опционального кэша. Если не удалось: Pending означает, что ни один StorageClass не может выделить том. Проверьте kubectl get storageclass и убедитесь, что существует по умолчанию. Для производства наложите том ClickHouse на быстрый SSD StorageClass (например, gp3 на AWS, pd-ssd на GCP); пропускная способность сжатия страдает на медленных дисках.

3.5 Проверка сертификатов

Ожидается: 3 сертификата, все Ready: True:
ИмяИздательНазначение
mtls-caselfsignedПриватный CA для выпуска сертификатов клиента mTLS (валидность 10 лет)
ingest-tlsletsencrypt-prodОбщедоступный TLS сертификат для конечной точки приема (90 дней, автоматическое обновление)
dashboard-tlsletsencrypt-prodОбщедоступный TLS сертификат для панели (90 дней, автоматическое обновление)
Если ingest-tls или dashboard-tls не готов: kubectl describe certificate <name> -n agenteye и прочитайте Events. Общие причины:
  • DNS еще не указывает на LB. Let’s Encrypt разрешает имя хоста и попадает на порт 80 для валидации — INGEST_DOMAIN должен разрешиться на общественный LB, DASHBOARD_DOMAIN на LB панели. До распространения CNAME/Alias заказ остается pending. После правильного DNS cert-manager автоматически повторит попытку (не нужно удалять Certificate).
  • Имя хоста не заменено. Если dnsNames все еще читает INGEST_DOMAIN_PLACEHOLDER / DASHBOARD_DOMAIN_PLACEHOLDER, вы пропустили шаг 3.1 — создайте base/certificates/domain.env и повторно примените.
  • Traefik панели не может обслужить вызов (только dashboard-tls). Экземпляр Traefik панели должен быть установлен с поставляемым файлом значений (этап 1.2), который включает поставщика Ingress с областью видимости, который обслуживает решатель HTTP-01 cert-manager. Экземпляр установленный без этого оставляет вызов неуспешным и заказ pending навечно.
Если mtls-ca не готов: cert-manager сам неисправен. Повторно проверьте pod’ы cert-manager из шага 1.1.

3.6 Проверка CronJob’ов

Ожидается:
ИмяРасписаниеНазначение
agenteye-backup0 3 * * *Ежедневная резервная копия Postgres + ClickHouse в 03:00 UTC
cert-renewal-check0 3,15 * * *Предупреждения об истечении сертификата в 03:00 и 15:00 UTC

3.7 Проверка правильного запуска сервера

Проверьте это: Ищите строку запуска, указывающую на то, что сервер прослушивает порт 8080. Не должно быть ошибок подключения к базе данных (сервер требует досягаемости и PostgreSQL, и ClickHouse перед отчетом Ready). Если не удалось: Наиболее распространенная причина - POSTGRES_PASSWORD содержит символы, небезопасные для URL, которые нарушают DATABASE_URL. См. enterprise-docs/troubleshooting.md.

3.8 Проверка подключения панели к серверу

Проверьте это: Ищите Ready в выводе без ECONNREFUSED или аналогичных ошибок. Если не удалось: Проверьте, что Service server существует (kubectl get svc server -n agenteye) и что AGENTEYE_SERVER_URL установлена на http://server:8080 в развертывании панели.

Этап 4 — Сетевой доступ (~5 мин)

4.1 Получение адресов LoadBalancer’ов

На AWS EKS LoadBalancer’ы возвращают имя хоста вместо IP-адреса. Замените .ip на .hostname в командах выше.
Проверьте это:
Оба должны быть не пусты.

4.2 Точка DNS на LoadBalancer’ы

Создайте записи DNS так, чтобы имена хостов из base/certificates/domain.env разрешались на их LoadBalancer’ы — INGEST_DOMAIN на общественный LB Traefik, DASHBOARD_DOMAIN на LB панели Traefik:
  • AWS Route 53: запись A с Alias = Yes, цель = имя хоста LB. Не используйте простой A → IP; IP ELB ротируются.
  • Любой другой поставщик: CNAME от имени хоста к имени хоста LB.
Проверьте:
Должны возвращать те же адреса, что и $PUBLIC_IP и $INTERNAL_IP соответственно (или на EKS разрешаться на то же имя хоста *.elb.amazonaws.com). После разрешения DNS cert-manager завершит ожидающие заказы ACME из этапа 3.5 в течение минуты. Повторно запустите kubectl get certificates -n agenteye пока оба ingest-tls и dashboard-tls не покажут Ready: True.

4.3 Достижение конечной точки приема

Общественная конечная точка приема обеспечивает взаимный TLS, поэтому каждый запрос (включая /health) должен представить сертификат клиента. Вы выпускаете первый сертификат клиента на этапе 5; если у вас уже есть, проверьте достижимость сейчас:
Ожидается: {"status":"ok"}. Не требуется -k — сертификат сервера цепляется к общедоступному CA для INGEST_DOMAIN, поэтому он проверяется в системном хранилище доверия. Достигайте конечной точки приема по ее имени хоста INGEST_DOMAIN (которое совпадает с выпущенным сертификатом), не по сырому IP/имени хоста LoadBalancer’а. Конечная точка панели обслуживается на DASHBOARD_DOMAIN с общедоступно доверенным сертификатом и не находится за mTLS, поэтому не требуются -k и сертификат клиента:
Достигайте панели по ее имени хоста, не по сырому адресу LB — сертификат привязан к DASHBOARD_DOMAIN, поэтому сырой адрес показывает несоответствие имени сертификата. Если не удалось: Если curl зависает, проверьте, достижим ли LB с вашей машины (VPN, группы безопасности, правила брандмауэра). Ошибка certificate required в рукопожатии на имени хоста приема означает, что сертификат клиента не был представлен; сначала завершите этап 5. Ошибка проверки TLS на имени хоста приема означает, что сертификат сервера еще не закончил выпуск; вернитесь к этапу 3.5 и решите проблему там.

Этап 5 — Выпуск сертификатов клиента mTLS (~10 мин на кластер)

Сборщики аутентифицируются с двумя факторами: сертификатом клиента (транспортный слой, доказывает, что запрос приходит от авторизованного кластера) и ключом API (уровень приложения, доказывает, что запрос от сборщика с разрешением events:add). Утечка ключа бесполезна без сертификата; украденный сертификат бесполезен без действительного ключа.

5.1 Выпуск сертификата

Каждый кластер, запускающий сборщики, нуждается в своем собственном сертификате клиента. Из каталога манифестов:
Замените <cluster-name> на значимый идентификатор (например, us-east-1-prod, staging). Проверьте это: Скрипт выводит ==> Done! и перечисляет файлы вывода.
Ожидается: Ready: True. Файлы вывода в issued/<cluster-name>/:
ФайлНазначение
client.crtСертификат клиента (валидность 90 дней)
client.keyПриватный ключ клиента
ca.crtСертификат CA для проверки сервера
collector-mtls-secret.yamlГотовый к применению Kubernetes Secret для кластера сборщика

5.1b Альтернативная доставка: AWS Secrets Manager

Если потребитель сертификата - это Kubernetes Pod’а, которому нужны client.crt и client.key на диске — типичный случай, когда вы запускаете agenteye-collector как sidecar в pod’е приложения — отправьте пакет сертификата в AWS Secrets Manager. Pod приложения затем подключает его через Secrets Store CSI Driver с IRSA, и ротация сертификата полностью безрук.
При повторном запуске (обновление) скрипт вызывает PutSecretValue на том же секрете, поэтому ARN и имя остаются стабильными. CSI Driver подхватывает новую версию на следующей ротации опроса и переписывает файлы внутри pod’а. Предварительные условия:
  • aws CLI v2 аутентифицированный для вашего аккаунта AWS.
  • jq установлен.
  • Переменная окружения AWS_REGION установлена.
  • IAM разрешения на вашей идентификации вызывающей (область видимости Resource к arn:aws:secretsmanager:<region>:<account>:secret:agenteye/mtls-client/*):
    • secretsmanager:CreateSecret
    • secretsmanager:DescribeSecret
    • secretsmanager:PutSecretValue
    • secretsmanager:TagResource
Что делает скрипт в этом режиме:
ШагДействие
1Выпускает / переизвлекает сертификат через cert-manager (то же, что режим по умолчанию).
2Вызывает DescribeSecret на agenteye/mtls-client/<cluster-name> для решения о создании против обновления.
3При первом запуске: CreateSecret с трехключевым JSON payload (client.crt, client.key, ca.crt), помечено AgentEyeCluster=<cluster-name>. При последующих запусках: PutSecretValue для публикации новой версии; тег обновлен через TagResource.
4Удаляет issued/<cluster-name>/ только после успешной загрузки. При любом отказе каталог сохраняется, так что вы можете повторить попытку.
Если секрет запланирован на удаление, скрипт не срабатывает с четким сообщением об ошибке, сообщающим вам запустить aws secretsmanager restore-secret --secret-id agenteye/mtls-client/<cluster-name> перед повтором. Для полной кабельной разводки pod’а (SecretProviderClass, настройка IRSA, поведение ротации, устранение неполадок) см. enterprise-docs/single-pod-deployment.md.

5.2 Проверка работы сертификата

Протестируйте выпущенный сертификат против входящего mTLS:
Ожидается: {"status":"ok"} Если не удалось:
ОшибкаПричинаИсправление
certificate requiredСертификат не представляетсяПроверьте пути к файлам в команде curl
bad certificateНесоответствие CAПроверьте, что mtls-ca-issuer выпустил сертификат: kubectl describe certificate mtls-client-<name> -n agenteye
connection refusedНеправильное имя хоста или LB недостижимПроверьте /etc/hosts или DNS

5.3 Доставка в кластер сборщика

Отправьте collector-mtls-secret.yaml команде, эксплуатирующей кластер сборщика. Они применяют его:
Затем настройте сборщик на подключение секрета и использование путей сертификата:
Полная установка сборщика включая подключение тома Kubernetes см. в enterprise-docs/collector-installation.md. Проверьте это (в кластере сборщика):
Ожидается: секрет существует с 3 ключами данных (client.crt, client.key, ca.crt).

5.4 Жизненный цикл сертификата

СвойствоЗначение
Валидность сертификата клиента90 дней
Автоматическое обновлениеcert-manager обновляет за 15 дней до истечения
Валидность CA10 лет
Предупреждения об истеченииCronJob предупреждает за 30 дней до истечения (этап 6)
cert-manager автоматически обновляет сертификат на кластере AgentEye, но обновленный сертификат должен быть доставлен на кластер сборщика. Повторно запустите issue-client-cert.sh и повторно примените collector-mtls-secret.yaml перед истечением старого сертификата. Если вы используете --save-to aws-secrets-manager (см. § 5.1b), повторно запустите ту же команду. Скрипт вызывает PutSecretValue на том же секрете; pod’ы подключающие секрет через Secrets Store CSI Driver подхватывают новую версию на следующем опросе ротации (по умолчанию: каждый час), без перезагрузки pod’а.

5.5 Отзыв сертификата

Для немедленной блокировки доступа сборщика кластера:
Проверьте это: Команда curl из шага 5.2 теперь не срабатывает с ошибкой рукопожатия TLS.

Этап 6 — Мониторинг обновления сертификата (~2 мин)

Встроенный CronJob запускается каждые 12 часов (03:00 и 15:00 UTC) и проверяет все сертификаты клиента с меткой agenteye.io/cert-type=mtls-client. Он предупреждает, когда какой-либо сертификат находится в пределах 30 дней до истечения.

6.1 Включение уведомлений Slack (опционально)

Без этого секрета CronJob все еще запускается и заносит статус сертификата в stdout. Проверьте это:
Ожидается: секрет существует.

6.2 Проверка CronJob’а

Ожидается: список сертификатов с их статусом истечения. Если webhook Slack настроен, проверьте канал Slack на предмет сообщения предупреждения. Если не удалось: Проверьте RBAC — ServiceAccount CronJob’а нуждается в разрешениях get, list на ресурсах Certificate cert-manager. Проверьте с: kubectl describe role cert-renewal-check -n agenteye. Очистите тестовое задание:

Этап 7 — Проверка end-to-end

Этот этап подтверждает, что вся конвейер работает: проверка здоровья, создание ключей, прием событий и отображение панели.
Примечание: Примеры ниже достигают конечной точки приема по ее сырому адресу LoadBalancer’а (${PUBLIC_IP}) для удобства, поэтому они передают -k; сертификат сервера привязан к INGEST_DOMAIN, не к IP LB, поэтому проверка имени хоста пропускается. Конечная точка приема обеспечивает взаимный TLS на каждом пути, поэтому каждый вызов также должен представить сертификат клиента (--cert/--key). Для также проверки общедоступного сертификата целевой https://ingest.your-company.example/... вместо ${PUBLIC_IP} и удалите -k.

7.1 Проверка здоровья

Ожидается: {"status":"ok"} с HTTP 200.

7.2 Создание областных ключей сборщика

Ключ администратора предназначен для начальной загрузки и управления. Создайте выделенные ключи events:add для сборщиков:
Проверьте это: Ответ включает "id", "name": "prod-collector", "permissions": ["events:add"], "created_at". Проверьте это: Убедитесь, что ключ появляется в списке ключей:
Ожидается: prod-collector появляется в ответе. Полный справочник управления ключей см. в enterprise-docs/api-keys.md.

7.3 Прием тестового события

Ожидается: {"accepted":1,"skipped":0} с HTTP 200. Если не удалось:
HTTP статусПричина
401Недействительный или отсутствующий ключ API
403Ключу не хватает разрешения events:add
Ошибка рукопожатия TLSПроблема с сертификатом клиента — см. устранение неполадок этапа 5

7.4 Проверка появления события на панели

Откройте https://agenteye.your-company.example (ваш DASHBOARD_DOMAIN) в браузере. Сертификат общедоступно доверенный, поэтому нет предупреждения.
Если LB панели ограничен списком разрешенных IP-адресов и вы не можете подключиться, проверьте, что ваш IP разрешен:
Помните, что Let’s Encrypt обновляет сертификат панели через HTTP-01 на порту 80, и диапазоны источников применяются ко всему LoadBalancer’у — перед ограничением его корпоративными диапазонами согласуйте решатель DNS-01 с поддержкой или обнов