Контроль доступа на основе файлов

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

Существует два типа управления доступом на основе файлов:

• Контроль доступа на уровне системы использует плагин контроля доступа с одним JSON-файл, задающий правила авторизации для всего кластера.

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

Файлы контроля доступа на уровне системы

Плагин контроля доступа позволяет указать правила авторизации для кластер в одном файле JSON.

Конфигурация

Чтобы использовать плагин контроля доступа, добавьтеetc/access-control.propertiesфайл содержащий два обязательных свойства:access-control.name, который необходимо установить кfile, иsecurity.config-file, который должен быть установлен в местоположении файла конфигурации. Местоположение файла конфигурации может указывать либо на локальный диск или к конечной точке http. Например, если файл конфигурации с именемrules.jsonпроживает вetc, добавьтеetc/access-control.propertiesсо следующим содержание:

access-control.name=file
security.config-file=etc/rules.json

Если конфигурация должна быть загружена через конечную точку httphttp://trino-test/configи завернут в объект JSON и доступен черезdataключetc/access-control.properties должно выглядеть так:

access-control.name=file
security.config-file=http://trino-test/config
security.json-pointer=/data

Конфигурационный файл указывается в формате JSON. Он содержит правила, определяющие, какие к каким ресурсам пользователи имеют доступ. Правила читаются сверху вниз и применяется первое правило соответствия. Если ни одно правило не соответствует, доступ запрещен. JSON указатель (RFC 6901) можно указать с помощьюsecurity.json-pointerсвойство чтобы указать вложенный объект внутри содержимого JSON, содержащего правила. По умолчанию, предполагается, что файл содержит один объект, определяющий правила рендеринга спецификацияsecurity.json-pointerв таком случае ненужно.

Обновить

По умолчанию при внесении изменений в файл правил JSON Trino должен быть перезапустился, чтобы загрузить изменения. Существует необязательное свойство для обновления свойства без необходимости перезапуска Trino. Период обновления указан в тотetc/access-control.properties:

security.refresh-period=1s

Доступ к каталогу, схеме и таблицам

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

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

Если никаких правил не предусмотрено вообще, то доступ предоставляется. Вы можете удалить предоставление доступа путем добавления раздела с пустым набором правил в этом конкретном месте уровень, например:

{
  "schemas": []
}

На уровне каталога вам необходимо добавить одно «фиктивное» правило для каждого доступного каталог.

Note

Эти правила не применяются к определяемым системой таблицам в information_schemaсхема.

В следующей таблице приведены разрешения, необходимые для каждой команды SQL:

SQL command	Catalog	Schema	Table	Note
SHOW CATALOGS				Always allowed
SHOW SCHEMAS	read-only	any*	any*	Allowed if catalog is visible
SHOW TABLES	read-only	any*	any*	Allowed if schema visible
CREATE SCHEMA	read-only	owner
DROP SCHEMA	all	owner
SHOW CREATE SCHEMA	all	owner
ALTER SCHEMA … RENAME TO	all	owner*		Ownership is required on both old and new schemas
ALTER SCHEMA … SET AUTHORIZATION	all	owner
CREATE TABLE	all		owner
DROP TABLE	all		owner
ALTER TABLE … RENAME TO	all		owner*	Ownership is required on both old and new tables
ALTER TABLE … SET PROPERTIES	all		owner
CREATE VIEW	all		owner
DROP VIEW	all		owner
ALTER VIEW … RENAME TO	all		owner*	Ownership is required on both old and new views
REFRESH MATERIALIZED VIEW	all		update
COMMENT ON TABLE	all		owner
COMMENT ON COLUMN	all		owner
ALTER TABLE … ADD COLUMN	all		owner
ALTER TABLE … DROP COLUMN	all		owner
ALTER TABLE … RENAME COLUMN	all		owner
SHOW COLUMNS	read-only		any
SELECT FROM table	read-only		select
SELECT FROM view	read-only		select, grant_select
INSERT INTO	all		insert
DELETE FROM	all		delete
UPDATE	all		update

