Как использовать секреты Openshift для установления клиентского соединения MQ через SSL
Я пытаюсь объединить предложения о том, как использовать SSL с openshift: https://blog.openshift.com/openshift-demo-part-13-using-ssl/
с тем, как использовать ssl с mq:
Поэтому мне удалось изменить приложение Spring Boot Camel, чтобы перейти от соединения через канал svrconn mq без SSL к тому, который использует SSL, добавив свойство SSLCipherSuite в bean com.ibm.mq.jms.MQConnectionFactory и добавив эти аргументы VM для запуска Конфигурация (как описано во втором связанном документе):
И он отлично работает на встроенном сервере Tomcat, однако мне нужно будет развернуть его в Openshift, поэтому первым моим импульсом было добавить те же аргументы виртуальной машины тем, которые я использую для развертывания Openshift, а именно:
но, очевидно, это не работает, например, потому что у меня нет того же пути к хранилищу ключей. Поэтому я немного его изучил и узнал, что мне нужно использовать секреты, которые могут быть определены с помощью команды CLI >> oc secrets new > Добавить значение из карты конфигурации или секретного > Откат Backoff > Журналы больше не доступны или не могут быть загружены. 2018-06-21T15:19:00+03:00 3 года, 5 месяцев назад
ИМХО вы неверно истолковываете некоторые из настроек, которые вы здесь указываете.
Аргументы VM после «-Dkubernetes.master =», которые вы указываете здесь, я предполагаю, должны быть предоставлены плагину fabric8 maven, который вы используете для развертывания. Правильно?
Параметры, которые касаются аутентификации/сертификатов здесь, являются ТОЛЬКО для связи с кубернетами и НЕ предназначены для предоставления данных хранилища ключей для использования вашим приложением. Поэтому я думаю, что они не связаны.
Вместо этого вам нужно убедиться, что внутри вашего контейнера ваше приложение запускается с теми же параметрами, которые вы используете для локального выполнения. Конечно, вам придется изменить значения параметров на то, где соответствующие данные доступны внутри вашего контейнера.
Альтернативой предоставлению секретных данных в качестве переменной среды, как вы и пытались, является просто монтирование их в файловую систему, которая делает секретные данные доступными в виде файлов. Поскольку вашему приложению нужен JKS в качестве файла, вы можете сделать следующее.
В веб-консоли при развертывании используйте ссылку «Добавить файлы конфигурации» в разделе «Объемы»,
Выберите секретный «my-key-jks», созданный ранее как «источник».
Укажите некоторый путь, где секрет должен быть установлен внутри вашего контейнера, например «/secret». Затем нажмите «Добавить».
Добавление или изменение секрета опроса Red Hat в кластере Azure Red Hat OpenShift 4
В этом руководстве описывается добавление или изменение секрета опроса Red Hat для существующего кластера Azure Red Hat OpenShift (ARO) 4.x.
При первом создании кластера можно добавить свой секрет опроса. Дополнительные сведения о создании кластера ARO с секретом опроса Red Hat см. в статье Создание кластера Azure Red Hat OpenShift 4.
Перед началом
В этом руководстве предполагается, что кластер Azure Red Hat OpenShift 4 уже существует. Убедитесь в наличии доступа к кластеру с правами администратора.
Подготовка секрета опроса
При создании кластера ARO без добавления секрета опроса Red Hat такой секрет создается в кластере автоматически. Однако этот секрет по запросу заполнен не полностью.
В этом разделе описано, как изменить этот секрет опроса, используя дополнительные значения из секрета по запросу Red Hat.
Извлеките секрет с именем pull-secret в пространстве имен openshift-config и сохраните его в отдельный файл, выполнив следующую команду:
Результат должен быть аналогичен следующему. (Обратите внимание, что фактическое значение секрета было удалено.)
Перейдите на портал диспетчера кластеров Red Hat OpenShift и выберите Скачать секрет опроса. Секрет опроса для Red Hat будет выглядеть следующим образом. (Обратите внимание, что фактические значения секрета были удалены.)
Измените файл секрета опроса, полученный из кластера, добавив записи, найденные в секрете опроса Red Hat.
Включение записи cloud.openshift.com из секрета опроса Red Hat приведет к тому, что кластер начнет отправлять данные телеметрии в Red Hat. Включайте этот раздел, только если нужно отправлять данные телеметрии. В противном случае пропустите следующий раздел.
Не удаляйте и не изменяйте запись arosvc.azurecr.io в секрете опроса. Этот раздел необходим для правильной работы кластера.
Окончательный файл должен выглядеть примерно следующим образом. (Обратите внимание, что фактические значения секрета были удалены.)
Убедитесь, что файл является правильным JSON-файлом. Проверить правильность формата JSON можно разными способами. В следующем примере используется jq:
Добавление секрета опроса в кластер
Выполните следующую команду, чтобы изменить секрет опроса.
Выполнение этой команды приведет к перезапуску узлов кластера по одному по мере их обновления.
После настройки секрета можно включить операторы Certified в Red Hat.
Изменение файлов конфигурации
Измените следующие объекты, чтобы включить операторы Red Hat.
Сначала измените файл конфигурации оператора Samples. Затем можно выполнить следующую команду, чтобы изменить файл конфигурации:
В следующем фрагменте кода YAML показаны только соответствующие разделы измененного файла YAML:
Во-вторых, выполните следующую команду, чтобы изменить файл конфигурации оператора Hub:
Измените значения Spec.Sources.Disabled и Status.Sources.Disabled с true на false для всех источников, которые нужно включить.
В следующем фрагменте кода YAML показаны только соответствующие разделы измененного файла YAML:
Сохраните файл, чтобы применить изменения.
Проверка работоспособности секрета
Для обновления кластера после добавления секрета допроса и изменения правильных файлов конфигурации может потребоваться несколько минут. Чтобы проверить, обновился ли кластер, выполните следующую команду, чтобы показать доступные источники операторов Certified и операторов Red Hat:
Если операторы Certified и Red Hat не видны, подождите несколько минут и повторите попытку.
Чтобы убедиться, что секрет опроса обновлен и работает правильно, откройте OperatorHub и проверьте любой проверенный оператор Red Hat. Например, проверьте, доступен ли оператор хранилища контейнера OpenShift, и проверьте, есть ли у вас разрешения на установку.
Дальнейшие действия
Дополнительные сведения о секретах опроса для Red Hat см. в статье Использование секретов опроса образа.
Дополнительные сведения о Red Hat OpenShift 4 см. в документации платформы контейнеров Red Hat OpenShift.
Черная метка – как OpenShift защищает от уязвимости контейнеров с помощью SELinux
Бывало ли, что вы выполняли для блага общества непростую работу, а ваших усилий не замечали, потому что вы приносили пользу так долго, что все давно привыкли? Именно такую работу для вас совершают все участники сообщества SELinux.
И вот 18 февраля этого года, во многом благодаря их работе, мир был спасен от опасной поражающей контейнеры уязвимости CVE-2019-5736.
Хотя существуют и другие операционные системы, и другие проекты с открытым кодом, в которых применяется контроль по типам и категориям, редко бывает, когда все компоненты, настроенные с SELinux, включены «из коробки», по умолчанию и готовы к работе. Еще реже эта конфигурация охватывает все уровни, вплоть до решения для оркестрации контейнеров, на основе которого работает публичное облако.
В Red Hat OpenShift уже восемь лет используются такие механизмы принудительного контроля доступа Linux, как контроль по типам (type enforcement, TE) и мультикатегорийная безопасность (multi-category security, MCS). SELinux применяется в OpenShift с 2011 года. В Red Hat OpenShift Online – общедоступном хостинговом сервисе, где тысячи разработчиков ежедневно запускают код в виде контейнеров, – SELinux используется с самого начала. А что как насчет версии OpenShift, который используется, например в ЦОДе вашего любимого сотового оператора? На самом деле, модуль безопасности SELinux включен в Red Hat OpenShift Container Platform по умолчанию, бай дефолт! Причем не просто включен, а полностью настроен и готов защищать от реальных угроз.
В отличие от других дистрибутивов Kubernetes, Red Hat закрывает брешь между Linux и установленной поверх платформой оркестрации контейнеров. То есть Red Hat OpenShift отслеживает и устраняет угрозы безопасности по всему стеку, а не только в одном слое. И это делается по умолчанию – с первого дня работы.
OpenShift по умолчанию использует эту конфигурацию в Red Hat Enterprise Linux (вам даже необязательно знать что она там есть). Дело не ограничивается тем, чтобы запустить на ноутбуке setenforce 1. Правила контроля доступа по типам и категориям, которые арендатор применяет для работы с контейнерами на одном кластере Kubernetes, можно распространить на сотни узлов, которыми могут пользоваться тысячи других арендаторов.
Задумайтесь, как будет выглядеть конфигурация SELinux с MCS через несколько лет использования в крупной компании, которая раздает учетные данные OpenShift направо и налево. Теперь представьте, что вы предоставляете свои учетные данные для входа в ваш кластер OpenShift, как мы делаем это на openshift.com. Преданность SELinux часто не получает признания за все, что делает в решении OpenShift. Если вам кажется, что в наши дни операционная система уже не так важна, подумайте, а были ли вы защищены от уязвимости CVE-2019-5736 до этого февраля. В OpenShift защита от уязвимости CVE-2019-5736 применяется с самого начала и на это решение можно перейти уже сейчас.
SELinux ставит отметки
Одной из наиболее эффективных функций безопасности по умолчанию, реализованных в Red Hat OpenShift, является Security-Enhanced Linux (SELinux). SELinux – это модуль безопасности ядра Linux, обеспечивающий механизм принудительного контроля доступа на основе политик безопасности. Способ работы SELinux заключается в том, чтобы присваивать метки (имена) всем процессам и объектам операционной системы. Таким образом, каждый элемент, задействованный в операциях ядра, помечается и классифицируется, а затем ему предоставляется доступ на основе имеющегося набора правил.
Правила политики определяют отношения между помеченными процессами и помеченными объектами. Правила, заданные пользователем в политиках, применяются на уровне ядра. По умолчанию всё, что не разрешено, автоматически запрещается – по аналогии с брандмауэром, который отказывает в доступе всем процессам, для которых не настроены явные разрешения. На рисунках ниже наглядно проиллюстрированы простые сценарии использования.
Представим систему, в которой нужно определить типы для таких объектов, как кошки и собаки. Кошка и собака – это типы процессов.
Класс объектов, с которыми будут взаимодействовать процессы, – корм. Добавим типы корма: cat_chow и dog_chow (Ом-ном-ном).
Зададим для собаки разрешение есть собачий корм (dog_chow), а для кошки – кошачий (cat_chow). Запишем эти разрешения в виде правила политики SELinux:
По этим правилам процессу «кошка» будет на уровне ядра разрешено есть корм с меткой cat_chow, а собаке – корм с меткой dog_chow.
Но мы помним, что в системе SELinux по умолчанию все запрещено. Поэтому если собака попытается съесть корм cat_chow, ядро не позволит этого сделать.
Это и есть контроль по типам, который играет главную роль в защите хост-системы от контейнерных процессов. Контейнерные процессы могут читать и запускать только файлы из каталога /usr и записывать данные только в контейнерные файлы. Это ограничение надежно защищает хост от контейнеров, но не обеспечивает защиту одних контейнеров от других, ведь все они помечены одним типом. Чтобы защитить контейнеры друг от друга, потребуется внедрить контроль по меткам MCS.
MCS не тянет кота за хвост
Применение MCS не связано напрямую с защитой OpenShift от уязвимости CVE-2019-5736, но с этой темой полезно ознакомиться, чтобы лучше понимать принципы использования SELinux в OpenShift. Присвоение меток MCS с точки зрения пользователя или системного администратора происходит достаточно просто. Нужно всего лишь настроить набор категорий, представляющих собой простые текстовые метки (например, Fido или Spot), и добавить в них пользователей. Системный администратор сначала настраивает категории, а затем добавляет в них пользователей, после чего пользователи могут применять эти метки по своему усмотрению. Это удобно, так как MCS позволяет использовать стандартные метки SELinux для управления объектами. Снова обратимся к воображаемой системе из примера выше.
Добавим еще одну часть метки, которая будет применяться к процессу «собака» и корму dog_chow. Присвоим процессу «собака» метки dog:random1 (Fido) и dog:random2 (Spot).
Корму для собак присвоим метки dog_chow:random1 (Fido) и dog_chow:random2 (Spot).
Согласно принципам работы MCS, если правила принудительного контроля по типу соблюдены и произвольные метки MCS точно совпадают, то доступ разрешается, а во всех остальных случаях он запрещается.
Попытки Fido (dog:random1) съесть корм cat_chow:food будут отклонены благодаря принудительному контролю по типу.
Глубоко эшелонированная защита
Модуль безопасности SELinux, который применяется в OpenShift по умолчанию, – яркий пример глубоко эшелонированной защиты. В OpenShift, как и во многих других платформах на базе Kubernetes, используются политики SCC/PSP, запрещающие запускать контейнеры с правами root-пользователя. Это ограничение также защищает от уязвимости CVE-2019-5736. В OpenShift по умолчанию блокируются контейнеры, владельцем которых является root-пользователь, но этот параметр можно изменить. Даже если разрешить запускать контейнеры от имени root-пользователя, стандартная конфигурация SELinux в OpenShift все равно защищает от уязвимости CVE-2019-5736. Это еще один уровень защиты, который действительно оправдывает себя в данной ситуации и он в OpenShift далеко не единственный. Дополнительную информацию можно найти в документе 10 уровней контейнерной безопасности.
Дополнительную информацию об уязвимости CVE-2019-5736, в том числе о патче Red Hat Enterprise Linux для среды выполнения контейнеров, можно найти в отзыве Red Hat на уязвимость.
Openshift — красношляпые поделки
OpenShift
1. Развертка Openshift
Требования к серверам, подготовка dns серверов, список имен серверов, требования к серверам.
Минимальные требования кратко — все сервера должны иметь минимум 16Gb Ram 2 ядра и минимум 100 гигабайт для нужд docker.
dns на базе Bind должен иметь следующую конфигурацию.
dkm — мастер, dk0 — исполняющие, ifr — инфраструктурные, bln — балансировщик, shd — nfs, dkr — управляющая нода с которой происходила конфигурация кластера, так же планировалась как отдельная нода под docker regestry.
После подключения подписки. Включение репозиториев и установка необходимых изначально пакетов.
Конфигурация хранилища докера (отдельным диском).
Установка остальных необходимых пакетов.
Создание, добавление пользователя, а также ключей.
В случае конфликта с уже используемыми подсетями — изменить адресацию по умолчанию внутри контейнеров.
Конфигурация network manager. (dns должен уметь froward во внешний мир)
Правка в случае необходимости имени машины на полное имя.
После выполненных действий перезагрузить сервера.
Подготовка управляющей ноды dkr
Отличие управляющей ноды от остальных — нет необходимости подключать docker на отдельный диск.
Также есть необходимость настройки ntp.
Также нужно добавить закрытый ключ пользователю ocp.
Зайти по ssh под пользователем ocp на все ноды.
Подготовка Inventory file и развертка кластера.
Запуск поочередно плейбуков.
Если все хорошо в конце будет примерно следующие.
Правка локального файла хост для проверки после установки работу oprenshift по веб интерфейсу.
2. Конфигурация после установки
Проверить что есть возможность видеть в web интерфейсе скрытые ранее project (openshift, например).
3. Создание и подключение PV
Создание persistent volume на сервере nfs.
Добавление pv в openshift.
Необходимо создать проект oc new-project examplpv-project.
Если проект уже создан перейти в него oc project examplpv-project. Создать yaml следующего содержания.
созданный pv будет виден в списке.
4. Создание и разворачивание проекта Red Hat Decision Manager (enterprise аналог kie-workbench)
Проверить наличие шаблонов.
Добавление шаблонов — ссылку и более полное описание можно найти
Создадим новый проект:
Добавление авторизации на сервер docker registry.redhat.io:
Импорт imagetream, создание ключей Decision Server, Decision Central.
Создание persistent volume на сервере nfs.
Добавить pv в проект:
Приложение автоматически развернется по завершению Pull образов в docker-registry.
До этого момента статус будет таким.
В случае перехода по ссылке на образ будет следующая ошибка
Необходимо изменить url загрузки образов выбрав edit yaml с registry.redhat.io на registry.access.redhat.com
Для перехода в развернутый сервис в его web интерфейс необходимо добавить в файл hosts следующие url
на на любую из infra nodes
10.19.86.25 rnd-osh-ifr-t02.test.osh myapp-rhdmcentr-rhdm72.apps.openshift.test.osh
5. Создание и разворачивание проектов AMQ (red hat active mq) и postgressql c использованием персистентных хранилищ
Создадим новый проект
Импортируем образы в случае их отсутствия.
Добавление роли сервис аккаунту.
Создание pv на сервере nfs
Создаем из шаблона
Создаем еще один PV аналогично тому как делали для MQ.
Заполняем необходимые параметры
6. Создание отдельных проектов для сервисов, шаблонов к ним, pipeline, интеграция с gitlab, gitlab regestry
Первый делом необходимо создать проект.
Первично не имея шаблона можно создать в ручную приложение.
Есть два способа.
Первый просто используя готовый образ, но тогда не будет доступна версионность образов и т.д., но в некоторых случаях будет актуально.
Прежде всего, нужно получить данные для аутентификации к registry. На примере собранного образа в Gitlab это делается вот так.
Для начала надо создать секреты по доступу к docker registry — посмотреть варианты и синтаксис.
Затем создадим секрет
Затем создадим наше приложение.
Если что-то пошло не так, и образ не тянется в свойставх приложения указать секрет к нашему regestry.
Затем добавляем необходимые переменные окружения.
Готово — контейнер живой.
Затем нажмем справа edit yaml и укажем порты.
Затем чтобы получить доступ к нашему контейнеру необходимо создать route, но создать его без сервиса невозможно, потому первым делом необходимо создать сервис.
прописываем url в hosts на своей машине смотрящим на одну из infra nodes.
прописываем url в hosts на своей машине смотрящим на одну из infra nodes.
Шаблон создается методом выгрузки в yaml по отдельности всех компонентов которые относятся к сервису.
А именно в данном случае это secrets dc Service Route.
Посмотреть все что сделано в конкретном проекте можно
Затем можно взять за основу любой шаблон для opensihft и интегрировать то что было получено для получения шаблона.
В данном случае результат будет выглядеть так:
Можно добавить сюда и secret-ы, в следующем примере рассмотрим вариант сервиса со сборкой на стороне openshift где secret-ы будут в шаблоне.
Создание проекта с полными стадиями сборки образов, простому pipeline и сборкой по Push.
Первым делом создадим новый проект.
Для начала нужно создать Buildconfig из гита (в данном случае в проекте есть три докер файла, обычный докер файл который рассчитан на docker версии 1.17 выше используя два FROM, и два отдельных dockerfile для сборки базового образа и целевого.)
Для доступа в гит если он приватный нужна авторизация. Создадим secret со следующим содержанием.
Дадим сервис аккаунту builder доступ к нашему секрету
Привяжем секрет к url git
На выходе можно получить два вот таких шаблона.
Также нам понадобится создать deploymentconfig два imagestream и для завершения развертки service и route.
Я предпочел не плодить отдельно все конфиги, а сразу делать шаблон, включающий все компоненты для сервиса. за основу взяв предыдущий шаблон для варианта без сборки.
Использовать данный шаблон для развертки можно так
Затем создадим Pipeline
После применения конфигурации Pipeline, запустив
Можно получить url для webhook в gitlab.
Секрет заменить на указанный секрет в конфиге.
Так же после применения Pipeline openshift сам начнет установку jenkins в проекте для запуска Pipeline. Первичный запуск длительный, так что необходимо подождать некоторое время.
Затем в Gitlab в нашем проекте:
Заполнить Url, secret, убрать Enable SSL verificationю И наш webhook готов.
Можно сделать тестовый push и посмотреть на ход ведения сборки
Не забудьте прописывать в host url чтобы попасть в тот же jenkins на infranode.
Так же можно посмотреть ход сборки.
P.S. Надеюсь данная статья поможет многим понять как и с чем едят openshift, разяснит многие не очевидные с первого взгляда моменты.
P.S.S. некоторые решения для решения некоторых проблем
Проблемы с запуском билда сборки и т.д.
— создать сервис аккаунт для проекта
Проблемы с подвисом проекта и не удалением его
— скрипт принудительного завершения (болезнь врожденная)
Проблемы с загрузкой образов.
Также переопределить разрешения на папку для registry на nfs. (в логах registry ошибки на запись, билд же висит на пуше).