Безопасность OpenShift — это в основном комбинация двух компонентов, которая в основном обрабатывает ограничения безопасности.
- Ограничения контекста безопасности (SCC)
- Сервисный аккаунт
Ограничения контекста безопасности (SCC)
Он в основном используется для ограничения модуля, что означает, что он определяет ограничения для модуля, а также то, какие действия он может выполнять и какие вещи он может получить в кластере.
OpenShift предоставляет набор предопределенных SCC, которые могут быть использованы, изменены и расширены администратором.
$ oc get scc NAME PRIV CAPS HOSTDIR SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY anyuid false [] false MustRunAs RunAsAny RunAsAny RunAsAny 10 hostaccess false [] true MustRunAs MustRunAsRange RunAsAny RunAsAny <none> hostmount-anyuid false [] true MustRunAs RunAsAny RunAsAny RunAsAny <none> nonroot false [] false MustRunAs MustRunAsNonRoot RunAsAny RunAsAny <none> privileged true [] true RunAsAny RunAsAny RunAsAny RunAsAny <none> restricted false [] false MustRunAs MustRunAsRange RunAsAny RunAsAny <none>
Если кто-то хочет использовать какой-либо заранее заданный scc, это можно сделать, просто добавив пользователя или группу в scc группу.
$ oadm policy add-user-to-scc <scc_name> <user_name> $ oadm policy add-group-to-scc <scc_name> <group_name>
Сервисный аккаунт
Сервисные учетные записи в основном используются для управления доступом к главному API OpenShift, который вызывается при запуске команды или запроса с любого из главного или узлового компьютера.
Каждый раз, когда приложению или процессу требуется возможность, которая не предоставляется ограниченным SCC, вам нужно будет создать определенную учетную запись службы и добавить учетную запись в соответствующий SCC. Однако, если SCC не соответствует вашим требованиям, лучше создать новый SCC, соответствующий вашим требованиям, а не использовать тот, который лучше всего подходит. В конце установите его для конфигурации развертывания.
$ oc create serviceaccount Cadmin $ oc adm policy add-scc-to-user vipin -z Cadmin
Контейнерная безопасность
В OpenShift безопасность контейнеров основана на том, насколько безопасна платформа контейнеров и где работают контейнеры. Когда мы говорим о безопасности контейнеров и о том, что нужно позаботиться о них, возникает множество вещей.
Image Provenance — внедрена защищенная система маркировки, которая точно и неопровержимо определяет, откуда пришли контейнеры, работающие в производственной среде.
Сканирование безопасности — сканер изображений автоматически проверяет все изображения на наличие известных уязвимостей.
Аудит . Производственная среда регулярно проверяется, чтобы убедиться, что все контейнеры основаны на современных контейнерах, а хосты и контейнеры настроены надежно.
Изоляция и минимальные привилегии. Контейнеры работают с минимальными ресурсами и привилегиями, необходимыми для эффективного функционирования. Они не могут чрезмерно мешать хосту или другим контейнерам.
Обнаружение угроз во время выполнения — возможность обнаруживать активные угрозы для контейнерного приложения во время выполнения и автоматически реагировать на него.
Контроль доступа — модули безопасности Linux, такие как AppArmor или SELinux, используются для обеспечения контроля доступа.
Существует несколько ключевых методов архивирования безопасности контейнера.
- Управление доступом через oAuth
- Через веб-консоль самообслуживания
- По сертификатам платформы
Управление доступом через OAuth
В этом методе аутентификация для доступа к управлению API архивируется с получением защищенного токена для аутентификации через серверы OAuth, который встроен в главный компьютер OpenShift. Как администратор, вы можете изменять конфигурацию конфигурации сервера OAuth.
Подробнее о настройке сервера OAuth см. В главе 5 этого руководства.
Через веб-консоль самообслуживания
Эта функция безопасности веб-консоли встроена в веб-консоль OpenShift. Эта консоль гарантирует, что все команды, работающие вместе, не имеют доступа к другим средам без аутентификации. Мастер multi-telnet в OpenShift имеет следующие функции безопасности:
- Уровень TCL включен
- Использует сертификат x.509 для аутентификации
- Защищает конфигурацию etcd на главном компьютере
По сертификатам платформы
В этом методе сертификаты для каждого хоста настраиваются во время установки через Ansible. Поскольку он использует протокол связи HTTPS через Rest API, нам необходимо защищенное соединение TCL с различными компонентами и объектами. Это предопределенные сертификаты, однако для доступа можно даже установить собственный сертификат в кластере мастера. Во время первоначальной настройки мастера пользовательские сертификаты могут быть настроены путем переопределения существующих сертификатов с помощью параметра openshift_master_overwrite_named_certificates .
пример
openshift_master_named_certificates = [{"certfile": "/path/on/host/to/master.crt",
"keyfile": "/path/on/host/to/master.key",
"cafile": "/path/on/host/to/mastercert.crt"}]
Для получения более подробной информации о том, как создавать пользовательские сертификаты, перейдите по следующей ссылке —
https://www.linux.com/learn/creating-self-signed-ssl-certificates-apache-linux
Сетевая безопасность
В OpenShift для связи используется программно-определяемая сеть (SDN). Сетевое пространство имен используется для каждого модуля в кластере, причем каждый модуль получает свой собственный IP и диапазон портов для получения сетевого трафика на нем. С помощью этого метода можно изолировать модули, из-за которых они не могут взаимодействовать с модулями в другом проекте.
Изоляция проекта
Это может сделать администратор кластера с помощью следующей команды oadm из CLI.
$ oadm pod-network isolate-projects <project name 1> <project name 2>
Это означает, что определенные выше проекты не могут взаимодействовать с другими проектами в кластере.
Объем безопасности
Под защитой томов подразумевается защита PV и PVC проектов в кластере OpenShift. В основном в OpenShift есть четыре раздела для управления доступом к томам.
- Дополнительные группы
- fsGroup
- RunAsUser
- seLinuxOptions
Дополнительные группы — Дополнительные группы — это обычные группы Linux. Когда процесс выполняется в системе, он запускается с идентификатором пользователя и идентификатором группы. Эти группы используются для управления доступом к общему хранилищу.
Проверьте монтирование NFS с помощью следующей команды.
# showmount -e <nfs-server-ip-or-hostname> Export list for f21-nfs.vm: /opt/nfs *
Проверьте сведения о NFS на сервере монтирования, используя следующую команду.
# cat /etc/exports /opt/nfs *(rw,sync,no_root_squash) ... # ls -lZ /opt/nfs -d drwxrws---. nfsnobody 2325 unconfined_u:object_r:usr_t:s0 /opt/nfs # id nfsnobody uid = 65534(nfsnobody) gid = 454265(nfsnobody) groups = 454265(nfsnobody)
/ Opt / nfs / export доступен по UID 454265 и группе 2325 .
apiVersion: v1
kind: Pod
...
spec:
containers:
- name: ...
volumeMounts:
- name: nfs
mountPath: /usr/share/...
securityContext:
supplementalGroups: [2325]
volumes:
- name: nfs
nfs:
server: <nfs_server_ip_or_host>
path: /opt/nfs
fsGroup
fsGroup обозначает группу файловой системы, которая используется для добавления дополнительных групп контейнера. Идентификатор группы дополнений используется для общего хранилища, а fsGroup — для блочного хранилища.
kind: Pod
spec:
containers:
- name: ...
securityContext:
fsGroup: 2325
RunAsUser
runAsUser использует идентификатор пользователя для связи. Это используется при определении изображения контейнера в определении модуля. Один идентификатор пользователя может быть использован во всех контейнерах, если требуется.
При запуске контейнера указанный идентификатор сопоставляется с идентификатором владельца при экспорте. Если указанный идентификатор определен снаружи, он становится глобальным для всех контейнеров в модуле. Если это определено с определенным модулем, то это становится определенным для единственного контейнера.