Разрешения, необходимые для выполнения функций:

SQL-команда	Каталог	Разрешение функции	Примечание
SELECT function()		execute, grant_execute*	grant_executeтребуется, когда функция используется вSECURITY DEFINERвид.
CREATE FUNCTION	all	ownership	Не все разъемы поддерживают Catalog user-defined functions.
DROP FUNCTION	all	ownership	Не все разъемы поддерживают Catalog user-defined functions.

Видимость

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

• catalog: Видно, если пользователь является владельцем какой-либо вложенной схемы, имеет разрешения на любую вложенную таблицу или функцию или имеет разрешения на установите свойства сеанса в каталоге.

• schema: отображается, если пользователь является владельцем схемы или имеет разрешения. для любой вложенной таблицы или функции.

• table: отображается, если у пользователя есть какие-либо разрешения на доступ к таблице.

Правила каталога

Каждое правило каталога состоит из следующих полей:

• user(необязательно): регулярное выражение для сопоставления с именем пользователя. По умолчанию.*.

• role(необязательно): регулярное выражение для сопоставления с именами ролей. По умолчанию.*.

• group(необязательно): регулярное выражение для сопоставления с именами групп. По умолчанию.*.

• catalog(необязательно): регулярное выражение для сопоставления с именем каталога. По умолчанию .*.

• allow(обязательно): строка, указывающая, имеет ли пользователь доступ к каталог. Это значение может бытьall, read-onlyилиnoneи по умолчанию none. Установка этого значения наread-onlyимеет такое же поведение, как и read-onlyПлагин контроля доступа к системе.

Чтобы правило применялось, имя пользователя должно соответствовать регулярному выражению. указано вuserатрибут.

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

Для имен групп правило может применяться, если хотя бы одно имя группы этого пользователя соответствуетgroupрегулярное выражение.

The allценность дляallowозначает, что эти правила не ограничивают доступ ни в каком способ, но правила схемы и таблицы могут ограничить доступ.

Note

По умолчанию все пользователи имеют доступ кsystemкаталог. Ты можешь переопределите это поведение, добавив правило.

логическое значениеtrueиfalseтакже поддерживаются как устаревшие значения для allow, для поддержки обратной совместимости.trueкарты вall, иfalseкарты вnone.

Например, если вы хотите разрешить только рольadminчтобы получить доступ к mysqlиsystemкаталог, разрешить пользователям изfinanceи human_resourcesдоступ групп кpostgresкаталог, разрешить всем пользователям получить доступ кhiveкаталог и запретить любой другой доступ, вы можете использовать следующие правила:

{
  "catalogs": [
    {
      "role": "admin",
      "catalog": "(mysql|system)",
      "allow": "all"
    },
    {
      "group": "finance|human_resources",
      "catalog": "postgres",
      "allow": true
    },
    {
      "catalog": "hive",
      "allow": "all"
    },
    {
      "user": "alice",
      "catalog": "postgresql",
      "allow": "read-only"
    },
    {
      "catalog": "system",
      "allow": "none"
    }
  ]
}

Для соответствия групповым правилам пользователей необходимо назначать в группы с помощью Провайдер групп.

Правила схемы

Каждое правило схемы состоит из следующих полей:

• user(необязательно): регулярное выражение для сопоставления с именем пользователя. По умолчанию.*.

• role(необязательно): регулярное выражение для сопоставления с именами ролей. По умолчанию.*.

• group(необязательно): регулярное выражение для сопоставления с именами групп. По умолчанию.*.

• catalog(необязательно): регулярное выражение для сопоставления с именем каталога. По умолчанию .*.

• schema(необязательно): регулярное выражение для сопоставления с именем схемы. По умолчанию .*.

• owner(обязательно): логическое значение, указывающее, следует ли учитывать пользователя владелец схемы. По умолчаниюfalse.

