Secure Links

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

Термин объединяет узконаправленные приватные подключения, за которые долговременно отвечает Opfield. При этом разные приватные пути не обязаны использовать один и тот же компонент среды выполнения. Связи Ingress с целевыми службами и привязки управляемых баз данных имеют разных владельцев, разные учётные данные, записи жизненного цикла и диагностические сигналы.

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

Обе стороны должны быть поддерживаемыми ресурсами под управлением Opfield со стабильными идентичностями. Ответственные за них ноды должны быть подключены и сообщать совместимые возможности. Relay должен быть работоспособен и доступен обеим нодам. Пользователю нужны права на чтение целевого ресурса и изменение ресурса, который владеет связью.

Выберите службу или порт приложения, на котором процесс действительно принимает соединения. Публиковать порт хоста только ради приватной связи не требуется, а открытие такого порта не исправляет неисправный приватный путь. Opfield не создаёт правила межсетевого экрана хоста и не делает произвольные сети доступными.

Привязки баз данных

Привязка управляемой базы данных соединяет один подходящий Container, Deployment или службу Compose с одной управляемой базой данных. Opfield создаёт отдельного пользователя или роль движка для этой привязки и выдаёт только необходимые права на базу данных. Рабочая нагрузка получает данные подключения, относящиеся именно к этой привязке; учётные данные владельца базы не раскрываются.

Рабочая нагрузка обращается к базе данных через общий коннектор защищённых связей своей ноды Docker, в собственной небольшой приватной сети привязки. Отдельного Container-коннектора для каждой привязки и службы приёма соединений на хосте не существует, поэтому перезапускать, проверять или заменять их не нужно. Связь и идентичность движка хранятся отдельно, но изменяются согласованно: ротация учётных данных, изменение прав или удаление одной рабочей нагрузки не должны незаметно затронуть другую привязку.

После пересоздания рабочей нагрузки привязка сохраняется, потому что авторизация следует за стабильной идентичностью ресурса Opfield, а не за временным идентификатором Container. Opfield снова согласует связь и передаёт актуальные параметры подключения. При удалении привязки Opfield удаляет связь и выводит идентичность движка из эксплуатации в рамках одного зафиксированного жизненного цикла. Обычный процесс не должен оставлять осиротевшие роли или пользователей.

Если привязка базы данных не работает, сигнал следует проверять по владельцам в таком порядке: состояние управляемой базы и ноды хранилища, состояние целевой ноды Docker и рабочей нагрузки, желаемое состояние привязки, коннектор защищённых связей ноды, идентичность и права движка, затем конфигурация приложения. На соответствующих страницах ресурсов проверьте последнюю Task и журналы рабочей нагрузки и базы. Не удаляйте роль, сеть связи или коннектор вручную как универсальное исправление: это может превратить устранимое расхождение в осиротевшую идентичность или помешать следующему согласованию.

Связи контейнеров

Связь контейнеров даёт Container, Deployment или службе Compose приватный доступ к одному порту другой рабочей нагрузки — на той же ноде или на другой. Потребитель обращается к цели как alias:port; цели не нужен опубликованный порт, а связь открывает только этот порт и в одном направлении. Связи в пределах одной ноды остаются на ней; связи между нодами идут через Relay.

Общий коннектор и сети связей

Начиная с 2.11.1 на каждой ноде Docker работает один общий коннектор защищённых связей для всех её привязок баз данных, привязок хранилища и связей контейнеров. Отдельных контейнеров-коннекторов для каждой связи и служб приёма соединений на хосте нет. Каждая связь получает собственную небольшую приватную сеть, к которой подключается потребитель; на псевдоним связи в ней отвечает коннектор.

Новые сети связей получают адреса из отдельного диапазона — по умолчанию 10.213.x.x (/16), по /26 на связь, — поэтому связи не расходуют пулы адресов, которые Docker выдаёт вашим собственным сетям. Сети, созданные до 2.11.1, сохраняют свои адреса. Демон пропускает подсети, которые уже заняты сетями Docker или собственными маршрутами хоста. Если диапазон пересекается с сетью, доступной с ноды через маршрут по умолчанию, например с сетью площадки или VPN за маршрутизатором, задайте другой диапазон IPv4 размером /26 или больше в файле конфигурации Docker-демона /etc/docker-daemon/config.yaml:

docker:
  secure_links:
    subnet_pool: "<диапазон IPv4 в нотации CIDR>"

После изменения перезапустите Docker-демон. Новый диапазон используют только новые сети связей; существующие сохраняют свои адреса, пока их связь не будет создана заново.

При обновлении самого коннектора открытые соединения сохраняются до 30 минут, после чего закрываются один раз; клиенты переподключаются к новому коннектору.

