s3_allow_multipart_copy
s3_allow_parallel_part_upload
s3_allow_server_credentials_in_user_queries
s3/s3Cluster, los motores S3/S3Queue, las colecciones con nombre de S3, las definiciones dinámicas disk(type=s3, ...), BACKUP/RESTORE TO S3, las lecturas de datos de tablas de DataLake y las bases de datos DataLakeCatalog (Glue, BigLake) no pueden resolver credenciales desde el entorno, los metadatos de instancia (IMDS), IRSA, ECS, el perfil de instancia, SSO, los archivos de configuración/credenciales de AWS ni el servicio de metadatos OAuth de GCP. Una solicitud que pida una de esas fuentes administradas por el servidor (por ejemplo, use_environment_credentials = 1 o http_client = gcp_oauth) sin proporcionar credenciales explícitas válidas se rechaza con ACCESS_DENIED. Una solicitud que no pida ninguna de ellas se envía sin firmar (anónima), igual que si se hubiera indicado NOSIGN.
La asunción de roles de STS basada en role_arn (extra_credentials(role_arn = '...')) sigue permitida incluso cuando esta configuración está deshabilitada: el rol de destino debe confiar explícitamente en la identidad con la que se ejecuta el servidor, y solo las credenciales del rol asumido firman las solicitudes de S3 de la consulta, por lo que las propias credenciales del servidor no se exponen a la consulta. Esta es la forma documentada de conceder a ClickHouse Cloud acceso a un bucket privado. El rol se asume con las propias claves base de la consulta cuando esta proporciona un par completo; de lo contrario, la llamada STS AssumeRole se firma con la identidad implícita del servidor. Las claves estáticas de la configuración <s3>/endpoint del servidor o de una colección con nombre nunca se usan como base de STS para un rol proporcionado por la consulta, y un role_arn configurado en la configuración <s3> del servidor no se aplica en absoluto a las consultas de usuario. Las definiciones dinámicas disk(type=s3, role_arn=...) siguen sujetas a la restricción.
Si una solicitud sin credenciales pide credenciales del entorno se determina mediante use_environment_credentials. Las colecciones con nombre lo establecen en 0 de forma predeterminada, por lo que una colección que solo especifica una URL lee de forma anónima. Las funciones de tabla s3/s3Cluster y los motores S3/S3Queue usan el valor predeterminado incorporado (1) salvo que la configuración <s3> del servidor indique lo contrario; configure <s3><use_environment_credentials>0</use_environment_credentials></s3> para que sus lecturas sin credenciales también sean anónimas de forma predeterminada (de lo contrario, esa solicitud se rechaza y debe usar NOSIGN). Los discos definidos en la configuración del servidor no se ven afectados y siguen usando credenciales del entorno de forma predeterminada; las definiciones dinámicas disk(type = s3, ...) creadas por el usuario sí están sujetas a la restricción (véase arriba) y se rechazan cuando dependen de credenciales predeterminadas/del entorno.
Esto impide que un usuario autenticado haga que el servidor acceda a S3 con sus propias credenciales implícitas. Las credenciales proporcionadas explícitamente no se ven afectadas: las claves pasadas en la consulta, las claves estáticas de una colección con nombre (creada mediante SQL o definida en la configuración) y las claves de la configuración <s3> del servidor siguen funcionando.
La forma recomendada de dar acceso a S3 a las consultas de usuario es una colección con nombre con credenciales explícitas (o NOSIGN para buckets públicos): las claves no aparecen en el texto de la consulta y el uso de cada colección se controla con RBAC (GRANT NAMED COLLECTION ON <name> TO <user>), de modo que se concede a usuarios concretos acceso a buckets concretos en lugar de exponer la propia identidad del servidor.
Alcance (deliberadamente fuera de alcance): esta configuración bloquea solo las fuentes de credenciales implícitas del servidor enumeradas arriba. No bloquea access_key_id/secret_access_key estáticos aprovisionados por el operador desde la configuración <s3> del servidor ni desde una colección con nombre definida en la configuración: se tratan como credenciales explícitas y siguen funcionando. Tenga en cuenta, no obstante, que material de solicitud de la configuración como access_header o claves de cifrado del lado del servidor no se considera por sí solo una credencial en este caso: una solicitud que lleve solo ese material, pero no un par de claves explícitas (y con el valor predeterminado use_environment_credentials = 1), sigue rechazándose, porque de lo contrario recurriría a las credenciales implícitas del servidor. Ese endpoint también debe proporcionar claves explícitas, NOSIGN, use_environment_credentials = 0 o la excepción indicada a continuación.
Un cliente administrativo de confianza puede necesitar credenciales administradas por el servidor para operaciones legítimas (por ejemplo, adjuntar tablas del sistema en un disco s3_plain_rewritable mediante SQL). Habilite esta configuración en la sesión o el perfil de configuración de ese cliente para permitirlo.
Para BACKUP/RESTORE ... ON CLUSTER, el valor de esta configuración del iniciador se propaga a los demás hosts y se utiliza allí sin cambios. Esos hosts ejecutan la continuación de la operación en cada host mediante la cola DDL distribuida, de forma predeterminada sin el usuario del iniciador, por lo que, de otro modo, evaluarían la restricción con respecto a su propio perfil predeterminado; en su lugar, se conserva el valor del iniciador porque este ya ha abierto el mismo destino de backup con su propia configuración restringida. Una restricción readonly en el iniciador sigue aplicándose (un iniciador no confiable no puede habilitar la configuración para su propio backup en el clúster), por lo que esto no debilita la restricción.
Durabilidad de las tablas persistentes S3 y S3Queue: habilitar esto solo por sesión o perfil no es persistente tras un reinicio. Cuando el servidor vuelve a cargar una tabla de este tipo desde su definición almacenada (inicio o RESTORE), reconstruye el cliente de S3 y vuelve a aplicar la restricción con el contexto de inicio, por lo que una tabla que dependía de credenciales administradas por el servidor y que se creó únicamente con una sesión/perfil s3_allow_server_credentials_in_user_queries = 1 se crea correctamente, pero queda inaccesible después de un reinicio (la tabla permanece en su sitio; las consultas contra ella fallan hasta que sus credenciales vuelvan a resolverse a una fuente permitida). El servidor en sí sigue iniciándose. Proporcione credenciales explícitas a esas tablas para un acceso persistente; como alternativa, habilitar la configuración en todo el servidor permite que sigan cargándose tras los reinicios, a costa de relajar la restricción para todas las recargas.
Para mantenerlo deshabilitado para usuarios no confiables, fíjelo en su perfil estableciendo explícitamente el valor en 0 y marcándolo como readonly:
clickhouse-local, donde el usuario es el operador.
Las bases de datos DataLakeCatalog (Glue, BigLake) también se incluyen, con una diferencia. Un objeto de catálogo se crea una sola vez y lo comparten todos los usuarios de la base de datos, por lo que el valor no puede leerse por consulta; se toma de la sesión que ejecuta CREATE DATABASE (o un usuario ATTACH DATABASE). Una base de datos creada mientras esta configuración está habilitada (por ejemplo, en una sesión o perfil de confianza) puede usar las credenciales implícitas del servidor para su catálogo, y entonces las comparte cualquier usuario que pueda consultar esa base de datos; si se crea con el valor predeterminado, el catálogo queda restringido para todos, independientemente de quién la consulte. Cuando el servidor carga una base de datos ya creada desde sus propios metadatos (inicio, RESTORE), la restricción se vuelve a aplicar con el contexto de inicio, igual que para las tablas persistentes S3/S3Queue: un catálogo que obtiene credenciales administradas por el servidor queda no disponible y la base de datos pasa a ser inaccesible después de un reinicio (el servidor sigue arrancando; la base de datos se carga con un catálogo no disponible según s3_load_table_anonymously_if_credentials_restricted, y las consultas informan de la restricción). Un catálogo al que se le proporcionan credenciales explícitas (Glue: aws_access_key_id y aws_secret_access_key; BigLake: un triple ADC completo de Google) funciona en cualquier caso y sigue siendo válido tras el reinicio.