Как вам поможет Service Discovery и управление секретами инфраструктуры в 1С и не только

Давайте разберемся, зачем в 1С может потребоваться Service Discovery, для чего вообще нужна эта кухня?

Service Discovery обычно упоминается в контексте микросервисной архитектуры, но в 1С применялась очень редко. Я не помню ни одного более-менее крутого кейса об использовании Service Discovery в рамках 1С. Были интересные идеи, но их мало. Я решил восполнить этот пробел, тем более, что сейчас я именно этим и занимаюсь в рамках развертывания инфраструктуры.

Что такое Service Discovery

Для чего вообще Service Discovery используется в большом ИТ? Представьте себе известный сайт, например, AliExpress. Как все знают, он работает на своих серверах, у них большие дата-центры, они используют Kubernetes, микросервисную архитектуру и так далее. Каждая функция, каждая операция на этом большом монстре – площадке AliExpress – разбита на маленькие кусочки.

Когда наступает Черная пятница, большое количество людей бежит на AliExpress покупать себе что-то хорошее. Из-за увеличения количества сеансов некоторые микрофункции сервиса начинают сильно нагружаться, но благодаря Kubernetes и возможностям горизонтального масштабирования самих инстансов этих функций, способных поглощать нагрузку, становится много. Но проблема не в том, что их стало много, проблема в том, что серверу нужно знать о том, что они появились – должно быть какое-то централизованное место, которое скажет: «Ребята, у меня появился новый сервис, он вон там, к нему нужно обратиться и взять какие-то данные».

Это и есть Service Discovery – такое централизованное место, которое, как гуру, подсказывает, где расположен нужный сервис, как к нему обратиться. Неважно, какой это сервис: главное, что он есть, и что он доступен в текущий момент.

Зачем в 1С может понадобиться Service Discovery и хранение секретов

Сегодня мы по большей части будем говорить про программы от HashiCorp – Consul и Vault. Consul – это Service Discovery, а Vault – сервис для хранения секретов.

Каким образом это можно привести к 1С? Я расскажу несколько кейсов.

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

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

В подавляющем большинстве настройки взаимодействия хранятся внутри информационной системы, и это приводит к следующему:

• Переезд одного сервиса в другое место требует изменения этих настроек в других местах.

• Вторичным моментом этого станет необходимость дублирования настроек и секретов. В частности, нам приходится хранить в 1С пароли пользователей, точки подключения и пути подключения к внешним информационным базам в справочниках, что явно очень небезопасно. Представьте, что мы берем какую-то информационную базу, делаем ее бэкап и отдаем этот бэкап подрядчику: внешнему или внутреннему, неважно. Получается, что через эту базу мы даем подрядчику возможность получить неправомерный доступ к нашим продуктивным информационным системам. Дело в том, что когда мы базу разворачиваем, у нас в БСП есть механизм, который при разворачивании копии базы показывает, что база перемещена, и предлагает отключить регламентное задание. Механизм крутой, но он не гарантирует, что информационная база при включении регламентного задания – либо других ручных действий пользователя – не получит доступ к продуктивным интегрированным системам через тот же самый план обмена, потому что там есть каталог, который мы выгружаем, и база, с которой мы соединяемся. Многие встречали ситуации, когда копия базы ухитрялась делать обмен с продуктивной базой, потому что в том или ином виде подрядчику передаются пароли и секреты подключения к продуктивным информационным базам. Причем, очень часто пароли захардкожены прямо в код. И когда мы отдали эту конфигурацию, наш подрядчик видит, что есть ресурс, к которому можно подключиться, и логин-пароль для этого. Теперь компрометация этого логина-пароля, чтобы они уплыли дальше, уже дело времени. Он уплывет – 100%.

• Третий момент – сложность построения тестовых площадок. Допустим, мы отдали клиентам тестовую базу и теперь нам нужно развернуть для нее тестовую инфраструктуру. Нам нужно узнать строки подключения, логины и пароли к интегрированным системам. Естественно, все эти секреты будут отправлены в Skype или в Telegram, т.е. пароли «поплывут». А нам потом нужно будет вручную зайти и поправить эти данные авторизации. Это время и явное снижение безопасности.

