rbac openshift что это

Понимаем RBAC в Kubernetes

Прим. перев.: Статья написана Javier Salmeron — инженером из хорошо известной в Kubernetes-сообществе компании Bitnami — и была опубликована в блоге CNCF в начале августа. Автор рассказывает о самых основах механизма RBAC (управление доступом на основе ролей), появившегося в Kubernetes полтора года назад. Материал будет особенно полезным для тех, кто знакомится с устройством ключевых компонентов K8s (ссылки на другие подобные статьи см. в конце).

Слайд из презентации, сделанной сотрудником Google по случаю релиза Kubernetes 1.6

Многие опытные пользователи Kubernetes могут вспомнить релиз Kubernetes 1.6, когда авторизация на основе Role-Based Access Control (RBAC) получила статус бета-версии. Так появился альтернативный механизм аутентификации, который дополнил уже существующий, но трудный в управлении и понимании, — Attribute-Based Access Control (ABAC). Все с восторгом приветствовали новую фичу, однако в то же время бесчисленное число пользователей были разочарованы. StackOverflow и GitHub изобиловали сообщениями об ограничениях RBAC, потому что большая часть документации и примеров не учитывали RBAC (но сейчас уже всё в порядке). Эталонным примером стал Helm: простой запуск helm init + helm install больше не работал. Внезапно нам потребовалось добавлять «странные» элементы вроде ServiceAccounts или RoleBindings ещё до того, как разворачивать чарт с WordPress или Redis (подробнее об этом см. в инструкции).

Оставив же эти неудачные первые попытки в стороне, нельзя отрицать тот огромный вклад, что внёс RBAC в превращение Kubernetes в готовую к production платформу. Многие из нас успели поиграть с Kubernetes с полными привилегиями администратора, и мы прекрасно понимаем, что в реальном окружении необходимо:

Ключ к пониманию RBAC в Kubernetes

Чтобы полностью осознать идею RBAC, нужно понимать, что к ней причастны три элемента:

Если помнить об этих трёх элементах, ключевая идея RBAC звучит так:

— Мы хотим соединить субъекты, ресурсы API и операции. Другими словами, мы хотим указать для заданного пользователя, какие операции могут быть исполнены на множестве ресурсов.

Разбираемся с объектами RBAC в API

В соединении этих трёх типов сущностей становятся понятными и доступные в Kubernetes API объекты RBAC:

Субъекты: пользователи и… ServiceAccounts?

… но вот такой уже нет:

У этой ситуации серьёзное последствие: если кластер не будет хранить информацию о пользователях, администратору придётся управлять учётными записями вне кластера. Здесь есть разные способы решения проблемы: TLS-сертификаты, токены, OAuth2 и т.п.

RBAC в Deployments: пример

Мы видели пример, в котором указанному пользователю выдаются права на операции в кластере. Но что насчёт Deployments, требующих доступа к Kubernetes API? Рассмотрим конкретный сценарий, чтобы разобраться получше.

Возьмём для примера популярное инфраструктурное приложение — RabbitMQ. Будем использовать Helm-чарт для RabbitMQ от Bitnami (из официального репозитория helm/charts), который использует контейнер bitnami/rabbitmq. В контейнер встроен плагин для Kubernetes, отвечающий за обнаружение других членов кластера RabbitMQ. Из-за этого процесс внутри контейнера требует доступа к Kubernetes API, и нам потребуется настроить ServiceAccount с правильными RBAC-привилегиями.

— Настраивайте ServiceAccounts для каждого Deployment с минимальным набором привилегий.

В случае приложений, требующих доступа к Kubernetes API, у вас может возникнуть соблазн создать некий «привилегированный ServiceAccount », который сможет делать в кластере практически всё. Хотя это кажется более простым решением, в конечном счёте оно может привести к уязвимости в безопасности, позволяющей выполнять нежелательные операции. (В видео рассматривается пример Tiller [компонента Helm] и последствий наличия ServiceAccounts с большими привилегиями.)

