Как автоматически загружать новые сертификаты TLS для прокси-сервера Envoy?

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

Это то, что они называют xDS, который включает в себя различные сервисы, которые вы можете написать, которые генерируют разные части конфигурации. Эта одна служба (которую вы должны предоставить и запустить) может эффективно предоставлять все другие службы (например, службу обнаружения прослушивателя) через разные конечные точки, которые она предоставляет. Envoy позволяет настроить его для опроса REST-подобный API, потоковая передача gRPC или даже для просмотра файла в определенном месте (я подозреваю, что это лучший вариант для вас). На самом деле вам нужно только реализовать LDS для динамически управляемых сертификатов TLS. Остальная часть конфига может оставаться статичной.

Если вы выберете маршрут записи динамической службы, с которой Envoy консультируется для конфигурации, тогда не сложно настроить ее так, чтобы она просто считывала содержимое файлов на диске и предоставляла Envoy все, что там находит. Для этого вы можете просто указать встроенный строковый источник данных для Общий объект контекста TLS. Если у вас нет тысяч сертификатов и слушателей, тело ответа не приблизится к вашим пределам пропускной способности / памяти.

Признаюсь, я исчерпал время, которое мог позволить себе начать работу с Envoy, пытаясь интерпретировать их обширную машинно-ориентированную документацию, поэтому в конечном итоге я остановился на HTTP-сервисе с опросом для нашей конфигурации. Даже с опросом каждые несколько секунд это единственный реальный трафик, поэтому его довольно легко настроить и продолжить. Я расскажу об этом подходе, поскольку он мне наиболее знаком. Вы могли начать с чего-то вроде статического примера, но все, что вам нужно сделать, чтобы сделать его более динамичным, - это перейти на динамическая конфигурация чуть ниже. Просто замените REST на gRPC, так как это немного проще, и реализуйте конечные точки REST описаны ниже. Это требует небольшого количества проб и ошибок, но хороший способ начать - просто заставить службу возвращать JSON-версию конфигурации, которую вы уже используете. Одна ошибка, на которую следует обратить внимание, заключается в том, что вам нужно добавить ключи "type" и "version" в объект JSON верхнего уровня, который ссылается на прототип того типа вещи, которую вы возвращаете, то есть ответ на службу LDS может выглядеть следующим образом:

{
    "version_info": "0",
    "resources": [{
        "@type": "type.googleapis.com/envoy.api.v2.Listener",
        "name": "http_listener",
        "address": "{...}",
        "filter_chains": [{
            "filters": [
                "{...}"
            ]
        }]
    }]
}

Это оказалось не так просто, как я надеялся начать работать с Python. У них есть довольно хороший пример в Go сервера xDS, который использует gRPC, но это не помогло мне почти так сильно, как просмотр некоторых других попыток реализации xDS сервер, который я нашел на Github. Этот проект был для меня особенно полезным. Также мне еще предстоит столкнуться с чем-либо, что действительно потребовало бы горячего перезапуска, если вы уже динамически настраиваете envoy, кроме стабильных вещей, таких как идентификаторы кластера самого экземпляра Envoy.