Это основные моменты, почему нам нужен Service Discovery и сервис хранения секретов для 1С. Они хранят данные о сервисах, а база 1С – это такой же сервис, ничем не отличающийся от приложений и микросервисов, только большой. Ведь сервис – некое приложение, осуществляющее действия для пользователя. 1С-ка осуществляет действия для пользователя, значит, по факту, это тоже сервис.

Возможности Service Discovery – Consul

Service discovery – некий справочник о метаинформации, «желтые страницы» сервисов. Я вспоминаю свои студенческие годы, и в институте на кафедре ИТ-нам давали книжечки, которые назывались «Желтые страницы интернета». Там были описаны веб-адреса сайтов, которые в то время вообще существовали в сети.

По факту, Service Discovery – это точно такой же ресурс «Желтых страниц». Он тоже говорит нам о том, какие сервисы есть в сети.

Как я и говорил, все это относится к реализации слабых связанностей между компонентами и системами. Мы малыми шагами идем к микросервисному паттерну разработки Service Oriented Architecture (SOA), описывающему архитектуру приложений в виде атомарных компонентов со слабой связанностью, которые общаются между собой по стандартным протоколам (например, через REST).

Логическим продолжением или подмножеством SOA является микросервисная архитектура. Она базируется на увеличении количества сервисов вместо увеличения функциональности конкретного сервиса и глубокой интеграции с continuous-процессами.

Что я этим хочу сказать? При жесткой настройке связей сервисов (из примера, который я рассказывал ранее) мы получаем единый моноблок. Чтобы этого избежать, нам нужно его декомпозировать на отдельные, более мелкие элементы и дать им общаться между собой более свободно.

Понятно, что прикладные решения 1С микросервисами назвать нельзя. Но если посмотреть на инфраструктуру в целом глобально, можно сказать, что конфигурация 1С – сервис, который осуществляет определенные действия для пользователя.

Нам необходимо использовать единую информационную систему, которая должна:

• знать о том, что этот абстрактный сервис запустился, причем она должна узнать это сама;

• иметь функциональность проверки работоспособности сервиса: существует он сейчас или не существует;

• поддерживать хранение дополнительной метаинформации о сервисе в формате key-value;

• иметь возможность отдавать несекретные данные всем заинтересованным информационным системам в любой момент времени (естественно, при наличии у сервиса прав на это).

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

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

• Service Discovery позволяет обнаруживать сервисы и заносить их в базу, называемую каталогом. Все это делается автоматически либо самим приложением, либо скриптами, которые его формируют. Вам не нужно запускать какой-то сервис, а потом самостоятельно его регистрировать. При развертывании приложение регистрируется в каталоге автоматически. Так же и 1С.

• Любое приложение, использующее Consul, обращается к нему через localhost. Самому приложению не нужно знать, где находится Service Discovery, оно стучится туда локально. Consul берет на себя взаимодействие внутри кластеров для обмена так называемых сплетен.

• Для интеграции с Consul и поиска данных предлагается использовать API, реализованное через интерфейсы HTTP или DNS. Последний вариант дает возможность работать с Consul приложениям, которые вообще ничего о нем не знают и поддерживают всего два вида DNS-запросов: поиск узлов (node lookup) и поиск сервисов (service lookup)..

Хранение секретов – Vault

Следующий нужный нам элемент – Vault, сервис хранения секретов.

Допустим, у нас есть какие-то сервисы, зарегистрированные в Consul. Но как узнать, какие логины и пароли нужны, чтобы к ним достучаться? Для этих целей и нужен Vault.

«Под капотом» для хранения секретов Vault использует тот же самый Consul – данные в зашифрованном виде хранятся в реестре метаинформации key-value в Consul.

Vault – инструмент, который позволяет хранить секреты в формате JSON (это его основное разрешение).

Отличительные черты Vault:

• Сервис хранения секретов должен обладать гибкой системой распределения доступа, что Vault и дает. Он дает не только регламентированный доступ, но и четко идентифицирует: кому этот секрет доступен, что он может с ним сделать, и в течение какого времени он сможет с ним поработать. У него есть политика доступа Access Control List (ACL), которая позволяет четко управлять не только самим секретом, но и группой секретов, их видимостью, доступностью, просмотром и чтением.