Не забывая об этом, посмотрим, какая конфигурация RBAC будет правильной для случая Deployment‘а с RabbitMQ.

В документации плагина и его исходном коде можно увидеть, что он запрашивает у Kubernetes API список Endpoints. Так и происходит обнаружение остальных членов кластера RabbitMQ. Поэтому чарт RabbitMQ от Bitnami создаёт:

Схема показывает, что мы разрешили процессам, запущенным в подах RabbitMQ, исполнять операции get над объектами Endpoint. Это минимальный набор операций, который требуется для того, чтобы всё работало. В то же время мы знаем, что развёрнутый чарт безопасен и не выполнит нежелательных действий внутри кластера Kubernetes.

Заключительные мысли

Чтобы работать с Kubernetes в production, политики RBAC не являются опциональными. Их нельзя рассматривать как набор объектов API, который должны знать только администраторы. Они на самом деле нужны разработчикам для развёртывания безопасных приложений и полного использования потенциала, предлагаемого Kubernetes API для облачных (cloud native) приложений. Больше информации по RBAC можно получить по этим ссылкам:

Источник

Chapter 6. Using RBAC to define and apply permissions

6.1. RBAC overview

Role-based access control (RBAC) objects determine whether a user is allowed to perform a given action within a project.

Cluster administrators can use the cluster roles and bindings to control who has various access levels to the OpenShift Container Platform platform itself and all projects.

Developers can use local roles and bindings to control who has access to their projects. Note that authorization is a separate step from authentication, which is more about determining the identity of who is taking the action.

Authorization is managed using:

Rules

Sets of permitted verbs on a set of objects. For example, whether a user or service account can create pods.

Roles

Collections of rules. You can associate, or bind, users and groups to multiple roles.

Bindings

Associations between users and/or groups with a role.

There are two levels of RBAC roles and bindings that control authorization:

Cluster RBAC

Roles and bindings that are applicable across all projects. Cluster roles exist cluster-wide, and cluster role bindings can reference only cluster roles.

Local RBAC

Roles and bindings that are scoped to a given project. While local roles exist only in a single project, local role bindings can reference both cluster and local roles.

A cluster role binding is a binding that exists at the cluster level. A role binding exists at the project level. The cluster role view must be bound to a user using a local role binding for that user to view the project. Create local roles only if a cluster role does not provide the set of permissions needed for a particular situation.

This two-level hierarchy allows reuse across multiple projects through the cluster roles while allowing customization inside of individual projects through local roles.

During evaluation, both the cluster role bindings and the local role bindings are used. For example:

6.1.1. Default cluster roles

OpenShift Container Platform includes a set of default cluster roles that you can bind to users and groups cluster-wide or locally. You can manually modify the default cluster roles, if required, but you must take extra steps each time you restart a master node.

A project manager. If used in a local binding, an admin has rights to view any resource in the project and modify any resource in the project except for quota.

A user that can get basic information about projects and users.

A super-user that can perform any action in any project. When bound to a user with a local binding, they have full control over quota and every action on every resource in the project.

A user that can get basic cluster status information.

A user that can modify most objects in a project but does not have the power to view or modify roles or bindings.

A user that can create their own projects.

A user who cannot make any modifications, but can see most objects in a project. They cannot view or modify roles or bindings.

The relationships between cluster roles, local roles, cluster role bindings, local role bindings, users, groups and service accounts are illustrated below.

6.1.2. Evaluating authorization

OpenShift Container Platform evaluates authorization by using:

The action you perform. In most cases, this consists of:

OpenShift Container Platform evaluates authorization by using the following steps:

Remember that users and groups can be associated with, or bound to, multiple roles at the same time.

Project administrators can use the CLI to view local roles and bindings, including a matrix of the verbs and resources each are associated with.