Например, чтобы передать право собственности на все схемы ролиadmin, лечить всех пользователи как владельцыdefault.defaultсхему и запретить пользователюguest от владения какой-либо схемой можно использовать следующие правила:

{
  "schemas": [
    {
      "role": "admin",
      "schema": ".*",
      "owner": true
    },
    {
      "user": "guest",
      "owner": false
    },
    {
      "catalog": "default",
      "schema": "default",
      "owner": true
    }
  ]
}

Правила стола

Каждое правило таблицы состоит из следующих полей:

• user(необязательно): регулярное выражение для сопоставления с именем пользователя. По умолчанию.*.

• role(необязательно): регулярное выражение для сопоставления с именами ролей. По умолчанию.*.

• group(необязательно): регулярное выражение для сопоставления с именами групп. По умолчанию.*.

• catalog(необязательно): регулярное выражение для сопоставления с именем каталога. По умолчанию .*.

• schema(необязательно): регулярное выражение для сопоставления с именем схемы. По умолчанию.*.

• table(необязательно): регулярное выражение для сопоставления с именами таблиц. По умолчанию.*.

• privileges(обязательно): ноль или болееSELECT, INSERT, DELETE, UPDATE, OWNERSHIP, GRANT_SELECT

• columns(необязательно): список ограничений столбца.

• filter(необязательно): логическое выражение фильтра для таблицы.

• filter_environment(необязательно): использование среды во время оценки фильтра.

Ограничение столбца

Эти ограничения можно использовать для ограничения доступа к данным столбца.

• name: имя столбца.

• allow(необязательно): если false, столбец недоступен.

• mask(необязательно): выражение маски, примененное к столбцу.

• mask_environment(необязательно): использование среды во время оценки маски.

Фильтрация и маска среды

• user(необязательно): имя пользователя для проверки разрешения подзапросов в маске.

Note

Эти правила не распространяются наinformation_schema.

maskможет содержать условные выражения, такие какIFилиCASE, что обеспечивает условное маскирование.

В приведенном ниже примере определяется следующая политика доступа к таблицам:

• Рольadminимеет все привилегии ко всем таблицам и схемам

• Пользовательbanned_userне имеет привилегий

• Все пользователи имеютSELECTпривилегии наdefault.hr.employees, но таблица фильтруется только по строке для текущего пользователя.

• Все пользователи имеютSELECTпривилегии для всех таблиц вdefault.default схему, за исключениемaddressстолбец, который заблокирован, иssnкоторый замаскирован.

{
  "tables": [
    {
      "role": "admin",
      "privileges": ["SELECT", "INSERT", "DELETE", "UPDATE", "OWNERSHIP"]
    },
    {
      "user": "banned_user",
      "privileges": []
    },
    {
      "catalog": "default",
      "schema": "hr",
      "table": "employee",
      "privileges": ["SELECT"],
      "filter": "user = current_user",
      "filter_environment": {
        "user": "system_user"
      }
    },
    {
      "catalog": "default",
      "schema": "default",
      "table": ".*",
      "privileges": ["SELECT"],
      "columns" : [
         {
            "name": "address",
            "allow": false
         },
         {
            "name": "SSN",
            "mask": "'XXX-XX-' + substring(credit_card, -4)",
            "mask_environment": {
              "user": "system_user"
            }
         }
      ]
    }
  ]
}

Правила функции

Эти правила контролируют возможность пользователя создавать, удалять и выполнять функции.

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

Note

Пользователи всегда имеют доступ к функциям вsystem.builtinсхема и вы не можете изменить это поведение, добавив правило.

Каждое функциональное правило состоит из следующих полей:

• user(необязательно): регулярное выражение для сопоставления с именем пользователя. По умолчанию.*.

• role(необязательно): регулярное выражение для сопоставления с именами ролей. По умолчанию.*.

• group(необязательно): регулярное выражение для сопоставления с именами групп. По умолчанию.*.

• catalog(необязательно): регулярное выражение для сопоставления с именем каталога. По умолчанию.*.