• Правила могут храниться в Git и подключаться при развертывании и обновлении самого Vault. Помимо этого есть аудит доступа: каждый акт доступа записывается самим Vault и хранится – мы знаем, кто и в какой момент запросил этот пароль. Теперь все интегрированные системы идут в Consul, спрашивают, где находится сервис. Затем запрос идет в Vault, где фиксируется, что такой-то компонент запросил секрет к такому-то сервису.

• Так же, как и Consul, Vault работает локально – все запросы идут в локальный Vault, а дальнейший обмен между Vault, Consul и другим источником хранения секрета уже не касается работы самого приложения. Плюс этой схемы – снижение периметра атаки. Чем меньше размазанность хранения паролей по системе – тем лучше.

• У Vault очень хорошее, гибкое REST API. С помощью токена вы можете запрашивать пароль для конкретного сервиса, причем пароль может быть временным. И даже необязательно это будет логин и пароль: секретные данные в Vault хранятся в виде json.

• Следующий момент – локальный запрос пароля, когда ваш компьютер при запуске программы авторизуется в Vault и получает токен внутри переменных среды. Например, вам нужно запускать 1С-ку, которая запускается не с обычного ярлыка, а со скрипта, который перед запуском подключится в Vault и скажет: я такой-то компьютер, дай мне логин и пароль для текущего пользователя, который у тебя хранится. Это некий аналог доменной авторизации, который тоже в некоторых случаях может использоваться. Я не говорю, что этот вариант лучше, но хранение секретов в едином месте, которое дает регламентированный доступ – это круто.

Итак, Vault – хранилище секретов, которые хранятся в виде key-value либо в виде json-файлов (как будет удобнее).

Причем можно создавать собственное хранилище секретов, которое в принципе недоступно даже root-пользователям. Например, у вас есть личные секреты, доступ к которым вы не хотите давать даже администраторам. Вы можете использовать в Vault свой собственный раздел для хранения секретов, к которому даже root-пользователи доступ не получат.

Реализация в инфраструктуре

Теперь расскажу, каким образом это работает все это у нас в инфраструктуре.

Consul и Vault – единая точка интеграции сервисов.

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

Интернет-магазин и личный кабинет, которые у нас работают, тоже интегрируются вместе с Consul, но через оркестраторы микросервисов.Интернет-магазин и личный кабинет у нас разворачиваются в виде docker-приложений, и при развертывании регистрируются в Consul автоматически и прописывают: где и какие порты используют.

Мы используем Consul как DNS-сервер и осуществляем доступ за счет вот этого.

Также у нас при регистрации в Consul автоматически создается раздел хранения секретов в Vault. Когда мы стучимся в Consul, мы говорим: а где хранятся секреты в Vault? И он четко указывает этот путь. Это напоминает путь хранения на жестком диске в ОС Linux, где нет дисков – допустим, kv/clients/mycompany и т.д..

Помимо этого есть еще различные сервисы. Например:

• Traefik – сервис, который управляет инфраструктурой: своего рода обратный реверс-прокси. Он напоминает Nginx, только более крутой. Он может использовать в качестве провайдера не только Docker, но и сам Consul. Именно благодаря ему сервисы при развертывании в Docker автоматически регистрируются в Consul и становятся публичными для общественности, получают DNS-имена.

• Jenkins – он интегрируется с Consul и получает параметры подключения к информационным базам для тестовых средств.

• GitLab – тоже использует Consul для получения параметров подключения.

• И какие-то другие приложения, которые выступают, как внешние источники данных.

Все это завязывается на Consul. А Consul – отказоустойчивая система.

Интеграция 1С и Consul

Как интегрировать 1С и Consul? Нами было разработано расширение, которое не зависит от информационной базы и встраивается в любую конфигурацию. Задача расширения – при запуске проверить уникальность информационной базы и наличие ее регистрации в Consul.

В качестве ключей для регистрации мы используем:

• имя сервера 1С и имя базы – если это серверная база;