Cluster roles are roles defined at the cluster level but can be bound either at the cluster level or at the project level.

6.1.2.1. Cluster Role Aggregation

The default admin, edit, view, and cluster-reader cluster roles support cluster role aggregation, where the cluster rules for each role are dynamically updated as new rules are created. This feature is relevant only if you extend the Kubernetes API by creating custom resources.

6.2. Projects and namespaces

A Kubernetes namespace provides a mechanism to scope resources in a cluster. The Kubernetes documentation has more information on namespaces.

Namespaces provide a unique scope for:

Most objects in the system are scoped by namespace, but some are excepted and have no namespace, including nodes and users.

A project is a Kubernetes namespace with additional annotations and is the central vehicle by which access to resources for regular users is managed. A project allows a community of users to organize and manage their content in isolation from other communities. Users must be given access to projects by administrators, or if allowed to create projects, automatically have access to their own projects.

Each project scopes its own set of:

Pods, services, replication controllers, etc.

Rules for which users can or cannot perform actions on objects.

Quotas for each kind of object that can be limited.

Service accounts act automatically with designated access to objects in the project.

Cluster administrators can create projects and delegate administrative rights for the project to any member of the user community. Cluster administrators can also allow developers to create their own projects.

Developers and administrators can interact with projects the CLI or the web console.

6.3. Default projects

OpenShift Container Platform comes with a number of default projects, and projects starting with openshift- are the most essential to users. These projects host master components that run as pods and other infrastructure components. The pods created in these namespaces that have a critical pod annotation are considered critical, and the have guaranteed admission by kubelet. Pods created for master components in these namespaces are already marked as critical.

6.4. Viewing cluster roles and bindings

You can use the oc CLI to view cluster roles and bindings by using the oc describe command.

Prerequisites

Users with the cluster-admin default cluster role bound cluster-wide can perform any action on any resource, including viewing cluster roles and bindings.

Procedure

To view the cluster roles and their associated rule sets:

To view the current set of cluster role bindings, which shows the users and groups that are bound to various roles:

6.5. Viewing local roles and bindings

You can use the oc CLI to view local roles and bindings by using the oc describe command.

Prerequisites

Obtain permission to view the local roles and bindings:

Procedure

To view the current set of local role bindings, which show the users and groups that are bound to various roles for the current project:

6.6. Adding roles to users

You can use the oc adm administrator CLI to manage the roles and bindings.

Binding, or adding, a role to users or groups gives the user or group the access that is granted by the role. You can add and remove roles to and from users and groups using oc adm policy commands.

You can bind any of the default cluster roles to local users or groups in your project.

Procedure

Add a role to a user in a specific project:

For example, you can add the admin role to the alice user in joe project by running:

View the local role bindings and verify the addition in the output:

For example, to view the local role bindings for the joe project:

6.7. Creating a local role

You can create a local role for a project and then bind it to a user.

Procedure

To create a local role for a project, run the following command:

In this command, specify:

For example, to create a local role that allows a user to view pods in the blue project, run the following command:

To bind the new role to a user, run the following command:

6.8. Creating a cluster role

You can create a cluster role.

Procedure

To create a cluster role, run the following command:

In this command, specify:

, the resources that the role applies to

For example, to create a cluster role that allows a user to view pods, run the following command:

6.9. Local role binding commands

You can use the following commands for local RBAC management.

Table 6.1. Local role binding operations

$ oc adm policy who-can

Indicates which users can perform an action on a resource.

$ oc adm policy add-role-to-user

Binds a specified role to specified users in the current project.

$ oc adm policy remove-role-from-user

Removes a given role from specified users in the current project.

$ oc adm policy remove-user

Removes specified users and all of their roles in the current project.

$ oc adm policy add-role-to-group

Binds a given role to specified groups in the current project.

$ oc adm policy remove-role-from-group

Removes a given role from specified groups in the current project.

