cloud-access-management

Cloud Access Management — официальный навык Elastic для управления доступом в организации Elastic Cloud и её Serverless-проектах. Он рассчитан на задачи, где нужно пригласить пользователя, назначить или изменить его роль, удалить участника, создать или отозвать Cloud API key либо настроить custom role для Serverless-проекта. Навык также помогает разложить запрос на доступ, сформулированный обычным языком, на отдельные операции приглашения, назначения роли и выдачи ключа. Это не общий справочник по всем механизмам безопасности Elastic: для создания проекта предназначен cloud-create-project, для операций над уже созданным проектом — cloud-manage-project, а для native users, role mappings и DLS/FLS на уровне Elasticsearch — elasticsearch-authz. Перед любой операцией навык предполагает, что уже выполнен cloud-setup и в окружении установлен EC_API_KEY. Идентификатор организации отдельно спрашивать не нужно: его можно автоматически обнаружить запросом GET /organizations. Проектный endpoint Elasticsearch нужен только для операций с custom roles. Для таких операций также требуются учётные данные с привилегией manage_security на соответствующем проекте. В качестве первого read-only шага используется команда `python3 skills/cloud/access-management/scripts/cloud_access.py list-members`: она одновременно проверяет, что EC_API_KEY работает, и помогает получить контекст организации. Если ключа нет, навык не предлагает передавать его в чат: нужно сначала запустить cloud-setup либо настроить переменные локально. Базовый адрес Cloud API — https://api.elastic-cloud.com; ELASTICSEARCH_URL и ELASTICSEARCH_API_KEY нужны только для custom-role операций. Набор задач включает приглашение участника с ролью Serverless-проекта, просмотр участников и текущих назначений, изменение ролей, удаление пользователя, создание дополнительного Cloud API key с ограниченными ролями и сроком действия, а также просмотр и отзыв ключей. Перед действием запрос следует разделить на вопросы «кто», «какой проект», «какой уровень доступа» и «нужен ли API key». Если пользователь уже состоит в организации, новое приглашение не создаётся: сначала проверяется существующее состояние, затем обновляются роли. Аналогично перед созданием ключа нужно выполнить list-api-keys и проверить, нет ли уже ключа для той же задачи с нужными ролями и достаточным сроком жизни. Дублирование ключа для другого назначения допустимо, но второй ключ для той же задачи увеличивает операционную нагрузку без пользы. Для обычных запросов предпочтительны предопределённые роли. На уровне организации доступны organization-admin с полными административными правами над организацией, развёртываниями и проектами, а также billing-admin только для управления платёжными данными. Для Serverless-проектов предусмотрены admin, developer, viewer и editor с разными областями доступности: admin даёт полное управление проектом, developer предназначен для Search и включает создание индексов, API keys, connectors и visualizations, viewer предоставляет доступ только для чтения, а editor используется для Observability и Security и предназначен для настройки функций при read-only доступе к индексам. Для Security также описаны t1_analyst, t2_analyst, t3_analyst, soc_manager и rule_author; их назначение относится соответственно к уровням анализа, расследования, реагирования и созданию правил. Проверка полномочий заранее отдельной командой не выполняется: операция отправляется в API, а при 403 Forbidden нужно остановиться и проверить права выданного ключа. Custom role нужен, когда предопределённой роли недостаточно для требуемой гранулярности: например, для read-only доступа к определённому шаблону индексов, DLS/FLS или feature-level контроля Kibana. Custom role создаётся через Elasticsearch security API командой create-custom-role, а затем назначается пользователю через Cloud API с полем application_roles. Канонический порядок состоит из создания роли в проекте, приглашения пользователя без project role assignments, назначения custom role после принятия приглашения и повторной проверки через list-members и list-roles. Важное ограничение безопасности: при custom role нельзя отдельно назначать viewer или другую предопределённую Cloud role для того же проекта. Custom-role assignment уже предоставляет Viewer-level доступ к проекту в Cloud console, а дополнительная predefined role даёт объединение разрешений и может расширить доступ за пределы задуманного custom role. Для Cloud API keys действует отдельное правило: ключи не наследуют stack roles от role_id. Если application_roles отсутствует или пуст, ключ имеет только Cloud API access; обращение с ним к Elasticsearch или Kibana вернёт 403 Forbidden. Чтобы ключ работал с ES/Kibana API Serverless-проекта, application_roles нужно указать в role_assignments. По умолчанию следует выбирать project-scoped режим и ограничивать ключ конкретными проектами или типом проекта. Organization-scoped application_roles дают доступ ко всем текущим и будущим проектам организации и являются самым широким вариантом, поэтому их следует использовать только при явно подтверждённой потребности в межпроектном доступе. Если organization-scoped ключ использует custom role, такая роль должна существовать в каждом проекте; иначе доступ к проекту может отсутствовать без отдельной ошибки. Практическая проверка после изменения обязательна: после приглашения или назначения роли снова перечисляются участники, а после работы с ключами — ключи. При создании ключа задаётся срок действия, соответствующий задаче; для коротких CI/CD-операций источник рекомендует короткий срок, а долгоживущие ключи следует регулярно ротировать. Секрет ключа не выводится в stdout или stderr: скрипт заменяет чувствительные поля на REDACTED и сохраняет полный ответ во временный файл с правами 0600, путь к которому возвращается в `_secret_file`. Такой файл нельзя читать или пересказывать агенту; после получения значения его следует удалить. Удаление участника и отзыв ключа относятся к разрушительным действиям и требуют подтверждения пользователя перед выполнением. Этот навык помогает безопасно выполнить и проверить конкретные операции доступа, но не доказывает корректность политик всей организации, сетевых traffic filters или настроек SAML: для них используются отдельные Elastic skills и официальные процедуры.