• или путь к информационной базе и имя текущего хоста – если это файловая база.

Когда база запускается – она идет в Consul и уточняет, зарегистрирована ли она в нем. Consul отвечает: «Я не знаю, кто ты». Тогда база начинает регистрироваться, но при этом уточняет: «А нода, машина, на которой я запустилась, зарегистрирована?» – «Нет» – отвечает Consul – «Тогда давай зарегистрируем ноду». После регистрации ноды база регистрируется сама и заносит для этого сервиса определенные значения key-value.

Для применения полученных значений в базе, а также для формирования новых пар key-value мы сейчас реализуем в расширении поддержку пользовательских скриптов. База же не только должна зарегистрироваться в Consul и Vault, но и узнать оттуда, какие сервисы сейчас существуют в окружении базы, и какие она может использовать.

На слайде видно, что база может быть основная, а может быть и не основная – тестовая. Основная – это продуктивная ИБ. Поэтому текущее развертывание должно зайти туда и спросить, какие значения она может использовать: ключи, параметры авторизации и пути к секретам в Vault, где они хранятся для этих сервисов.

Мы реализуем не только поддержку Consul, но и возможность быстрой смены обработчиков взаимодействия Service Discovery. Это позволяет нам манипулировать: кто хочет работать с Consul, а кто-то – с другими инструментами. Например, кто-нибудь напишет Service Discovery на OneScript – наверное, такое себе приключение, но, может, кто-то и захочет.

Consul выглядит вот так. На экране вы видите ноды, которые сейчас доступны.

Нода – это некий компьютер, на котором крутятся сервисы. В качестве операционной системы у этого компьютера может быть Windows, Linux – не важно. В качестве сервисов – необязательно 1С, это могут быть docker-приложения, веб-сервисы, MS SQL, PostgreSQL. Что хотите называть сервисом, то и будет. Нода должна осуществлять доступ к этому сервису, его развертывание и управление этим сервисом.

Как нода может появиться? Я говорил, что Consul может работать локально, а может – через REST API.

• Когда Consul работает локально, мы его объединяем в кластер. Настройка кластера осуществляется при запуске Consul через конфигурационный файл либо через параметры запуска. И когда мы запускаем Consul локально, нода появляется. Допустим, здесь на слайде sport1, sport2, sport5 – это ноды, которые подключены в Consul локально.

• Но есть ситуации, когда мы запускаем инстанс на тестовой базе разработчика удаленно и не хотим разворачивать Consul у него локально. Тогда мы можем создавать ноды через запросы, используя REST API. Ноды на слайде Office и AttlassianTest.Sport как раз запущены через REST API.

А вот так выглядит пример самого сервиса. ФинБазаОСКК – это наша конфигурация, которая запустилась и зарегистрировалась в Consul.

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

На ноде развернут сервис, а сервисы одинаковые: мы взяли бэкап ФинБазыОСКК и раскатили его в другом месте – Васе или Пете. Сервисы те же самые, а инстансы разные.

Мы этот бэкап подключаем, как отдельный инстанс, их может быть очень много. Они могут жить и могут удаляться.

Единственную сложность вызывает удаление этих сервисов. Но это тема для отдельного разговора.

Зарегистрированный сервис заносит туда определенный набор значений, key-value.

Для файловой базы набор значений будет вот таким:

• ONEC_DABE_NAME – имя базы;

• ONEC_SERVER_NAME – эта база зарегистрирована на сервере Sport1;

• VAULT_SECRITS_CI – путь хранения секретов, как я уже говорил, он указывается в формате unix-пути, разделенный слэшем;

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

Для 1С набор этих параметров будет одним, для Jenkins – другим.

Все эти значения key-value, они могут дополняться – мы в любой момент можем их изменить или дополнить чем-то на одном сервисе или сразу на группе сервисов.

Итак, сервис создался. У нас есть к нему доступ, все замечательно. А еще у нас есть ресурс, который может к нему подключиться. Где этому ресурсу взять параметр авторизации?

Для этого у нас есть параметр – путь хранения секретов, вы видите его на слайде. При этом сами секреты у нас хранятся в Vault.