$ oc adm policy remove-group

Removes specified groups and all of their roles in the current project.

6.10. Cluster role binding commands

Table 6.2. Cluster role binding operations

$ oc adm policy add-cluster-role-to-user

Binds a given role to specified users for all projects in the cluster.

$ oc adm policy remove-cluster-role-from-user

Removes a given role from specified users for all projects in the cluster.

$ oc adm policy add-cluster-role-to-group

Binds a given role to specified groups for all projects in the cluster.

$ oc adm policy remove-cluster-role-from-group

Removes a given role from specified groups for all projects in the cluster.

6.11. Creating a cluster admin

The cluster-admin role is required to perform administrator level tasks on the OpenShift Container Platform cluster, such as modifying cluster resources.

Prerequisites

Источник

Подходы к контролю доступа: RBAC vs. ABAC

В этой теме хотелось бы познакомить читателей с относительно новым подходом к контролю доступа под названием Attribute-based access control. Знакомство будет происходить на примере сравнения с популярным нынче Role-based access control.

Когда компания состоит из одного человека, то внутренних секретов в ней нет. Единственному сотруднику доступны любые действия и любая информация.

Если компания успешна и объемы работы растут, то наступает момент, когда один человек перестает справляться. И тогда в компанию нанимаются новые сотрудники.

Но когда число сотрудников в компании увеличивается, появляются другие проблемы, например:

Самой сложной является проблема авторизации. Существует несколько подходов к ее решению, но наибольшее распространение на сегодняшний день получил контроль на основе ролей (role-based access control, RBAC).

Role-based access control (RBAC)

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

Если бизнес-правила одномерны и все действия можно разбить по ролям (бухгалтер, менеджер, администратор и т. п.), такого подхода будет достаточно. Тогда одному бизнес-правилу будет соответствовать одна роль.

Но бизнес-правила неизбежно усложняются и становятся многомерными. Это приводит к тому, что одного атрибута (роли) для выражения бизнес-правил становится недостаточно и начинают добавляться другие атрибуты (город, страна, филиал, день недели, владелец, лимит и т. п.).

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

После каждого добавления нового значения атрибута придется добавлять новые роли. То есть если появится филиал «Г», то придется добавить новые роли, такие как «Администратор филиала «Г», «Менеджер филиала «Г», «Бухгалтер филиала «Г» и т. п., после чего присвоить всем требуемым сотрудникам новые роли. Все это порождает много рутинного ручного труда.

Кроме этого, появляются и другие проблемы:

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

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

Attribute-based access control (ABAC)

Чтобы справиться с нерешаемыми в рамках RBAC проблемами, был создан другой подход, который основывается на атрибутах.
Основное отличие этого подхода в том, что каждая ситуация оценивается не с точки зрения роли пользователя и действия, которое он хочет совершить, а с точки зрения атрибутов, которые к ним относятся.

Бизнес-правило, по сути, представляет собой набор условий, в которых различные атрибуты должны удовлетворять предъявляемым к ним требованиям.

Можно явно выделить несколько категорий атрибутов.

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

Простые правила описываются простыми условиями.

Многомерные правила в этой модели не становятся более сложными.

При добавлении новых значений атрибутов условия бизнес-правила меняться не будут. То есть если появится филиал «Г», в условиях бизнес-правила ничего менять не придется. Все, что потребуется, — это добавить нужным сотрудникам значение атрибута «Филиал» — «Филиал «Г».

Таким образом, ABAC позволяет избежать проблем, которые появляются в RBAC:

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

Первые три условия можно проверить еще до обращения к данным. А последнее условие можно использовать в качестве предиката для получения только разрешенных данных.

Сравнение ABAC и RBAC

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

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

P. S.: На сегодняшний день для ABAC существует стандарт XACML, который активно развивается и используется. Подробнее о нем можно узнать в следующей статье.

Источник

OpenShift как корпоративная версия Kubernetes