• schema(необязательно): регулярное выражение для сопоставления с именем схемы. По умолчанию.*.

• function(необязательно): регулярное выражение для сопоставления с именами функций. По умолчанию.*.

• privileges(обязательно): ноль или болееEXECUTE, GRANT_EXECUTE, OWNERSHIP.

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

Следующий пример позволяетadminпользователь для выполненияsystem.queryтабличная функция в любой каталог и позволяет всем пользователям создавать, удалять и выполнять функции (включая SECURITY DEFINERпросмотров) вhive.functionсхема:

{
  "functions": [
    {
      "user": "admin",
      "schema": "system",
      "function": "query",
      "privileges": [
        "EXECUTE"
      ]
    },
    {
      "catalog": "hive",
      "schema": "function",
      "privileges": [
        "EXECUTE", "GRANT_EXECUTE", "OWNERSHIP"
      ]
    }
  ]
}

Правила процедуры

Эти правила контролируют возможность пользователя выполнять процедуры с использованием Оператор CALL.

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

При наличии правил процедуры авторизация основана на первом правило сопоставления, обрабатываемое сверху вниз. Если ни одно правило не соответствует, в авторизации отказано. Если правила процедур отсутствуют, используются только процедуры в system.builtinможет быть выполнено.

Каждое правило процедуры состоит из следующих полей:

• user(необязательно): регулярное выражение для сопоставления с именем пользователя. По умолчанию.*.

• role(необязательно): регулярное выражение для сопоставления с именами ролей. По умолчанию.*.

• group(необязательно): регулярное выражение для сопоставления с именами групп. По умолчанию.*.

• catalog(необязательно): регулярное выражение для сопоставления с именем каталога. По умолчанию.*.

• schema(необязательно): регулярное выражение для сопоставления с именем схемы. По умолчанию.*.

• procedure(необязательно): регулярное выражение для сопоставления с именами процедур. По умолчанию.*.

• privileges(обязательно): ноль или болееEXECUTE, GRANT_EXECUTE.

Следующий пример позволяетadminпользователь для выполнения и разрешения выполнения права на звонокregister_tableиunregister_tableвsystemсхема каталог под названиемdelta, который использует Delta Lake разъем. Это позволяет всем пользователям выполнять delta.sytem.vacuumпроцедура.

{
  "procedures": [
    {
      "user": "admin",
      "catalog": "delta",
      "schema": "system",
      "procedure": "register_table|unregister_table",
      "privileges": [
        "EXECUTE",
        "GRANT_EXECUTE"
      ]
    },
    {
      "catalog": "delta",
      "schema": "system",
      "procedure": "vacuum",
      "privileges": [
        "EXECUTE"
      ]
    }
  ]
}

Правила табличных процедур

Табличные процедуры выполняются с использованием Синтаксис [ALTER TABLE … EXECUTE] (изменить-таблицу-выполнить).

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

Проверьте конфигурацию

Чтобы убедиться, что файл управления доступом к системе настроен правильно, установите правила для полной блокировки доступа всем пользователям системы:

{
  "catalogs": [
    {
      "catalog": "system",
      "allow": "none"
    }
  ]
}

Перезапустите кластер, чтобы активировать правила для вашего кластера. С Trino CLI выполните запрос для проверки авторизации:

trino> SELECT * FROM system.runtime.nodes;
Query 20200824_183358_00000_c62aw failed: Access Denied: Cannot access catalog system

Удалите эти правила и перезапустите кластер Trino.

Правила свойств сеанса

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

• user(необязательно): регулярное выражение для сопоставления с именем пользователя. По умолчанию.*.

• role(необязательно): регулярное выражение для сопоставления с именами ролей. По умолчанию.*.

• group(необязательно): регулярное выражение для сопоставления с именами групп. По умолчанию.*.

• property(необязательно): регулярное выражение для сопоставления с именем свойства. По умолчанию .*.

• allow(обязательно): логическое значение, указывающее, установлена ​​ли настройка сеанса. собственность должна быть разрешена.

