s3_allow_multipart_copy
s3_allow_parallel_part_upload
s3_allow_server_credentials_in_user_queries
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 :
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.