«В чем разница между Kubernetes и OpenShift?» – этот вопрос возникает с завидным постоянством. Хотя на самом деле это все равно что спрашивать, чем автомобиль отличается от двигателя. Если продолжить аналогию, то автомобиль – это готовый продукт, им можно пользоваться сразу же, буквально: сел и поехал. С другой стороны, чтобы двигатель вас куда-то повез, его сначала надо дополнить массой других вещей, чтобы в итоге получить все тот же автомобиль.

Поэтому Kubernetes – это такой двигатель, вокруг которого собран автомобиль (платформа) марки OpenShift, который и везет вас к цели.

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

OpenShift – это Kubernetes со 100% сертификацией от фонда CNCF

В основе OpenShift лежит сертифицированный Kubernetes. Поэтому после соответствующего обучения пользователи восхищаются мощью kubectl. А те, кто перешел на OpenShift с Kubernetes Cluster, часто говорят, как им очень нравится, что после перенаправления kubeconfig на кластер OpenShift, все имеющиеся скрипты работают безупречно.

Вы наверняка слышали про OpenShift’овскую утилиту командной строки под названием OC. Она полностью совместима по командам с kubectl, плюс, предлагает несколько полезных helper’ов, которые пригодятся при выполнении целого ряда задач. Но вначале чуть подробнее о совместимости OC и kubectl:

Вот как выглядят результаты использования kubectl на OpenShift API:

• kubectl get pods – вполне ожидаемо возвращает pod’ы.

• kubectl get namespaces – вполне ожидаемо возвращает пространства имен.

Иначе говоря, все Kubernetes’овские API полностью доступны в OpenShift с сохранением 100% совместимости. Именно поэтому OpenShift признан сертифицированной Kubernetes-платформой фондом Cloud Native Computing Foundation (CNCF).

OpenShift дополняет Kubernetes полезными функциями

Kubernetes’овские API на 100% доступны в OpenShift, но вот штатной Kubernetes’овской утилите kubectl явно не достает функциональности и удобства. Поэтому Red Hat дополнил Kubernetes полезными функциями и инструментами командной строки, такими как OC (сокращение от OpenShift client) и ODO (OpenShift DO, эта утилита предназначена для разработчиков).

1. Утилита OC – более мощный и удобный вариант Kubectl

Например, в отличие от kubectl, она позволяет создавать новые пространства имен и легко переключать контекст, а также предлагает ряд полезных команд для разработчиков, например, для сборки контейнерных образов и развертывания приложений непосредственно из исходного кода или двоичных файлов (Source-to-image, s2i).

Давайте на примерах рассмотрим, как встроенные helper’ы и расширенная функциональность утилиты OC помогают упростить повседневную работу.

Пример первый – управление пространствами имен. В каждом кластере Kubernetes всегда есть несколько пространств имен. Обычно они используются для создания девелоперских и продакшн-окружений, но могут применяться и для того, чтобы, например, выдавать каждому разработчику персональную «песочницу». На практике это приводит к тому, что разработчику приходится часто переключаться между пространствами имен, поскольку kubectl работает в контексте текущего пространства. Поэтому в случае с kubectl народ активно применяет для этого helper-скрипты. А вот при использовании OC для переключения на нужное пространство достаточно сказать “oc project пространство_имен”.

Не помните, как называется нужное пространство имен? Не проблема, просто введите “oc get projects”, чтобы вывести на экран полный список. Скептически интересуетесь, как это сработает, если у вас есть доступ только к ограниченному подмножеству пространств имен на кластере? Ну, потому что kubectl делает это корректно, только если RBAC разрешает вам видеть все пространства на кластере, а в больших кластерах такие полномочия выдают далеко не всем. Так вот, отвечаем: для OC это вообще не проблема и она легко выдаст в такой ситуации полный список. Вот из таких мелочей и складывается корпоративная ориентированность Openshift и хорошая масштабируемость этой платформы в плане пользователей и приложений