В правилах свойств сеанса каталога есть дополнительное поле:

• catalog(необязательно): регулярное выражение для сопоставления с именем каталога. По умолчанию .*.

В приведенном ниже примере определяется следующая политика доступа к таблицам:

• Рольadminможно установить все свойства сеанса

• Пользовательbanned_userне могу установить какие-либо свойства сеанса

• Все пользователи могут установитьresource_overcommitсвойство системного сеанса и bucket_execution_enabledсвойство сеанса вhiveкаталог.

{
    "system_session_properties": [
        {
            "role": "admin",
            "allow": true
        },
        {
            "user": "banned_user",
            "allow": false
        },
        {
            "property": "resource_overcommit",
            "allow": true
        }
    ],
    "catalog_session_properties": [
        {
            "role": "admin",
            "allow": true
        },
        {
            "user": "banned_user",
            "allow": false
        },
        {
            "catalog": "hive",
            "property": "bucket_execution_enabled",
            "allow": true
        }
    ]
}

Правила запроса

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

• user(необязательно): регулярное выражение для сопоставления с именем пользователя. По умолчанию.*.

• role(необязательно): регулярное выражение для сопоставления с именами ролей. По умолчанию.*.

• group(необязательно): регулярное выражение для сопоставления с именами групп. По умолчанию.*.

• queryOwner(необязательно): регулярное выражение для сопоставления с именем владельца запроса. По умолчанию.*.

• allow(обязательно): набор разрешений на запросы, предоставленных пользователю. Ценности: execute, view, kill

Note

Пользователи всегда имеют разрешение просматривать или удалять свои собственные запросы.

Правило, которое включает в себяqueryOwnerможет не включать в себяexecuteрежим доступа. Запросы принадлежат пользователю только после начала их выполнения.

Например, если вы хотите разрешить рольadminполный доступ к запросам, разрешить пользовательaliceвыполнять и уничтожать запросы, разрешать членам группы contractorsдля просмотра запросов, принадлежащих пользователямaliceилиdave, разрешить любой пользователя для выполнения запросов и запрета любого другого доступа, вы можете использовать следующее правила:

{
  "queries": [
    {
      "role": "admin",
      "allow": ["execute", "kill", "view"]
    },
    {
      "user": "alice",
      "allow": ["execute", "kill"]
    },
    {
      "group": "contractors",
      "queryOwner": "alice|dave",
      "allow": ["view"]
    },
    {
      "allow": ["execute"]
    }
  ]
}

Правила олицетворения

Эти правила контролируют возможность пользователя выдавать себя за другого пользователя. В в некоторых средах администратору (или управляемой системе) желательно запускать запросы от имени других пользователей. В этих случаях администратор аутентифицируется, используя свои учетные данные, а затем отправляет запрос как другой пользователь. При изменении контекста пользователя Trino проверяет, что администратор имеет право запускать запросы от имени целевого пользователя.

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

Каждое правило олицетворения состоит из следующих полей:

• original_user(необязательно): регулярное выражение для сопоставления с пользователем, запрашивающим олицетворение. По умолчанию.*.

• original_role(необязательно): регулярное выражение для сопоставления с именами ролей с просьбой выдать себя за другое лицо. По умолчанию.*.

• new_user(обязательно): регулярное выражение для сопоставления с пользователем, которого нужно олицетворять. Может содержать ссылки на подпоследовательности, захваченные во время сопоставления с original_user, и каждая ссылка заменяется результатом вычисления соответствующую группу соответственно.

• allow(необязательно): логическое значение, указывающее, должна ли проводиться аутентификация. допустимый. По умолчаниюtrue.

Правила олицетворения немного отличаются от других правил: Атрибут new_userтребуется, чтобы случайно не предотвратить больший доступ, чем предполагалось. При этом можно было сделать атрибутallowнеобязательный.

