Контроль доступа для нескольких команд в Redpanda Agentic Data Plane

Большое внимание в Redpanda Agentic Data Plane уделяется управлению самими агентами с помощью политик данных и средств защиты. Но как насчет управления самой платформой, чтобы все ваше предприятие могло использовать ее в качестве центрального места для запуска агентов? В этой статье показано, как несколько команд могут совместно использовать одно развертывание с гибкими границами для каждой команды, охватывающими все типы ресурсов на платформе.

Эти границы должны способствовать движению команд вперед, а не замедлять их, поскольку главная цель — это самообслуживание: команда должна иметь возможность создавать и выпускать собственные агенты без отправки заявок команде платформы. Самообслуживание на каждом предприятии понимается по-своему, поэтому модель доступа должна быть достаточно гибкой. Если пренебречь этой гибкостью, пользователи найдут другие способы запуска своих агентов, подорвав безопасность и управляемость, которые должна обеспечивать платформа.

Эта цель сводится к трем требованиям:

• Детализация: установите границы для ресурсов каждой команды и научитесь отличать агента в разработке от такого же агента в рабочей среде (production).
• Гибкость: выпускайте агента или добавляйте нового без необходимости переписывать правила доступа.
• Масштабируемость: сохраняйте работоспособность по мере роста числа команд и агентов.

Подход прост: политики могут считывать любой тег, присвоенный ресурсу, поэтому вы сами решаете, какие факты о ресурсе контролируют доступ к нему. В этой статье показан один из способов реализации: тег команды (team) для определения владельца каждого ресурса, тег этапа (stage) для статуса выпуска агента, тег роли (persona) для задач каждой команды и небольшой набор политик, считывающих эти теги. Мы рассмотрим, как модель авторизации отвечает трем вышеуказанным требованиям, а затем разберем решения, которые необходимо принять перед написанием политики.

Чтобы сделать это нагляднее, мы рассмотрим пример с тремя командами. Команда платформы управляет развертыванием и владеет общим провайдером больших языковых языковых моделей (LLM). Команда бухгалтерии создает агента для обработки счетов, который обращается к своей системе планирования ресурсов предприятия (ERP) через сервер Model Context Protocol (MCP) с именем erp. Команда поддержки создает агента-помощника по возвратам на собственном сервере MCP для работы с тикетами. Мы покажем готовую модель и то, как она меняется, когда команде требуется собственный провайдер или доступ к серверу другой команды.

Как Redpanda Agentic Data Plane определяет, кто и что может делать

Redpanda Agentic Data Plane построена на основе модели контроля доступа на основе атрибутов (ABAC). Вы помечаете каждый ресурс несколькими атрибутами и пишете политики на языке политик Cedar, которые считывают эти теги при поступлении запроса. Политика, утверждающая, что «команда бухгалтерии может вызывать агентов с тегом team=accounting», распространяется на каждого агента с таким тегом, включая те, которые еще не существуют.

Политика Cedar представляет собой инструкцию разрешить (permit) или запретить (forbid), состоящую из трех обязательных частей и одной необязательной:

• Субъект (Principal): кто делает запрос. Пользователь, группа из вашего провайдера идентификации (IdP) или агент.
• Действие (Action): что они пытаются сделать, например Agent.invoke или McpServer.create.
• Ресурс (Resource): по отношению к чему это делается. Агент, сервер MCP, провайдер LLM и так далее.
• Условия (Conditions): предложение when для правила и предложение unless для исключений.

Везде действуют два правила оценки:

• Запрос отклоняется, если ему не соответствует ни одно разрешение.
• Соответствующее правило запрета отменяет любое разрешение.

Вот как выглядит политика. Это политика, которая дает команде бухгалтерии контроль над собственными агентами:

Перевод политики на человеческий язык:

• Субъект: любой участник группы IdP accounting.
• Действие: создание, получение, перечисление, вызов и обновление агентов.
• Ресурс: привязан к типу Agent.
• Условие: агент имеет тег team=accounting. Проверка hasTag выполняется первой, поскольку чтение тега, которого у ресурса нет, в Cedar считается ошибкой оценки, а не ложным значением (false).

При создании или обновлении условие проверяется для ресурса в том виде, в каком он будет существовать после вызова. Пользователю из бухгалтерии, который пытается создать агента с тегом team=support или вообще без тега команды, будет отказано. Политика обеспечивает соблюдение правила тегирования без необходимости ручной проверки. Один из случаев требует дополнительной политики, которая рассматривается в разделе с запретами далее в статье.

Ресурсы, которыми вы управляете

Каждый запрос в Redpanda Agentic Data Plane авторизуется на основе политик доступа, подобных приведенной выше. Ресурсы, которыми управляют эти политики:

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

Рекомендации по проектированию: что нужно каждой команде для выполнения своей работы?

Модель доступа начинается с вопросов о людях, а не о Cedar. Для каждой команды, которая будет использовать платформу, вам нужно определить, что они должны уметь делать, сопоставить это с типами ресурсов выше, а затем выразить это с помощью тегов.

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

Кто является субъектами и где хранятся данные о членстве в группах?

Redpanda Agentic Data Plane считывает членство в группах из вашего IdP во время запроса, что делает IdP единственным местом управления членством в командах. Когда кто-то присоединяется к бухгалтерии, его добавляют в группу, и доступ предоставляется автоматически.

Это означает, что значения тегов ваших команд должны совпадать с именами групп в IdP вплоть до написания. Политика сравнивает строки, поэтому Accounting и accounting — это две разные команды.

Ресурс содержит один тег команды. Человек может состоять в нескольких группах и получает разрешения всех их них. Тот, кто состоит одновременно в accounting и support, может создавать и выпускать релизы для любой из команд, что обычно и требуется для инженера, работающего на несколько команд, но об этом стоит знать перед добавлением человека во вторую группу.

В нашем примере тег команды имеет три возможных значения: platform, accounting и support; по одному для каждой группы IdP.

Какие теги нужны модели?

Тег команды проводит границы между командами. Любой другой факт о ресурсе, на который должна реагировать политика, также может быть тегом. Наша модель использует еще два.

shared=true обозначает ресурс, который может использовать любая команда. Команда платформы добавляет его к провайдеру LLM, и одна политика разрешает get, list и invoke для любого провайдера с этим тегом для всех пользователей. Когда команда платформы добавляет второго общего провайдера, она помечает его тегом, и та же политика начинает охватывать его.

stage задает жизненный цикл релиза. Каждый агент находится либо в разработке (dev), либо в production (prod). В режиме dev вызывать агента может только создатель. Для этого требуется один запрет с исключением для создателя, который Redpanda Agentic Data Plane передает политикам как created_by. Это ограничение распространяется и на товарищей по команде самого создателя, поэтому агент в dev остается приватным для своего разработчика до момента выпуска. В prod вызывать его могут все.

Выпуск агента означает изменение значения тега с dev на prod. Любой участник команды-владельца может сделать это, не обращаясь к платформенной команде с просьбой изменить политику. Если вам нужен этап проверки перед выпуском, запрет на изменение тега стадии может зарезервировать это действие для группы проверяющих. Тег команды работает иначе. Команды не могут его изменить, поскольку запрет резервирует это изменение за платформенной командой. В разделе «Запреты» ниже объясняется, почему.

Сопоставление каждой команды с персоной

Начинайте с персон, а не с команд. Персона — это тип пользователя, определяемый тем, что ему нужно делать. Определите персоны, которые есть на вашей платформе, опишите потребности каждой из них, используя справочник действий Redpanda Agentic Data Plane в качестве словаря, а затем сопоставьте каждую команду с одной из них. В нашей примерной модели их три:

• Оператор: все действия с любым ресурсом. Это единственная персона, которая может создавать, обновлять или удалять политики, потому что тот, кто может изменить политику, может изменить любую другую политику.
• Разработчик (Builder): создание, получение, перечисление, обновление и вызов собственных агентов; создание, получение, перечисление, обновление, инициализация и перечисление инструментов на собственных MCP-серверах; вызов инструментов на собственных серверах; а также получение, перечисление и вызов общих провайдеров LLM.
• Потребитель (Consumer): получение, перечисление и вызов агентов, выпущенных другими командами.

Платформенная команда сопоставляется с «Оператором», а команды бухгалтерии и поддержки — с «Разработчиком». «Потребитель» охватывает всех, включая людей, не входящих ни в одну группу команд, поэтому для него не требуется отдельная команда. Команде, которая использует только агентов, созданных другими командами, вообще не нужны политики команд.

Каждая команда «Разработчиков» получает по одной политике на каждый тип используемого ресурса: одну для своих агентов, одну для своих MCP-серверов и одну для инструментов на этих серверах. Инструменты получают свою собственную политику, потому что они являются подресурсом. MCP-сервер — это ресурс, который команда создает и к которому подключается, а инструменты, которые он предоставляет, находятся внутри него. Политика для сервера охватывает его создание, подключение к нему и перечисление его инструментов, но вызов инструмента — это действие, выполняемое непосредственно с инструментом.

Все три политики считывают тег команды, поэтому команда с тремя агентами и пятью MCP-серверами получает те же три политики, что и команда с одним агентом и одним сервером каждого типа. Предоставление команде доступа к другому типу ресурсов, например к секретам или бюджетам, добавляет одну политику для этого типа.

На диаграмме ниже показана результирующая модель. Ресурсы каждой команды находятся внутри ее собственной границы, а общий провайдер и политики доступа находятся у платформенной команды. Единственные линии, пересекающие границу, — это вызовы, разрешенные политиками.

Все ли команды выглядят одинаково?

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

Команда, работающая с регулируемыми данными, например бухгалтерия, может захотеть использовать собственного провайдера LLM по собственному контракту вместо общего. В этот момент бухгалтерия становится другим типом «Разработчика». Поддержка остается «Разработчиком» на общем провайдере. Бухгалтерия теперь является «Разработчиком» с частным провайдером, помеченным тегом team=accounting, который может использовать только она. Двум персонам нужны разные наборы политик: у бухгалтерии добавляется политика для своего провайдера, а у поддержки остается прежней.

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

Что нужно всем остальным?

Как только агент попадает в prod, любой пользователь должен иметь возможность найти его и запустить. Это означает получение, перечисление и вызов агентов с тегом stage=prod для любого принципала.

Обновление (update) в этот список не входит, поэтому каждый может использовать выпущенного агента, но только его команда может его изменить.

Что никому не должно быть позволено делать?

Три запрета удерживают модель вместе:

• Агенты dev остаются у своего создателя: all-dev-creator-only запрещает вызов любого агента с тегом stage=dev, если только вы его не создали.
• Никто не может использовать агента без тегов: запрет блокирует вызов любого агента, у которого отсутствует тег stage или team, поэтому агент, который забыли пометить, становится непригодным для использования, вместо того чтобы проскользнуть мимо правил dev и prod.
• Никто не может переместить ресурс в другую команду, изменив его тег: встроенная политика жизненного цикла владельца в Redpanda Agentic Data Plane позволяет тому, кто создал ресурс, продолжать обновлять его независимо от его тегов, поэтому без запрета создатель мог бы переместить своего агента в другую команду. Запрет на изменение тега команды закрывает эту возможность для всех, кроме платформенной команды:

changed_tags — это набор ключей тегов, которые обновление добавляет, удаляет или изменяет. Он существует только на пути обновления, поэтому создание и чтение остаются нетронутыми. Исключение называет платформенную команду вместо перечисления каждой команды разработчиков, поэтому новая команда охватывается без редактирования этой политики.