2. ODO – улучшенная версия kubectl для разработчиков

В качестве еще одного примера улучшений Red Hat OpenShift по сравнению с Kubernetes можно привести утилиту командной строки ODO. Она предназначена для разработчиков и позволяет быстро развертывать локальный код на удаленном кластере OpenShift. Кроме того, с ее помощью можно оптимизировать внутренние процессы, чтобы мгновенно синхронизировать все изменения кода с контейнерами на удаленном кластере OpenShift без того, чтобы заново выполнять сборку, размещение в реестре и повторное развертывание образов.

Давайте посмотрим, как OC и ODO облегчает работу с контейнерами и Kubernetes.

Просто сравним парочку рабочих процессов, когда они строятся на основе kubectl, и когда применяются OC или ODO.

• Развертывание кода на OpenShift для тех, кто не владеет языком YAML:

• Переключение контекста: смена рабочего пространства имен или рабочего кластера.

Контроль качества: «Тут появилась одна интересная функция, пока в альфа-версии. Может введем ее в продакшн?»

Представьте, что вас усаживают в гоночный болид и говорят: «Мы тут поставили тормоза нового типа и, честно говоря, у них пока не все в порядке с надежностью… Но ты не переживай, будем их активно дорабатывать прямо по ходу чемпионата». Как вам такая перспектива? Нам в Red Hat как-то не очень. 🙂

Поэтому мы стараемся воздерживаться от альфа-версий до тех пор, пока они в достаточной мере не созреют, и мы не проведем тщательное боевое тестирование и не почувствуем, что их можно безопасно использовать. Обычно у нас всё проходит сначала через стадию Dev Preview, затем через Tech Preview и только потом выходит в виде общедоступного релиза General Availability (GA), который стабилен уже настолько, что годится в продакшн.

Почему так? Потому что, как и при разработке любого другого софта, далеко не все первоначальные задумки в Kubernetes доходят до финального релиза. Или доходят, и даже сохраняют задуманную функциональность, но их реализация кардинально отличается от той, что была в альфа-версии. Поскольку тысячи и тысячи клиентов Red Hat применяют OpenShift для поддержки критически важных задач, мы делаем особый упор на стабильности нашей платформы и на долговременной поддержке.

Red Hat целенаправленно выпускает частые релизы OpenShift и обновляет входящую в ее состав версию Kubernetes. Например, в текущий на момент написания этой статьи GA-релиз OpenShift 4.3 встроен Kubernetes 1.16, который всего на единичку отстает от upstream-версии Kubernetes с номером 1.17. Таким образом мы стараемся дать заказчику Kubernetes корпоративного класса и обеспечить дополнительный контроль качества в процессе выпуска новых версий OpenShift.

Программные исправления: «В той версии Kubernetes, которая у нас в продакшн, нашлась дыра. И закрыть ее можно только обновлением на три версии вверх. Или есть варианты?»

В рамках открытого проекта Kubernetes программные исправления обычно выходят в составе следующего релиза, иногда они охватывают один или два предыдущих промежуточных релиза, что дает охват всего на 6 месяцев назад.

Red Hat по праву гордится тем, что выпускает критические исправления раньше других и обеспечивает поддержу на гораздо больший срок. Возьмем, к примеру, уязвимость с эскалацией привилегий в Kubernetes (CVE-2018-1002105): она обнаружилась в Kubernetes 1.11, а исправления для предыдущих релизов выпустили только до версии 1.10.11, оставив эту в дыру во все предыдущие релизах Kubernetes, с 1.x по 1.9.

В свою очередь, Red Hat пропатчила OpenShift назад вплоть до версии 3.2 (там стоит Kubernetes 1.2), захватив девять релизов OpenShift и наглядно продемонстрировав заботу о клиентах (подробнее здесь).