Следующий пример позволяетadminроль, чтобы выдавать себя за любого пользователя, кроме дляbob. Это также позволяет любому пользователю выдавать себя заtestпользователь. Это также позволяет пользователю в формеteam_backendвыдавать себя за team_backend_sandboxпользователь, а не произвольные пользователи:

{
    "impersonation": [
        {
            "original_role": "admin",
            "new_user": "bob",
            "allow": false
        },
        {
            "original_role": "admin",
            "new_user": ".*"
        },
        {
            "original_user": ".*",
            "new_user": "test"
        },
        {
            "original_user": "team_(.*)",
            "new_user": "team_$1_sandbox",
            "allow": true
        }
    ]
}

Основные правила

Warning

Основные правила устарели. Вместо этого используйте Сопоставление пользователей который определяет, как сложное имя пользователя аутентификации сопоставляется с простым имя пользователя для Trino и правила олицетворения, определенные выше.

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

• principal(обязательно): регулярное выражение для сопоставления и группировки по принципу.

• user(необязательно): регулярное выражение для сопоставления с именем пользователя. Если оно совпадает, то выдает или отказывает в разрешении в зависимости от стоимостиallow.

• principal_to_user(необязательно): строка замены для замены главный. Если результат подмены совпадает с именем пользователя, это выдает или отказывает в разрешении в зависимости от стоимостиallow.

• allow(обязательно): логическое значение, указывающее, может ли принципал быть авторизован как пользователь.

Note

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

Следующее реализует точное соответствие полного имени участника для LDAP. и аутентификация Kerberos:

{
  "principals": [
    {
      "principal": "(.*)",
      "principal_to_user": "$1",
      "allow": true
    },
    {
      "principal": "([^/]+)(/.*)?@.*",
      "principal_to_user": "$1",
      "allow": true
    }
  ]
}

Если вы хотите разрешить пользователям использовать то же имя, что и их Kerberos основное имя и разрешитьaliceиbobиспользовать участника группы с именем какgroup@example.net, вы можете использовать следующие правила.

{
  "principals": [
    {
      "principal": "([^/]+)/?.*@example.net",
      "principal_to_user": "$1",
      "allow": true
    },
    {
      "principal": "group@example.net",
      "user": "alice|bob",
      "allow": true
    }
  ]
}

Правила информации о системе

Эти правила определяют, какие пользователи могут получить доступ к управлению системной информацией. интерфейс. Доступ к системной информации включает в себя следующие аспекты:

• Доступ для чтения к конфиденциальной информации с конечных точек REST, например/v1/node и/v1/thread.

• Доступ для чтения с помощью system information functions.

• Доступ для чтения с помощью System connector.

• Доступ на запись для триггера Graceful shutdown.

Следующие конечные точки REST всегда являются общедоступными и на них не распространяются эти правила:

• GET /v1/info

• GET /v1/info/state

• GET /v1/status

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

• role(необязательно): регулярное выражение для сопоставления с ролью. Если оно совпадает, то выдает или отказывает в разрешении в зависимости от стоимостиallow.

• user(необязательно): регулярное выражение для сопоставления с именем пользователя. Если оно совпадает, то выдает или отказывает в разрешении в зависимости от стоимостиallow.

• allow(обязательно): набор прав доступа, предоставленных пользователю. Ценности: read, write

Следующая конфигурация представляет собой пример:

{
  "system_information": [
    {
      "role": "admin",
      "allow": ["read", "write"]
    },
    {
      "user": "alice",
      "allow": ["read"]
    }
  ]
}

• Все пользователи сadminроль имеет доступ на чтение и запись в систему информация. Это включает в себя возможность запускать Graceful shutdown.

• Пользовательaliceможет читать системную информацию.

• Всем остальным пользователям и ролям запрещен доступ к системной информации.

Фиксированного пользователя можно настроить для интерфейсов управления с помощьюmanagement.user свойство конфигурации. Когда это настроено, правила системной информации должны по-прежнему должно быть установлено, чтобы разрешить этому пользователю читать или записывать информацию управления. Пользователь фиксированного управления по умолчанию применяется только к HTTP. Чтобы включить фиксированную пользователя через HTTPS, установитеmanagement.user.https-enabledконфигурация свойство.

