> ## 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.

# paramètres de session s3_allow_*

> Paramètres de session ClickHouse du groupe généré 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
  }}>Type</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{type}</div>
      <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>Par défaut</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{default_value}</div>
      {changeable_without_restart && <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>
          Modifiable sans redémarrage
        </div>}
      {changeable_without_restart && <div style={{
    overflowWrap: "anywhere"
  }}>
          {changeable_without_restart}
        </div>}
    </div>;
};

Ces paramètres sont disponibles dans [system.settings](/docs/fr/reference/system-tables/settings) et sont générés automatiquement à partir du [source](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": "Nouveau paramètre."}]}]} />

Autorise la copie multipartite dans S3.

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

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

Utilise plusieurs threads pour le téléversement multipart S3. Cela peut entraîner une utilisation de la mémoire légèrement plus élevée

<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": "Nouveau paramètre empêchant l'accès S3 issu du SQL utilisateur de résoudre les propres informations d'authentification ambiantes du serveur (environment\/IMDS\/IRSA\/instance-profile\/AWS-config-file\/role_arn-STS\/GCP-OAuth-metadata). Le comportement précédent (autorisé) est rétabli avec les paramètres de compatibilité."}]}]} />

Autorise l'accès S3 provenant du SQL utilisateur à utiliser des informations d'authentification gérées par le serveur.

Lorsqu'il est désactivé (valeur par défaut), les fonctions de table `s3`/`s3Cluster`, les moteurs `S3`/`S3Queue`, les collections nommées S3, les définitions dynamiques `disk(type=s3, ...)`, `BACKUP`/`RESTORE TO S3`, les lectures de données de table DataLake et les bases de données `DataLakeCatalog` (Glue, BigLake) ne peuvent pas résoudre les informations d'authentification à partir de l'environnement, des métadonnées d'instance (IMDS), d'IRSA, d'ECS, du profil d'instance, de SSO, des fichiers AWS de configuration/d'informations d'authentification, de l'assume-role STS basé sur `role_arn` ou du service de métadonnées OAuth de GCP. Une requête qui demande l'une de ces sources gérées par le serveur (par exemple `use_environment_credentials = 1`, un `role_arn` ou `http_client = gcp_oauth`) sans fournir d'informations d'authentification explicites utilisables est rejetée avec `ACCESS_DENIED`. Une requête qui n'en demande aucune est envoyée non signée (anonyme), comme si `NOSIGN` avait été indiqué.

Le fait qu'une requête sans informations d'authentification demande des informations d'authentification d'environnement est déterminé par `use_environment_credentials`. Pour les collections nommées, la valeur par défaut est `0`, de sorte qu'une collection qui spécifie uniquement une URL est lue anonymement. Les fonctions de table `s3`/`s3Cluster` et les moteurs `S3`/`S3Queue` utilisent la valeur par défaut intégrée (`1`), sauf si la configuration du serveur `<s3>` la remplace ; définissez `<s3><use_environment_credentials>0</use_environment_credentials></s3>` pour que leurs lectures sans informations d'authentification soient elles aussi anonymes par défaut (sinon, une telle requête est refusée et doit utiliser `NOSIGN`). Les disques définis dans la configuration du serveur ne sont pas affectés et continuent d'utiliser par défaut les informations d'authentification d'environnement ; les définitions dynamiques `disk(type = s3, ...)` créées par l'utilisateur sont couvertes par la restriction (voir ci-dessus) et sont rejetées lorsqu'elles s'appuient sur les informations d'authentification par défaut/de l'environnement.

Cela empêche un utilisateur authentifié de faire accéder le serveur à S3 avec ses propres informations d'authentification (ambiantes). Les informations d'authentification fournies explicitement ne sont pas affectées : les clés passées dans la requête, les clés statiques d'une collection nommée (créée via SQL ou définie dans la configuration) et les clés de la configuration du serveur `<s3>` continuent toutes de fonctionner.

La méthode recommandée pour donner aux requêtes utilisateur un accès à S3 consiste à utiliser une collection nommée avec des informations d'authentification explicites (ou `NOSIGN` pour les buckets publics) : les clés ne figurent pas dans le texte de la requête, et l'utilisation de chaque collection est contrôlée via RBAC (`GRANT NAMED COLLECTION ON <name> TO <user>`). Vous accordez ainsi à des utilisateurs précis l'accès à des buckets précis, au lieu d'exposer l'identité propre du serveur.

Portée (volontairement limitée) : ce paramètre bloque uniquement les sources d'informations d'authentification ambiantes du serveur listées ci-dessus. Il ne bloque pas les `access_key_id`/`secret_access_key` statiques provisionnés par l'opérateur dans la configuration du serveur `<s3>` ou dans une collection nommée définie dans la configuration : ceux-ci sont traités comme des informations d'authentification explicites et continuent de fonctionner. Notez toutefois que les éléments de requête de configuration tels que `access_header` ou les clés de chiffrement côté serveur ne sont pas, à eux seuls, traités ici comme des informations d'authentification : une requête qui ne contient que de tels éléments, sans paire de clés explicite (et avec la valeur par défaut `use_environment_credentials = 1`), est tout de même refusée, car elle retomberait sinon sur les informations d'authentification ambiantes du serveur. Un tel endpoint doit aussi fournir des clés explicites, `NOSIGN`, `use_environment_credentials = 0` ou l'exception ci-dessous.

Un client administratif de confiance peut avoir besoin d'informations d'authentification gérées par le serveur pour des opérations légitimes (par exemple, attacher des tables système sur un disque `s3_plain_rewritable` via SQL). Activez ce paramètre dans la session de ce client ou dans son profil de paramètres pour l'y autoriser.

Pour `BACKUP`/`RESTORE ... ON CLUSTER`, la valeur de ce paramètre côté initiateur est propagée aux autres hôtes et utilisée telle quelle. Ces hôtes exécutent la continuation de l'opération sur chaque hôte via la file distributed DDL, par défaut sans l'utilisateur de l'initiateur ; sinon, ils évalueraient donc la restriction par rapport à leur propre profil par défaut. La valeur de l'initiateur est conservée, car il a déjà ouvert la même destination de sauvegarde avec ses propres paramètres contraints. Une contrainte `readonly` sur l'initiateur s'applique toujours (un initiateur non fiable ne peut pas activer ce paramètre pour sa propre sauvegarde on-cluster), donc cela n'affaiblit pas la restriction.

Durabilité des tables persistantes `S3` et `S3Queue` : l’activer uniquement par session ou par profil n’est pas pérenne après un redémarrage. Lorsque le serveur recharge une telle table à partir de sa définition stockée (au démarrage ou lors d’un `RESTORE`), il reconstruit le client S3 et réapplique la restriction avec le contexte de démarrage. Ainsi, une table qui s’appuyait sur des informations d’authentification gérées par le serveur et qui a été créée uniquement avec `s3_allow_server_credentials_in_user_queries = 1` au niveau de la session ou du profil est bien créée, mais devient inaccessible après un redémarrage (la table reste en place ; les requêtes qui la ciblent échouent jusqu’à ce que ses credentials soient de nouveau résolus vers une source autorisée). Le serveur lui-même démarre toujours. Donnez à ces tables des informations d’authentification explicites pour un accès pérenne ; sinon, activer ce setting à l’échelle du serveur permet de continuer à les charger après les redémarrages, au prix d’un assouplissement de la restriction pour tous les rechargements.

Pour le laisser désactivé pour les utilisateurs non approuvés, fixez-le dans leur profil en définissant explicitement la valeur sur `0` et en le marquant comme `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>
```

Ce paramètre n’a aucun effet dans `clickhouse-local`, où l’utilisateur est l’opérateur.

Les bases de données `DataLakeCatalog` (Glue, BigLake) sont également concernées, avec une différence. Un objet de catalogue est créé une seule fois et partagé entre tous les utilisateurs de la base de données, de sorte que la valeur ne peut pas être lue pour chaque query ; elle est capturée à partir de la session qui exécute `CREATE DATABASE` (ou un `ATTACH DATABASE` utilisateur). Une base de données créée alors que ce paramètre est activé (par exemple dans une session ou un profile de confiance) peut utiliser les informations d’authentification ambiantes du serveur pour son catalogue, et tout utilisateur pouvant interroger cette base de données les partage ensuite ; si elle est créée avec la configuration par défaut, le catalogue est restreint pour tout le monde, quel que soit l’utilisateur qui l’interroge. Lorsque le server charge une base de données déjà créée depuis ses propres metadata (au démarrage, `RESTORE`), la restriction est réappliquée avec le Context de démarrage, comme pour les tables persistantes `S3`/`S3Queue` : un catalogue qui résout des informations d’authentification gérées par le serveur reste indisponible et la base de données devient inaccessible après un redémarrage (le server démarre tout de même ; la base de données est chargée avec un catalogue indisponible conformément à `s3_load_table_anonymously_if_credentials_restricted`, et les queries signalent la restriction). Un catalogue doté d’informations d’authentification explicites (Glue : `aws_access_key_id` et `aws_secret_access_key` ; BigLake : un triplet Google ADC complet) fonctionne dans tous les cas et reste disponible après redémarrage.