Как OpenShift и Red Hat двигают вперед Kubernetes

Red Hat занимает второе место по размеру программного вклада в открытый проект Kubernetes, уступая здесь только Google, причем 3 из 5 самых плодовитых разработчиков являются сотрудниками Red Hat. Еще один малоизвестный факт: многие критически важные функции появились в Kubernetes именно по инициативе Red Hat, в частности, такие как:

Понятно, OpenShift – это Kubernetes. А различия-то в чём? 🙂

Надеемся, что, дочитав до этого места, вы уяснили, что Kubernetes –это основной компонент OpenShift. Основной, но далеко не единственный. Иначе говоря, просто установив Kubernetes, вы не получите платформу корпоративного класса. Вам надо будет добавить аутентификацию, сеть, безопасность, мониторинг, управление журналами и многое другое. Кроме того, придется сделать нелегкий выбор из большого количества доступных инструментов (чтобы оценить разнообразие экосистемы, просто гляньте диаграмму CNCF) и как-то обеспечить согласованность и слаженность, чтобы они работали как одно целое. Кроме того, вам регулярно придется выполнять обновление и регрессионное тестирование при выходе новой версии любого из используемых компонентов. То есть, помимо создания и сопровождения самой платформы, вам надо будет заниматься еще и всем этим софтом. Вряд ли тут останется много времени на решение бизнес-задач и достижение конкурентных преимуществ.

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

Взгляните на рисунок выше: всё, что находится вне прямоугольника Kubernetes, – это те области, где Red Hat добавляет функционал, которого в Kubernetes нет, что называется, by-design. И сейчас мы рассмотрим основные из этих областей.

1. Надежная ОС в качестве основы: RHEL CoreOS или RHEL

Red Hat уже более 20 лет является ведущим поставщиком Linux-дистрибутивов для критически важных бизнес-приложений. Наработанный и постоянно обновляемый в этой области опыт позволяет нам предложить по-настоящему надежную и доверенную основу для промышленной эксплуатации контейнеров. RHEL CoreOS использует то же ядро, что и RHEL, но оптимизирована прежде всего для таких задач, как выполнение контейнеров и работа в кластерах Kubernetes: ее уменьшенный размер и неподверженность изменениям (immutability) упрощает установку кластеров, автомасштабирование, развертывание исправлений и т. д. Все эти функции делают ее идеальной основой для получения одного и того же пользовательского опыт при работе с OpenShift в самых разных вычислительных средах, от «голого железа» до частного и публичного облака.

2. Автоматизация ИТ-операций

Автоматизация процессов установки и операций второго дня (то есть повседневной эксплуатации) – это конек OpenShift, которые значительно облегчает администрирование, обновление и поддержание работы контейнерной платформы на высочайшем уровне. Это достигается за счет поддержки Kubernetes-операторов на уровне ядра OpenShift 4.

OpenShift 4 – это также и целая экосистема решений на основе Kubernetes-операторов, разработанных как самой Red Hat, так и сторонними партнерами (см. каталог операторов Red Hat, или магазин операторов operatorhub.io, созданный Red Hat для сторонних разработчиков).

В состав интегрированного каталога OpenShift 4 входит более 180 Kubernetes-операторов

3. Инструменты для разработчиков

Начиная с 2011 года, OpenShift доступна в виде платформы PaaS (Platform-as-a-Service), которая значительно упрощает жизнь разработчикам, помогает им сосредоточиться на создании кода и предлагает встроенную поддержки таких языков программирования, как Java, Node.js, PHP, Ruby, Python, Go, а также сервисы непрерывной интеграции и доставки CI/CD, базы данных и т. п. OpenShift 4 предлагает обширный каталог, включающий более 100 сервисов на основе Kubernetes-операторов, разработанных Red Hat и нашими партнерами.

