> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# настройки сеанса s3_allow_*

> Настройки сеанса ClickHouse из сгенерированной группы s3_allow_*.

export const SettingsInfoBlock = ({type, default_value, changeable_without_restart}) => {
  return <div className="not-prose" style={{
    display: "flex",
    flexWrap: "wrap",
    alignItems: "baseline",
    columnGap: "0.5rem",
    rowGap: "0.125rem",
    margin: "0.375rem 0",
    fontSize: "0.8125rem",
    lineHeight: "1.125rem"
  }}>
      <div style={{
    fontWeight: 600,
    opacity: 0.72
  }}>Тип</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{type}</div>
      <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>По умолчанию</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{default_value}</div>
      {changeable_without_restart && <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>
          Изменяется без перезапуска
        </div>}
      {changeable_without_restart && <div style={{
    overflowWrap: "anywhere"
  }}>
          {changeable_without_restart}
        </div>}
    </div>;
};

Эти настройки доступны в [system.settings](/docs/ru/reference/system-tables/settings) и автоматически генерируются из [исходного кода](https://github.com/ClickHouse/ClickHouse/blob/master/src/Core/Settings.cpp).

<div id="s3_allow_multipart_copy">
  ## s3\_allow\_multipart\_copy
</div>

<SettingsInfoBlock type="Bool" default_value="1" />

<VersionHistory rows={[{"id": "row-1","items": [{"label": "25.2"},{"label": "1"},{"label": "Новая настройка"}]}]} />

Разрешает многокомпонентное копирование в S3.

<div id="s3_allow_parallel_part_upload">
  ## s3\_allow\_parallel\_part\_upload
</div>

<SettingsInfoBlock type="Bool" default_value="1" />

Использовать несколько потоков для multipart-загрузки в S3. Это может привести к несколько большему использованию памяти

<div id="s3_allow_server_credentials_in_user_queries">
  ## s3\_allow\_server\_credentials\_in\_user\_queries
</div>

<SettingsInfoBlock type="Bool" default_value="0" />

<VersionHistory rows={[{"id": "row-1","items": [{"label": "26.7"},{"label": "0"},{"label": "Новая настройка, запрещающая пользовательскому SQL доступ к S3 через разрешение собственных неявных учётных данных сервера (environment\/IMDS\/IRSA\/instance-profile\/AWS-config-file\/role_arn-STS\/GCP-OAuth-metadata). Прежнее поведение (разрешено) восстанавливается настройками compatibility."}]}]} />

Разрешает доступ к S3 из пользовательского SQL с использованием учётных данных, управляемых сервером.

Когда настройка отключена (по умолчанию), табличные функции `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`:

```xml theme={null}
<profiles>
    <untrusted>
        <!-- The explicit value is required: a `readonly` constraint alone only blocks direct changes,
             but `compatibility` with a version before this setting was introduced would otherwise
             restore the old (allowing) default. Setting the value explicitly defeats `compatibility`. -->
        <s3_allow_server_credentials_in_user_queries>0</s3_allow_server_credentials_in_user_queries>
        <constraints>
            <s3_allow_server_credentials_in_user_queries>
                <readonly/>
            </s3_allow_server_credentials_in_user_queries>
        </constraints>
    </untrusted>
</profiles>
```

Этот параметр не влияет на `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), работает в любом случае и сохраняет работоспособность после перезапуска.