Правила авторизации

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

ALTER SCHEMA name SET AUTHORIZATION ( user | USER user | ROLE role )
ALTER TABLE name SET AUTHORIZATION ( user | USER user | ROLE role )
ALTER VIEW name SET AUTHORIZATION ( user | USER user | ROLE role )

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

Обратите внимание, что для выполненияALTERкоманда по схеме, таблице или представлению требует пользователяOWNERSHIP привилегия.

Каждое правило авторизации состоит из следующих полей:

• original_user(необязательно): регулярное выражение для сопоставления с пользователем, запрашивающим авторизация. По умолчанию.*.

• original_group(необязательно): регулярное выражение для сопоставления с именами групп запрос авторизации. По умолчанию.*.

• original_role(необязательно): регулярное выражение для сопоставления с именами ролей запрос авторизации. По умолчанию.*.

• new_user(необязательно): регулярное выражение для сопоставления с новым пользователем-владельцем схемы, таблицы или представления. По умолчанию не совпадает.

• new_role(необязательно): регулярное выражение для сопоставления с новой ролью владельца схемы, таблицы или представления. По умолчанию не совпадает.

• allow(необязательно): логическое значение, указывающее, должна ли проводиться аутентификация. допустимый. По умолчаниюtrue.

Обратите внимание, чтоnew_userиnew_roleявляются необязательными, однако необходимо указать хотя бы один из них.

Следующий пример позволяетadminроль, чтобы изменить владельца любой схемы, таблицы или представления любому пользователю, кроме ``боб``.

{
  "authorization": [
    {
      "original_role": "admin",
      "new_user": "bob",
      "allow": false
    },
    {
      "original_role": "admin",
      "new_user": ".*",
      "new_role": ".*"
    }
  ],
  "schemas": [
    {
      "role": "admin",
      "owner": true
    }
  ],
  "tables": [
    {
      "role": "admin",
      "privileges": ["OWNERSHIP"]
    }
  ]
}

Файлы контроля доступа на уровне каталога

Вы можете создавать файлы JSON для отдельных каталогов, определяющих авторизацию. правила, специфичные для этого каталога. Чтобы включить файлы контроля доступа на уровне каталога, добавьте свойство конфигурации каталога для конкретного соединителя, которое задает тип авторизации дляFILEиsecurity.config-fileкаталог Свойство конфигурации, указывающее файл правил JSON.

Например, следующие свойства конфигурации каталога Iceberg используют параметр rules.jsonфайл для контроля доступа на уровне каталога:

iceberg.security=FILE
security.config-file=etc/catalog/rules.json

Файлы контроля доступа на уровне каталога поддерживаются отдельно для каждого соединителя, см. для получения дополнительной информации обратитесь к документации разъема.

Note

Эти правила не применяются к определяемым системой таблицам в information_schemaсхема.

Настройка файла правил каталога

Файл конфигурации указывается в формате JSON. Этот файл состоит из следующие разделы, каждый из которых представляет собой список правил, обрабатываемых в порядок сверху вниз:

1. schemas

2. tables

3. session_properties

Пользователю предоставляются привилегии из первого соответствующего правила. Все регулярные выражения по умолчанию.*если не указано.

Правила схемы

Эти правила определяют, кто считается владельцем схемы.

• user(необязательно): регулярное выражение для сопоставления с именем пользователя.

• group(необязательно): регулярное выражение для сопоставления с каждой группой пользователей, к которой принадлежит пользователь. к.

• schema(необязательно): регулярное выражение для сопоставления с именем схемы.

• owner(обязательно): логическое значение, указывающее право собственности.

Правила стола

Эти правила регулируют привилегии, предоставляемые конкретным таблицам.

• user(необязательно): регулярное выражение для сопоставления с именем пользователя.

• group(необязательно): регулярное выражение для сопоставления с каждой группой пользователей, к которой принадлежит пользователь. к.

