Это проект, стартовавший в 2016 году, направленный на унификацию применения политик в различных технологиях и системах. Сегодня OPA используется гигантскими игроками в технологической индустрии. Например, Netflix использует OPA для управления доступом к своим внутренним ресурсам API. Chef использует его для предоставления возможностей IAM в своих продуктах для конечных пользователей. Кроме того, многие другие компании, такие как Cloudflare, Pinterest и другие, используют OPA для обеспечения соблюдения политик на своих платформах (например, кластеры Kubernetes). В настоящее время OPA является частью CNCF в качестве инкубационного проекта. Вы можете спросить: как возникла OPA? Какие проблемы пытается решить? Действительно, применение политик в отношении API и микросервисов так же старо, как и сами микросервисы. Никогда не было приложения production уровня, которое не обеспечивало бы какой-либо контроль доступа, авторизацию и применение политик. Чтобы понять роль OPA, рассмотрим следующий вариант использования: ваша компания продает ноутбуки через онлайн-портал. Как и все другие подобные приложения, портал состоит из главной страницы, где клиенты видят последние предложения, возможно, некоторые ограниченные по времени рекламные акции. Если клиенты хотят что-то купить, им необходимо войти в систему или создать учетную запись. Затем они осуществляют платежи с помощью своих кредитных карт или другими способами. Чтобы ваши клиенты постоянно посещали вас, вы предлагаете им подписаться на вашу рассылку новостей, которая может содержать специальные скидки. Кроме того, они могут выбрать получение уведомлений браузера, как только будут объявлены новые продукты. Типичное приложение для онлайн-покупок, не так ли? Теперь давайте изобразим, как этот рабочий процесс будет выглядеть на диаграмме, чтобы визуализировать процесс:  На диаграмме выше показано, как наша система может выглядеть внутри. У нас есть ряд микросервисов, которые взаимодействуют друг с другом для обслуживания наших клиентов. Теперь очевидно, что Боб не должен видеть никаких внутренних механизмов работы системы. Например, он не может просматривать (или даже знать) корзину S3, в которой архивируются платежи, или с какими службами может взаимодействовать API уведомлений. Но как насчет Джона? Он один из наших разработчиков приложений, и ему нужен доступ ко всем микросервисам, чтобы иметь возможность устранять неполадки и отлаживать их при возникновении проблем. Или он? Что, если он случайно (или намеренно) вызовет API-интерфейс службы базы данных, чтобы изменить адрес доставки клиента на другое место? Хуже того, что, если бы у него были разрешения на чтение номеров кредитных карт клиентов? Чтобы устранить эти риски, мы размещаем элемент управления авторизацией поверх каждого из наших микросервисов. Элемент управления проверяет, имеет ли аутентифицированный пользователь необходимые привилегии для выполнения запрошенной операции. Такая система авторизации может быть внутренним, собственным процессом или внешним, как это предусмотрено AWS IAM. Так создается и защищается типичное приложение для микросервисов. Но посмотрите на недостатки использования нескольких разных систем авторизации, особенно по мере роста приложения: Давайте посмотрим на Kubernetes в качестве примера. Если бы всем пользователям был разрешен доступ ко всему кластеру, может произойти множество неприятных вещей, таких как: Конечно, вы можете использовать RBAC и политики безопасности Pod для детального контроля над кластером. Но опять же, это применимо только к кластеру. Kubernetes RBAC бесполезен, кроме как в кластере Kubernetes. Вот где в игру вступает Open Policy Agent (OPA). OPA был введен для создания унифицированного метода обеспечения соблюдения политики безопасности в стеке. Ранее мы исследовали стратегии обеспечения соблюдения политик и то, что OPA пытается решить, — это показало нам, «что». А теперь давайте посмотрим, «как». Допустим, вы внедряете платежную службу нашего примера приложения. Эта служба отвечает за обработку платежей клиентов. Он предоставляет API, в котором принимает оплату от клиента. Это также позволяет пользователю запрашивать, какие платежи были произведены конкретным клиентом. Итак, чтобы получить массив, содержащий покупки, сделанные Джейн, которая является одним из клиентов компании, вы отправляете запрос GET в API с путем / payment / jane. Вы указываете свои учетные данные в заголовке авторизации и отправляете запрос. Ответом будет массив JSON с запрошенными вами данными. Однако, поскольку вы не хотите, чтобы кто-либо, имеющий доступ к сети, имел доступ к Payments API для просмотра таких конфиденциальных данных, вам необходимо применить политику авторизации. OPA решает проблему следующим образом: Здесь важно отметить, что OPA отделяет наше решение о политике от применения политики. Рабочий процесс OPA можно изобразить на следующей диаграмме:  OPA — это универсальный инструмент принудительного применения политик, не зависящий от домена. Он может быть интегрирован с API, демоном SSH Linux, хранилищем объектов, таким как CEPH, и т. Д. Разработчики OPA намеренно избегали основывать его на каком-либо другом проекте. Соответственно, запрос политики и решение не следуют конкретному формату. То есть вы можете использовать любые допустимые данные JSON в качестве атрибутов запроса, если они предоставляют необходимые данные. Точно так же решение политики, исходящее от OPA, также может быть любыми действительными данными JSON. Вы выбираете, что вводится, а что выводится. Например, вы можете выбрать, чтобы OPA возвращал объект JSON True или False, число, строку или даже сложный объект данных. Чтобы полностью понять OPA и начать применять его в своих проектах, вы должны ознакомиться с его функциями и компонентами. Начнем с того, как вы определяете свою политику. Rego — это декларативный язык высокого уровня, созданный специально для OPA. Это упрощает определение политик и ответы на такие вопросы, как: разрешено ли Бобу выполнять GET-запрос на /api/v1/products? Какие записи ему разрешено просматривать? Когда дело доходит до развертывания OPA, у вас есть несколько вариантов в зависимости от вашего конкретного сценария:  Чтобы еще больше уменьшить задержку, разработчики решили, что OPA должен хранить все данные политики в памяти. Это гарантирует, что OPA не будет запрашивать данные у другой службы. Для работы с OPA у вас есть набор API, которые служат для разных целей: К настоящему времени у вас должно быть довольно четкое представление о том, почему появился OPA, проблемы, которые он пытается решить, и как он был спроектирован и решен. Пришло время проверить воду и посмотреть, каково это — создавать политику на языке Rego. Первый шаг — сформулировать свою политику на простом английском языке. Например: «Клиенты должны иметь возможность просматривать свои собственные платежи. Сотрудники финансового отдела должны иметь возможность просматривать любые платежи клиентов». Следующим шагом будет преобразование политики в код Rego. Для этого мы можем использовать Rego. Итак, на главной панели очистите код, который уже был добавлен туда, и добавьте следующее: Давайте рассмотрим этот фрагмент построчно: Если бы мы перевели этот код обратно на простой язык, это выглядело бы примерно так:
«Разрешите запрос, если он использует метод GET, путь — /payments/customer_id, а пользователь — тот же customer_id. Что эффективно позволяет клиенту просматривать свои собственные платежные данные ». Rego также позволяет вам оценить ваш код и убедиться, что политика работает должным образом. В панели INPUT мы можем подделать законный запрос, добавив следующий код: Обратите внимание, что INPUT использует произвольный JSON. Нет никаких особых правил, которым нужно следовать при отправке запроса. Теперь давайте посмотрим, как OPA ответит на этот запрос о решении, нажав кнопку Evaluate. На панели OUTPUT должно отображаться следующее: Ниже приведен снимок экрана площадки после выполнения вышеуказанных действий:  Теперь давайте попробуем изменить пользователя в запросе на alice, что означает, что клиент пытается просмотреть платежи другого клиента. Если мы нажмем Evaluate, вы заметите, что на выходе отображается пустой объект JSON {}. Причина в том, что OPA не знает, что отправлять, если политика не соответствует. Чтобы изменить это поведение, добавьте следующий оператор перед телом политики: Итак, вся политика должна выглядеть так: Теперь, если вы нажмете Evaluate, вы увидите ожидаемый результат: Обратите внимание, что Rego настолько мощна, что вы можете выбирать части политики и оценивать ее независимо от остальной политики. Это может быть очень полезно, когда у вас сложная политика, которая дает ложную оценку, хотя этого не должно быть. В этом случае вы можете выбрать части политики и посмотреть, где именно возникает ошибка. Хорошо, теперь, когда мы выполнили первую часть нашей политики, давайте перейдем ко второй части: сотрудники финансового отдела должны иметь возможность просматривать любые платежи клиентов. Добавьте следующие строки после политики, которую мы определили ранее: Сотрудники финансового отдела могут просматривать любые платежи клиентов Большая часть этой политики похожа на предыдущую, за исключением строки 4. Вместо оценки того, совпадает ли идентификатор пользователя с идентификатором клиента, мы оцениваем, является ли пользователь частью финансового объекта JSON. Rego имеет множество встроенных конструкций, которые позволяют делать много полезных вещей, включая поиск. Наконец, мы определяем финансовый объект и добавляем имена пользователей для сотрудников, работающих в этой группе. В реальном сценарии этот объект JSON будет передаваться как часть запроса INPUT или как токен. Теперь давайте протестируем политику, задав для пользователя и клиента одно и то же имя (например, bob). Политика должна возвращать истину. Измените пользователя на john (который работает в финансовом отделе) и протестируйте политику. Опять же, он должен вернуть истину. Наконец, измените имя пользователя на любое имя, которое не работает в финансовом отделе (скажем, Джейн), и политика должна вернуть false. Вы можете узнать больше о языке Rego и о том, что с ним делать, обратившись к официальной документации. Как упоминалось ранее, OPA можно интегрировать со многими современными платформами. Давайте посмотрим на несколько примеров того, что OPA может для вас сделать: Есть также много других продуктов, которые можно интегрировать с OPA, чтобы предоставить безграничные возможности. Например, Kafka, ElasticSearch, SQLite и CEPH и многие другие. Немного рекламы: На платформе https://rotoro.cloud/ вы можете найти курсы с практическими занятиями: DevOps-инженер