Сеть, APISIX и TLS¶
Требования применяются к сетевой связности, DNS и публикации Kubernetes-
приложений через корпоративную ingress-границу. Уровни обязательности
определены в корневом README.md.
INF-NET-001. Публикация через APISIX¶
Уровень: MUST
Применяется к: HTTP(S)-сервису, публикуемому через ingress за пределы Kubernetes-кластера
Внешний HTTP(S)-маршрут должен публиковаться через корпоративный Apache APISIX. Route должен иметь уникальные host и path, явный backend service, timeout и ограничение размера запроса. Политика forwarded headers и доверенных proxy должна предотвращать принятие поддельного client IP или исходной схемы от недоверенного клиента.
Обоснование¶
Единая граница обеспечивает управляемую маршрутизацию и защиту.
Проверка¶
- запрос APISIX route и отрендеренного manifest;
- тест неизвестного host/path и превышения лимита.
Исключения¶
Не-HTTP протокол требует согласованной платформенной точки входа.
INF-NET-002. TLS и cert-manager¶
Уровень: MUST
Применяется к: ingress в non-production и production
Соединение клиента с APISIX должно использовать TLS. Сертификат должен
выпускаться и обновляться cert-manager через одобренный Issuer или
ClusterIssuer. Закрытый ключ не должен храниться в Git или CI artifact.
Параметры TLS и внутренняя граница шифрования должны соответствовать
применимым architecture:SEC-TLS-001–SEC-TLS-005.
Обоснование¶
Автоматический жизненный цикл сертификата предотвращает истечение и утечку ключа.
Проверка¶
- проверка Certificate, issuer и даты истечения;
- тест автоматического обновления и alert на ошибку выпуска.
Исключения¶
Изолированный local endpoint MAY использовать HTTP на loopback-интерфейсе.
INF-NET-003. Сетевой доступ по необходимости¶
Уровень: MUST
Применяется к: production namespace при поддержке NetworkPolicy платформой
Ingress и egress workload должны ограничиваться NetworkPolicy до объявленных источников, назначений, портов и DNS. Политика должна запрещать остальной трафик по умолчанию.
Обоснование¶
Ограничение связности уменьшает распространение ошибки или компрометации.
Проверка¶
- негативные и позитивные сетевые тесты из namespace;
- сопоставление правил с перечнем зависимостей.
Исключения¶
Отсутствие технической поддержки NetworkPolicy должно быть отражено в platform manifest и risk acceptance с владельцем и датой пересмотра.
INF-NET-004. Внутренняя адресация¶
Уровень: MUST
Применяется к: межсервисному трафику внутри Kubernetes
Компоненты должны обращаться друг к другу через стабильные Service DNS-имена, а не Pod IP или NodePort. Namespace внешней зависимости должен быть указан явно.
Обоснование¶
Pod IP нестабилен, а NodePort обходит управляемую сервисную границу.
Проверка¶
- статический поиск адресов в конфигурации;
- тест замены Pod.
Исключения¶
Headless Service MAY использоваться для протокола обнаружения участников.
INF-NET-005. Управляемый DNS¶
Уровень: MUST
Применяется к: endpoint non-production и production
DNS-запись должна иметь владельца, целевую среду и управляться из версионируемой конфигурации либо аудируемой системы. TTL должен учитывать проверенное время переключения. Production и non-production не должны использовать одно и то же имя для разных доверительных границ.
Обоснование¶
Забытая или неоднозначная DNS-запись направляет трафик в неверную среду.
Проверка¶
- сопоставление DNS с APISIX route и владельцем;
- тест переключения и истечения TTL.
Исключения¶
Локальное имя в /etc/hosts MAY использоваться только в local-профиле.
INF-NET-006. Защита публичного маршрута¶
Уровень: MUST
Применяется к: capability public-ingress
APISIX route должен иметь численные timeout и предел запроса, а также
ограничение частоты или доказанное эквивалентное ограничение на прикладной
границе. Scope, ключ, численные пределы, результат отклонения и поведение при
недоступности ограничения должны реализовывать
architecture:BE-HTTP-011. Метод аутентификации и авторизации должен следовать
архитектурному контракту приложения по применимым
architecture:SEC-AUTHN-001–SEC-AUTHN-012 и
architecture:SEC-AUTHZ-001–SEC-AUTHZ-012; инфраструктура не должна
добавлять несовместимую identity или переносить backend-решение авторизации в
route без ADR.
Обоснование¶
Неограниченный публичный трафик способен исчерпать ресурсы до обработки приложением.
Проверка¶
- нагрузочный тест превышения каждого предела;
- проверка кодов ответа,
Retry-Afterи forwarded identity; - тест недоступности общего состояния rate limiter.
Исключения¶
Rate limit MAY отсутствовать для заранее ограниченного upstream-трафика, если граница и её ёмкость проверены.