В отличие от Kubernetes, в OpenShift 4 есть специальный графический интерфейс (Developer Console), помогающий разработчикам без лишних усилий развертывать в своих пространствах имен приложения из различных источников (git, внешние реестры, Dockerfile и т. д) и наглядно визуализирующий связи между компонентами приложения.

Кроме того, OpenShift предлагает набор инструментов разработки Codeready, куда, в частности, входит Codeready Workspaces, полностью контейнеризированная IDE с веб-интерфейсом, работающая непосредственно поверх OpenShift и реализующая подход «IDE-как сервис». С другой стороны, для тех, кто хочет работать строго в локальном режиме, есть Codeready Containers – полнофункциональная версия OpenShift 4, которую можно развернуть на ноутбуке.

Интегрированная «IDE как сервис» для эффективной разработки на платформе Kubernetes/OpenShift

Прямо из коробки OpenShift предлагает полноценную систему CI/CD, либо на основе контейнеризованного Jenkins и плагина DSL для работы с конвейерами, либо ориентированную на Kubernetes CI/CD-систему Tekton (пока в версии Tech preview). Оба этих решения полностью интегрируются с консолью OpenShift, позволяя запускать триггеры конвейеров, просматривать развертывания, журналы и т. д.

4. Инструменты для приложений

OpenShift позволяет развертывать как традиционные stateful-приложения, так и облачно-ориентированные решения на базе новых архитектур, вроде микросервисов или serverless. Решение OpenShift Service Mesh прямо из коробки ключевые для сопровождения микросервисов инструменты, как Istio, Kiali и Jaeger. В свою очередь, решение OpenShift Serverless включает в себя не только Knative, но и созданные в рамках совместной с Microsoft инициативы инструменты вроде Keda для предоставления функций Azure на платформе OpenShift.

Интегрированное решение OpenShift ServiceMesh (Istio, Kiali, Jaeger) пригодится при разработке микросервисов

Чтобы сократить разрыв между унаследованными приложениями и контейнерами, OpenShift теперь позволяет провести миграцию виртуальных машин на платформу OpenShift с помощью Container Native Virtualization (пока в версии в TechPreview), превращая гибридные приложения в реальность и облегчая их перенос между различными облака, как частными, так и публичными.

Виртуальная машина Windows 2019 Virtual, запущенная на OpenShift через Container Native Virtualization (пока в версии Tech preview)

5. Инструменты для кластеров

У любой платформы корпоративного класса должны быть сервисы мониторинга и централизованного ведения логов, механизмы безопасности, аутентификации и авторизация, средства сетевого управления. И OpenShift предоставляет всё это из коробки, причем всё это на 100% открытый код, включая такие решения как ElasticSearch, Prometheus, Grafana. Все эти решения идут в комплекте с информационными панелями, метриками и оповещениями, которые уже скомпонованы и настроены с учетом обширного опыта Red Hat в области мониторинга кластеров, что позволяет с первых же минут эффективно контролировать и отслеживать работу вашей продакшн-среды.

В OpenShift также штатно имеет такие важные для корпоративного заказчика вещи, как аутентификация со встроенным провайдером oauth, интеграция с провайдерами учетных данных, включая LDAP, ActiveDirectory, OpenID Connect, и многое другое.

Предварительно настроенная информационная панель Grafana для мониторинга кластера OpenShift

Более 150 предварительно настроенных метрик и оповещений Prometheus для мониторинга кластера OpenShift

Продолжение следует

Богатый функционал решения и обширный опыт Red Hat в области Kubernetes – именно по этим причинам OpenShift занял доминирующее положение на рынке, как показано на рисунке ниже (подробнее здесь).

«На текущий момент Red Hat лидирует на рынке с долей в 44 %.
Компания пожинает плоды своей стратегии продаж с активным участием в делах клиента, в рамках которой она вначале консультирует и обучает корпоративных разработчиков, а затем переходит к монетизации по мере того, как предприятие начинает внедрять контейнеры в продакшн».

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

Источник