Связи Ingress с целевыми службами

Routes и Additional Routes могут направлять трафик к поддерживаемым Docker-ресурсам через Secure Link. Opfield проверяет выбранный ресурс и порт приложения, создаёт связь и согласует принадлежащий Opfield коннектор через Relay. Коннектор для трафика от nginx к рабочей нагрузке — реальный компонент среды выполнения, но он недоступен через обычные пользовательские API жизненного цикла.

Связь, созданная управляемым Route, принадлежит этому Route. Её можно просматривать для диагностики, но нельзя удалять отдельно. Отключение Route сохраняет его конфигурацию и связь, а удаление Route выводит принадлежащую связь из эксплуатации после согласования. Перезапуск или пересоздание рабочей нагрузки не разрывает связь, потому что Route указывает на стабильный ресурс Opfield. При продвижении Deployment или смене ревизии Compose Opfield определяет активную среду выполнения за той же идентичностью верхнего уровня.

В 2.11 слушающие сокеты Secure Links на ноде Ingress продолжают принимать соединения под нагрузкой. Раньше, начиная с 2.10.0, nginx-демон проверял каждое новое соединение полной выгрузкой конфигурации nginx, поэтому нода Ingress захлёбывалась примерно после 100 новых соединений Secure Links в секунду и продолжала отклонять запросы ещё долго после спада нагрузки. Теперь проверка использует закэшированные сведения о процессах: одноядерная нода Ingress обрабатывает тысячи новых соединений в секунду, соединения сверх 1024 на этапе установки сразу отклоняются, чтобы nginx быстро перешёл к следующему варианту, а не ждал в очереди, соединения, от которых клиент уже отказался, закрываются без открытия туннеля, и слушающий сокет восстанавливается, как только нагрузка спадает. Временная ошибка приёма соединения, например нехватка файловых дескрипторов, больше не останавливает слушающий сокет до перезапуска демона.

Расширенные конфигурации nginx могут использовать дополнительные привязки с отдельным управлением и собственным жизненным циклом. Не путайте их с привязками, принадлежащими Route. Перед удалением пользовательской привязки найдите все конфигурации, которые на неё ссылаются.

Обычный процесс и проверка

Для целевой службы Ingress откройте редактор Route или Additional Route, выберите управляемый ресурс, службу или порт приложения и протокол. Сохраните изменения и дождитесь согласования Secure Link и успешной валидации конфигурации nginx. Затем проверьте идентичность цели, состояние коннектора, состояние Route и выполните реальный внешний запрос.

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

Проверка должна подтверждать работу нужного пути, а не только наличие записи. Для Ingress проверьте доступность Relay, соединения обеих нод, задержку настройки, активные потоки, пропускную способность, состояние завершения, отказы при допуске, журналы nginx и поведение приложения. Для привязок баз данных проверьте готовность базы, согласование связи, состояние идентичности движка, подключение приложения и актуальную конфигурацию рабочей нагрузки.

Что Secure Links не делают

• Это не универсальный VPN и не overlay-сеть.
• Они не обеспечивают произвольную переадресацию TCP или SSH.
• Они не открывают межсетевые экраны хостов автоматически.
• Они не отменяют аутентификацию на уровне приложения, если её требует протокол целевой системы.

Secure Links также не передают владение целевым ресурсом, не делают неподдерживаемые рабочие нагрузки переносимыми и не авторизуют пользователя, у которого нет доступа к обеим сторонам. Secure Link не служит основанием открывать управляющие интерфейсы демона, порты владельца базы данных или внутренние учётные данные коннектора.

Сбой и безопасное восстановление

Если Ingress Route сохраняется, но трафик не проходит, используйте сам запрос как сигнал и проверяйте уровни по порядку: Route включён и не находится в режиме обслуживания, последняя ревизия nginx применена, Relay доступен, ноды Ingress и Docker подключены, целевая среда выполнения и выбранный порт работоспособны, а допуск коннектора не завершился ошибкой. Затем сопоставьте Task и состояние Link Runtime с журналами приложения и поведением протокола. Не публикуйте внутренний порт рабочей нагрузки как недокументированный обход.

После сбоя ноды или Relay сначала восстановите соединение, затем дождитесь свежего отчёта о возможностях и согласования желаемого состояния. Не заменяйте идентичности до этих проверок. Сохраните историю операций и идентификаторы запросов. Если удаление прервалось, оставьте долговременную запись владельца или привязки, чтобы Opfield мог завершить очистку. Ручное удаление принадлежащих Opfield коннекторов, сетей или идентичностей движка допустимо только как согласованная исключительная процедура восстановления, а не как первое действие.