Vault – это тоже веб-приложение, у него есть интерфейс. Здесь в данном случае мы видим четыре раздела хранения

• cubbyhole – ваш персональный раздел, где хранятся секреты, недоступные никому, кроме вас.

• DevOps – набор секретов, размещенных для использования сборочных линий.

• infrastructure – пароли к различным инфраструктурным сервисам.

• kv (key-value) – секреты доступа и параметры авторизации для приложений-клиентов (например, для информационных баз).

Сейчас я в качестве примера расскажу один из кейсов реализации. Это реализация сборочной линии для 1С-приложений и интеграция его с Consul.

У нас есть несколько информационных баз, в которых осуществляется две операции:

• gitsync – операция синхронизации хранилища и Git через GitSync;

• testAndBuild – тестирование конфигурации, например, синтаксическая проверка, проверка SonarQube, TDD, BDD-тестирование, сборка поставки и так далее.

Каждая из этих операций требует себе набор определенных параметров – путь к базе, секреты пользователей, путь хранения каких-то конфигурационных файлов, секреты доступа к Git и так далее.

Раньше мы их хранили в Jenkins и нам приходилось их дублировать в нескольких местах – в Jenkins хранить, пользователю отдавать и т.д.

В итоге мы пришли к тому, что хранить их нужно в одном месте – в Vault. На слайде показано два раздела, в которых у нас хранятся секреты.

А здесь показано, как выглядит хранение секретов для каждого раздела.

Например, здесь для testAndBuild хранятся не только секреты, но и параметры, которые по факту могли быть и не секретными.

Но на тот момент, когда мы начали развивать инфраструктуру, было проще начать с того, что все данные хранить только в Vault. А позже мы начали разделять: то, что секретное – хранится в Vault, а то, что является публичным – в Consul.

Сделаю ремарку: здесь хранятся не только секреты, но и пути к файлам.

Такие же настройки у нас заданы для GitSync – они выглядят вот таким образом.

Здесь видно переключатель JSON, что значения секретов можно задавать не в виде пар key-value, а сразу в виде JSON.

В Jenkins разработана сборочная линия, которая интегрируется с Consul/Vault и спрашивает: где параметры авторизации сервисов и баз, которые у нас зарегистрированы, для тех двух задач, которые у нас запускаются – GitSync и testAndBuild.

В итоге получается, что база тестируется, мы видим, что прогоны тестов прошли, но в сборочной линии не хранятся параметры, секреты сборки… Все настройки хранятся в Git.

Теперь при запуске новой сборочной линии нам нужно задать параметры авторизации для нее вручную в Vault.

Вот таким образом системы, которые, казалось бы, невозможно связать между собой, связываются, и между ними мир, дружба, жвачка. Невозможное возможно.

Вопросы

Где это реализовано?

Это реализовано у нас в инфраструктуре, внутри компании “Серебряная Пуля”. Мы используем это для наших клиентов, пока нет решения о том, что это будет OpenSource-решением.

Можно ли реализовать связку PostgreSQL+Consul?

Можно реализовать любую связку – ЧтоТо+Consul – появилось, зарегистрировалось и работает.

Есть база Прод1 и база Прод2. Они связаны планами обмена, HTTP-сервисами и т.д. Мы делаем копию обоих баз – получилась база Копия1 и база Копия2. Что нужно сделать, чтобы Consul решил проблему перенастройки связей между Копией1 и Копией2?

Здесь мы хотим как раз подключать микросервисы с помощью таких инструментов, как OpenFaaS либо OpenWhisk. То есть, мы пишем какие-то маленькие приложения на том же OneScript, запаковываем их в Docker, реализуем REST API. И когда новой базе потребуется постучаться в какой-то микросервис, она спросит у Consul – куда обратиться. Она постучится в этот микросервис, а он уже либо возвращает, к кому нужно подключиться, либо формирует новое окружение – создает тестовую сборочную линию, новые тестовые базы и т.д. Сейчас мы переходим на микросервисную архитектуру в OpenFaaS и у нас это частично уже начинает реализовываться, но не полностью.

*************

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Новосибирск.