s3_allow_multipart_copy
s3_allow_parallel_part_upload
s3_allow_server_credentials_in_user_queries
s3/s3Cluster, движки S3/S3Queue, именованные коллекции S3, динамические определения disk(type=s3, ...), BACKUP/RESTORE TO S3, чтение данных таблиц DataLake и базы данных DataLakeCatalog (Glue, BigLake) не могут получать учётные данные из окружения, метаданных инстанса (IMDS), IRSA, ECS, профиля инстанса, SSO, файлов AWS config/credentials, STS assume-role на основе role_arn или службы метаданных GCP OAuth. Запрос, который обращается к одному из этих источников, управляемых сервером (например, use_environment_credentials = 1, role_arn или http_client = gcp_oauth), но не передаёт пригодные явные учётные данные, отклоняется с ACCESS_DENIED. Запрос, который не обращается ни к одному из них, отправляется без подписи (анонимно) — так же, как если бы был указан NOSIGN.
То, запрашивает ли запрос без учётных данных учётные данные из окружения, определяется параметром use_environment_credentials. В именованных коллекциях по умолчанию используется 0, поэтому коллекция, в которой указан только URL, читает анонимно. Табличные функции s3/s3Cluster и движки S3/S3Queue используют встроенное значение по умолчанию (1), если только в конфигурации сервера <s3> не задано иное; установите <s3><use_environment_credentials>0</use_environment_credentials></s3>, чтобы их чтение без учётных данных тоже по умолчанию было анонимным (иначе такой запрос отклоняется и должен использовать NOSIGN). Диски, определённые в конфигурации сервера, это не затрагивает, и они по умолчанию продолжают использовать учётные данные из окружения; созданные пользователем динамические определения disk(type = s3, ...) подпадают под это ограничение (см. выше) и отклоняются, если полагаются на учётные данные по умолчанию/из окружения.
Это не позволяет аутентифицированному пользователю заставить сервер обращаться к S3 с использованием его собственных (неявных) учётных данных. Явно переданные учётные данные не затрагиваются: ключи, переданные в запросе, статические ключи в именованной коллекции (созданной через SQL или определённой в config), а также ключи в конфигурации сервера <s3> продолжают работать.
Рекомендуемый способ предоставить пользовательским запросам доступ к S3 — использовать именованную коллекцию с явными учётными данными (или NOSIGN для public buckets): ключи не попадают в текст запроса, а использование каждой коллекции контролируется через RBAC (GRANT NAMED COLLECTION ON <name> TO <user>), поэтому вы предоставляете конкретным пользователям доступ к конкретным бакетам, не раскрывая собственную идентичность сервера.
Область действия (умышленно не охватывается): эта настройка блокирует только перечисленные выше неявные источники учётных данных сервера. Она не блокирует статические access_key_id/secret_access_key, подготовленные оператором, из конфигурации сервера <s3> или из именованной коллекции, определённой в config: они считаются явными учётными данными и продолжают работать. Однако обратите внимание, что такие элементы конфигурации запроса, как access_header или ключи server-side-encryption, сами по себе здесь не считаются учётными данными: запрос, который содержит только их, но не содержит явной пары ключей (и использует значение по умолчанию use_environment_credentials = 1), всё равно отклоняется, поскольку в противном случае он бы переключился на неявные учётные данные сервера. Для такой конечной точки также необходимо указать явные ключи, NOSIGN, use_environment_credentials = 0 или использовать описанное ниже исключение.
Доверенному административному client могут требоваться учётные данные, управляемые сервером, для легитимных операций (например, для подключения system tables на диске s3_plain_rewritable через SQL). Включите эту настройку в сеансе этого client или в его профиле настроек, чтобы разрешить это.
Для BACKUP/RESTORE ... ON CLUSTER значение этой настройки у initiator передаётся другим hosts и используется там как есть. Эти hosts выполняют продолжение операции на каждом хосте через очередь distributed DDL, по умолчанию без пользователя initiator, поэтому в противном случае они бы применяли это ограничение относительно собственного профиля по умолчанию; вместо этого сохраняется значение initiator, поскольку он уже открыл тот же пункт назначения резервной копии в рамках своих собственных ограниченных настроек. Ограничение readonly для initiator по-прежнему действует (ненадёжный initiator не может включить эту настройку для собственного on-cluster backup), так что это не ослабляет ограничение.”
Надёжность для постоянных таблиц S3 и S3Queue: включение этого параметра только на уровне сеанса или профиля не сохраняется после перезапуска. Когда сервер заново загружает такую таблицу из её сохранённого определения (при запуске или RESTORE), он пересоздаёт клиент S3 и повторно применяет ограничение в контексте запуска, поэтому таблица, которая использовала учётные данные, управляемые сервером, и была создана только при s3_allow_server_credentials_in_user_queries = 1 на уровне сеанса/профиля, создаётся успешно, но после перезапуска становится недоступной (сама таблица остаётся на месте; запросы к ней завершаются ошибкой, пока её credentials снова не начнут разрешаться в допустимый источник). Сам сервер при этом всё равно запускается. Чтобы доступ к таким таблицам сохранялся после перезапуска, укажите для них явные credentials; либо можно включить этот параметр для всего сервера, чтобы они продолжали загружаться после перезапусков, ценой ослабления ограничения для всех повторных загрузок.
Чтобы он оставался отключённым для недоверенных пользователей, закрепите его в их профиле, явно задав значение 0 и пометив его как readonly:
clickhouse-local, где оператор выступает пользователем.
Базы данных DataLakeCatalog (Glue, BigLake) тоже подпадают под это правило, но с одним отличием. Объект каталога создаётся один раз и используется совместно всеми пользователями базы данных, поэтому значение нельзя считывать отдельно для каждого запроса; оно берётся из сеанса, в котором выполняется CREATE DATABASE (или ATTACH DATABASE, выполняемого пользователем). База данных, созданная при включённом этом параметре (например, в доверенном сеансе или профиле), может использовать для своего каталога неявные учётные данные сервера, и тогда ими будут совместно пользоваться все, у кого есть доступ к запросам к этой базе данных; если же она создана со значением по умолчанию, каталог будет ограничен для всех независимо от того, кто к нему обращается. Когда сервер загружает уже созданную базу данных из собственных метаданных (при запуске, RESTORE), ограничение применяется повторно в контексте запуска — так же, как и для постоянных таблиц S3/S3Queue: каталог, в котором используются учётные данные, управляемые сервером, остаётся недоступным, и после перезапуска база данных становится недоступной (сам сервер при этом всё равно запускается; база данных загружается с недоступным каталогом согласно s3_load_table_anonymously_if_credentials_restricted, а запросы сообщают об ограничении). Каталог, для которого заданы явные учётные данные (Glue: aws_access_key_id и aws_secret_access_key; BigLake: полная тройка Google ADC), работает в любом случае и сохраняет работоспособность после перезапуска.