• schema(необязательно): регулярное выражение для сопоставления с именем схемы.

• table(необязательно): регулярное выражение для сопоставления с именем таблицы.

• privileges(обязательно): ноль или болееSELECT, INSERT, DELETE, UPDATE, OWNERSHIP, GRANT_SELECT.

• columns(необязательно): список ограничений столбца.

• filter(необязательно): логическое выражение фильтра для таблицы.

• filter_environment(необязательно): среда, используемая во время оценки фильтра.

Ограничения столбца

Эти ограничения можно использовать для ограничения доступа к данным столбца.

• name: имя столбца.

• allow(необязательно): если false, столбец недоступен.

• mask(необязательно): выражение маски, примененное к столбцу.

• mask_environment(необязательно): использование среды во время оценки маски.

Фильтровать среду и маскировать среду

Эти правила распространяются наfilter_environmentиmask_environment.

• user(необязательно): имя пользователя для проверки разрешения подзапросов в маске.

Note

maskможет содержать условные выражения, такие какIFилиCASE, что обеспечивает условное маскирование.

Правила функции

Эти правила контролируют возможность пользователя создавать, удалять и выполнять функции.

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

• user(необязательно): регулярное выражение для сопоставления с именем пользователя. По умолчанию.*.

• group(необязательно): регулярное выражение для сопоставления с именами групп. По умолчанию.*.

• schema(необязательно): регулярное выражение для сопоставления с именем схемы. По умолчанию.*.

• function(необязательно): регулярное выражение для сопоставления с именами функций. По умолчанию.*.

• privileges(обязательно): ноль или болееEXECUTE, GRANT_EXECUTE, OWNERSHIP.

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

Следующий пример позволяетadminпользователь для выполненияsystem.queryтабличная функция из этот каталог и все пользователи могут создавать, удалять и выполнять функции (в том числе из представлений) вfunctionсхема этого каталога:

{
  "functions": [
    {
      "user": "admin",
      "schema": "system",
      "function": "query",
      "privileges": [
        "EXECUTE"
      ]
    },
    {
      "schema": "function",
      "privileges": [
        "EXECUTE", "GRANT_EXECUTE", "OWNERSHIP"
      ]
    }
  ]
}

Правила свойств сеанса

Эти правила определяют, кто может устанавливать свойства сеанса.

• user(необязательно): регулярное выражение для сопоставления с именем пользователя.

• group(необязательно): регулярное выражение для сопоставления с каждой группой пользователей, к которой принадлежит пользователь. к.

• property(необязательно): регулярное выражение для сопоставления с именем свойства сеанса.

• allow(обязательно): логическое значение, указывающее, может ли это свойство сеанса быть набор.

Пример

{
  "schemas": [
    {
      "user": "admin",
      "schema": ".*",
      "owner": true
    },
    {
      "group": "finance|human_resources",
      "schema": "employees",
      "owner": true
    },
    {
      "user": "guest",
      "owner": false
    },
    {
      "schema": "default",
      "owner": true
    }
  ],
  "tables": [
    {
      "user": "admin",
      "privileges": ["SELECT", "INSERT", "DELETE", "UPDATE", "OWNERSHIP"]
    },
    {
      "user": "banned_user",
      "privileges": []
    },
    {
      "schema": "hr",
      "table": "employee",
      "privileges": ["SELECT"],
      "filter": "user = current_user"
    },
    {
      "schema": "default",
      "table": ".*",
      "privileges": ["SELECT"],
      "columns" : [
         {
            "name": "address",
            "allow": false
         },
         {
            "name": "ssn",
            "mask": "'XXX-XX-' + substring(credit_card, -4)",
            "mask_environment": {
              "user": "admin"
            }
         }
      ]
    }
  ],
  "session_properties": [
    {
      "property": "force_local_scheduling",
      "allow": true
    },
    {
      "user": "admin",
      "property": "max_split_size",
      "allow": true
    }
  ]
}