Управление политиками доступа не требует запрета. Запрос отклоняется, если только он не соответствует разрешению, а platform-full-access — единственная политика, которая предоставляет Policy.create, Policy.update или Policy.delete.

Обобщение политик для нашего примера модели доступа

Вам понадобится двенадцать политик доступа, чтобы создать модель, представленную на Диаграмме 1. Добавление агента или MCP-сервера, или выпуск агента не меняет этот набор. Новая команда или персона добавляет политики.

Группа платформы

• platform-full-access: все действия с любым ресурсом.

Группа бухгалтерии

• accounting-agents: создание, получение, перечисление, вызов и обновление агентов с тегом team=accounting.
• accounting-mcp: создание, получение, перечисление, обновление, инициализация и перечисление инструментов на MCP-серверах с тегом team=accounting.
• accounting-tool-calls: вызов инструментов на MCP-серверах с тегом team=accounting.

Группа поддержки

• support-agents: создание, получение, перечисление, вызов и обновление агентов с тегом team=support.
• support-mcp: создание, получение, перечисление, обновление, инициализация и перечисление инструментов на MCP-серверах с тегом team=support.
• support-tool-calls: вызов инструментов на MCP-серверах с тегом team=support.

Все пользователи

• all-shared-llm-use: получение, перечисление и вызов провайдеров LLM с тегом shared=true.
• all-prod-invoke: получение, перечисление и вызов агентов с тегом stage=prod.
• all-dev-creator-only: запрет на вызов агентов с тегом stage=dev, если только вы их не создали.
• all-untagged-deny: запрет на вызов агентов, у которых отсутствует тег stage или team.
• all-teams-cannot-change-team-tag: запрет всем, кроме платформенной команды, изменять тег команды.

Все, что не предоставлено этим списком или встроенной политикой жизненного цикла владельца Redpanda Agentic Data Plane, запрещено. Политика жизненного цикла владельца позволяет людям получать, обновлять и удалять то, что они создали. У бухгалтерии и поддержки нет разрешений на guardrails, бюджеты, секреты или политики доступа, поэтому они не могут их создавать или изменять, и ни для чего из этого не нужен запрет. Добавляйте запрет только тогда, когда вам нужно переопределить то, что в противном случае разрешило бы разрешение.

Сначала проектируйте, затем пишите политики

Управление общим развертыванием Redpanda Agentic Data Plane — это прежде всего упражнение по проектированию, а не по написанию политик. Решите, какие персоны обслуживает ваша платформа и что должна делать каждая из них. Выберите теги, которые выражают эти решения, со значениями team, соответствующими вашим группам IdP, плюс любые другие теги, такие как shared или stage, на которые должна реагировать политика. Затем напишите политики поверх этих тегов.

Выполненная в таком порядке, модель с самого начала отвечает трем требованиям. Она детализирована, поскольку тег команды проводит границу вокруг ресурсов каждой команды, а тег этапа отделяет агент разработки от производственного агента. Она гибкая, поскольку добавление или удаление агента — это изменение тега, а не изменение политики. Она масштабируема, поскольку количество политик растет вместе с командами и ролями, а не с количеством агентов. Команда платформы оставляет за собой изменения, требующие дополнительного рассмотрения, такие как создание новой команды или роли, либо предоставление доступа между командами, а команды самостоятельно справляются со всем остальным.

Чтобы настроить подобную модель для своих команд, попробуйте Redpanda Agentic Data Plane.

Продолжайте обучение

• [Документация] Управление политиками доступа
• [Документация] Контроль прав доступа в Redpanda Agentic Data Plane
• [Блог] Управление ИИ-агентами в масштабе: четыре столпа, необходимые каждому предприятию
• [Страница продукта] Redpanda Agentic Data Plane