«id =» main «> Поделиться
Red Hat OpenShift становится все более популярной как платформа для управления контейнерами. Благодаря тому, что эти контейнеры легко встраиваются в различные приложения, это решение действительно было оценено разработчиками. не всегда методы, способствующие быстрой разработке программного обеспечения, предполагают заботу обо всех аспектах безопасности данной реализации.
Ниже я хотел бы выделить несколько основных проблем безопасности, которые мы попытаемся поместить в контекст контейнерной платформы OpenShift.
Фактически, очень большая группа проблем ИТ-безопасности может быть решена с помощью довольно фундаментального вопроса: «Что мой контейнер может быть встроен в платформу OpenShift?» Возможно, у некоторых из нас сразу возникает вопрос, к каким ресурсам постоянного хранения у нашего контейнера есть доступ? Какие из них я могу изменить? Может ли этот конкретный контейнер работать с привилегиями root?
Последний вопрос представляет особый интерес в контексте необходимости полностью избежать возможности эксплуатации & nbsp; уязвимости некоторых механизмов платформы OpenShift таким образом, чтобы получить контроль над процессом контейнера, который работает с с привилегиями привилегированного пользователя, он также становится & nbsp; root & nbsp; на хост-машине. Если в нашей среде мы не разрешаем запускать контейнеры, работающие с привилегиями пользователя root, что платформа OpenShift делает для нас по умолчанию, то мы защищаем себя от этой проблемы, по крайней мере, до определенной степени.
Однако, если нам действительно нужно запускать отдельные контейнеры от привилегированного пользователя, каков самый безопасный способ сделать это? Тогда так называемый сервисные & nbsp; аккаунты. В идеале в конкретном проекте как конкретный пользователь OpenShift вы должны создать учетную запись службы. Затем с помощью учетной записи & nbsp; cluster-admin & nbsp; добавьте указанную учетную запись службы в политику SCC & nbsp; anyuid:
oc adm policy add-scc-to-user anyuid -z kontoserwisowe (1)
Стоит обратить внимание на то, что используется довольно популярное решение:
oc adm policy add-scc-to-user anyuid -z default (2)
заставит все контейнеры запускаться от имени пользователя root внутри определенного проекта. Благодаря использованию (1) только конкретный контейнер, конфигурация развертывания & nbsp; которого будет изменен таким образом, который требует использования определенной учетной записи службы & nbsp; службы поддержки, сможет выполнять итак.
Таким образом, мы существенно повлияем на контроль количества «привилегированных» контейнеров, потому что это ограничение также распространяется на возможность выполнять определенные директивы докеров, такие как USER, или простейшие команды chmod, chown внутри Dockerfile. Что касается самих правил SCC, которых даже поверхностного обзора может хватить для многих отдельных публикаций, дополнительную информацию можно найти в отличной статье: Understanding Service Accounts and SCCs.
Возвращаясь к нашим первоначальным вопросам о безопасности OpenShift, в контексте самой безопасности данных, похоже, ключ заключается в выборе соответствующей политики для очистки неиспользуемых дисковых ресурсов (постоянных томов). Используя политику повторного использования по умолчанию (которая медленно помечается Red Hat как & nbsp; устаревшая, заменяется & nbsp; Delete) на данном физическом томе, когда соответствующее требование постоянного тома откреплено, данные на этом томе будут удалены. Политика Retain сохраняет эти данные.
При рассмотрении дополнительных постоянных томов естественно, но не менее важно выбрать соответствующий режим доступа для данного тома.
Переходя к нашим соображениям безопасности, мы можем задать вопрос, который является довольно универсальным для ряда платформ, а не только для OpenShift: «Кто и что может делать на самой платформе OpenShift?» Вообще говоря, у нас есть два уровня распределения прав доступа к ресурсам OpenShift. Первый предоставляет доступ к ресурсам на уровне проекта. Данный пользователь может быть администратором данного проекта (с полными правами), иметь право редактировать, то есть создавать и изменять все объекты, кроме так называемых привязок и кавычек, или быть базовым пользователем или даже только тем, кто может только просмотр конфигурации (просмотр).
Мы имеем дело с подобной грануляцией на уровне предоставленных разрешений в случае доступа, описывающего возможности данных типов пользователей по отношению ко всему кластеру OpenShift, а не только к отдельным проектам. Эти разрешения можно указать с помощью следующих команд:
oc adm policy & lt; add-role-to-user> или & lt; add-cluster-role-to-user>
В зависимости от ' предоставленные нами разрешения scope, с помощью аналогичных команд мы справляемся с необходимостью удалить вышеупомянутые разрешения у данного пользователя или группы (remove-role-from-user, remove-cluster-role-from-user).
Чтобы проверить текущий статус разрешений, мы вводим команду (вместе с примером ответа):
[root @ rhel-openshift-master ~] # oc get rolebindings ИМЯ РОЛЬ ПОЛЬЗОВАТЕЛИ ГРУППЫ СЕРВИС АККАУНТЫ СУБЪЕКТЫ admin/admin piotr.stolarek admin-0/admin pstolarek edit/edit testowe1 edit-0/edit testowe2 system: deployers/system: deployer deployer system: image-builders/system: image-builder builder system: image-pullers/system: image-puller система: serviceaccounts: test
В зависимости от настроек конкретного проекта результат этой команды будет отличаться возвращаемым значением. Аналогичная команда с глобальной перспективой для всего кластера (oc get clusterrolebindings) будет независимой с точки зрения результата фактического проекта, в котором она запущена.
Еще одна довольно обширная проблема, которая естественно возникла при рассмотрении до сих пор, — это аутентификация самой платформы. Вышеописанные права для так называемых обычных пользователей на платформе OpenShift или функциональных пользователей могут применяться только тогда, когда мы определяем источник аутентификации для платформы (поставщик удостоверений), который фактически « предоставит 'нам базу пользователей, которая является позже отразился и на платформе OpenShift. По умолчанию создается только привилегированный пользователь system: admin.
OpenShift не имеет внутренней базы пользователей, но имеет возможность подключать длинный список этих провайдеров. Самый популярный и, вероятно, самый простой вариант настройки — это аутентификация с помощью & nbsp; htpasswd. Для корпоративных целей лучше всего использовать: & nbsp; LDAPPAssworDIdentityProvider. Ниже приведен фрагмент файла конфигурации & nbsp; master-config.yaml, относящийся к этой конфигурации:
oauthConfig: assetPublicURL: https: ⁄opensourceday.linuxpolska.pl: 8443/console/grantConfig: method: auto identityProviders: — challenge: true login: true mappingMethod: имя требования: ldapIPA provider: apiVersion: v1 Attributes: … bindDN: uid = svc_oseipa, cn = users, cn = accounts, dc = ipa, dc = linuxpolska, dc = pl BindPassword: 'opensourceday2018' … insecure: false kind: LDAPPasswordIdentityProvider url: ldaps: //ipa.linuxpolska.pl: 636/cn = users, cn = accounts, dc = ipa, dc = linuxpolska, dc = pl? uid? sub?
В приведенном выше примере мы использовали сервер Red Hat IPA в качестве сервера аутентификации. Связь осуществляется по защищенному (insecure = false) протоколу & nbsp; ldaps & nbsp; на порту 636.
Чтобы уточнить нашу конфигурацию, администратор также должен рассмотреть возможность ограничения возможности входа на платформу только определенной группой в структуре LDAP в IPA, например, используя решение, подобное следующему:
(memberOf = cn = ose_admins, cn = groups, cn = accounts, dc = ipa, dc = linuxpolska, dc = pl).
Представляя следующие проблемы безопасности, характерные для платформы OpenShift, давайте в качестве оправдания воспользуемся приведенным выше фрагментом конфигурации. На первый взгляд, пароль для пользователя, который может запрашивать у службы каталогов идентификационные данные, встроен в этот файл в виде обычного текста. Это решение, по крайней мере, неэлегантно, поэтому мы изменим его, чтобы заменить фрагмент:
BindPassword: 'opensourceday2018' следующим: bindPassword: file: /root/bindPasswordtest.encrypted keyFile: /root/bindPasswordtest.key
Соответствующий ключ файлов и правильный файл зашифрованных паролей генерируются с помощью команды:
oc adm ca encrypt –genkey =/root/bindPasswordtest.key –out =/root/bindPasswordtest.encrypted
Благодаря этому типу изменения в файлах конфигурации, мы можем скрыть важные данные, такие как, например, пароль, указанный выше. В целом, однако, использование так называемых секретов намного шире и очень полезно в аналогичных ситуациях при создании конфигурации развертывания (deploymentconfig) подиумов, где мы также хотели бы скрыть некоторую информацию, например имя пользователя, имя базы данных, пароль базы данных и т. д. с помощью этого решения перечисленные образцы данных не будут отображаться в незашифрованном виде в файле & nbsp; deploymentconfig & nbsp;