These settings are available in system.settings and are autogenerated from source.
s3_allow_multipart_copy
Allow multipart copy in S3.
s3_allow_parallel_part_upload
Use multiple threads for s3 multipart upload. It may lead to slightly higher memory usage
s3_allow_server_credentials_in_user_queries
Allow S3 access that originates from user SQL to use server-managed credentials.
When disabled (the default), the s3/s3Cluster table functions, the S3/S3Queue engines, S3 named collections, dynamic disk(type=s3, ...) definitions, BACKUP/RESTORE TO S3, DataLake table-data reads, and DataLakeCatalog databases (Glue, BigLake) may not resolve credentials from the environment, instance metadata (IMDS), IRSA, ECS, instance profile, SSO, AWS config/credentials files, role_arn-based STS assume-role, or the GCP OAuth metadata service. A request that asks for one of those server-managed sources (for example use_environment_credentials = 1, a role_arn, or http_client = gcp_oauth) without supplying usable explicit credentials is rejected with ACCESS_DENIED. A request that asks for none of them is sent unsigned (anonymous), the same as if NOSIGN had been given.
Whether a credential-less request asks for environment credentials is decided by use_environment_credentials. Named collections default it to 0, so a collection that only specifies a URL reads anonymously. The s3/s3Cluster table functions and S3/S3Queue engines use the built-in default (1) unless the server <s3> config sets it otherwise; set <s3><use_environment_credentials>0</use_environment_credentials></s3> to make their credential-less reads anonymous by default too (otherwise such a request is refused and must use NOSIGN). Disks defined in the server configuration are unaffected and keep using environment credentials by default; user-created dynamic disk(type = s3, ...) definitions are covered by the restriction (see above) and are rejected when they rely on default/environment credentials.
This prevents an authenticated user from making the server access S3 with its own (ambient) credentials. Credentials supplied explicitly are not affected: keys passed in the query, static keys in a named collection (created via SQL or defined in config), and keys in the server <s3> config all keep working.
The recommended way to give user queries S3 access is a named collection with explicit credentials (or NOSIGN for public buckets): the keys stay out of the query text, and use of each collection is controlled with RBAC (GRANT NAMED COLLECTION ON <name> TO <user>), so you grant specific users specific buckets instead of exposing the server’s own identity.
Scope (out of scope on purpose): this setting blocks only the server’s ambient credential sources listed above. It does not block operator-provisioned static access_key_id/secret_access_key from the server <s3> config or from a config-defined named collection: those are treated as explicit credentials and keep working. Note, however, that config request material such as access_header or server-side-encryption keys is not by itself treated as a credential here: a request that carries only such material but no explicit key pair (and the default use_environment_credentials = 1) is still refused, because it would otherwise fall back to the server’s ambient credentials. Such an endpoint must also provide explicit keys, NOSIGN, use_environment_credentials = 0, or the escape hatch below.
A trusted administrative client may need server-managed credentials for legitimate operations (for example, attaching system tables on an s3_plain_rewritable disk via SQL). Enable this setting in that client’s session or settings profile to permit it.
For BACKUP/RESTORE ... ON CLUSTER the initiator’s value of this setting is propagated to the other hosts and used there as-is. Those hosts run the per-host continuation of the operation through the distributed DDL queue, by default without the initiator’s user, so they would otherwise evaluate the restriction against their own default profile; the initiator’s value is preserved instead, because it has already opened the same backup destination under its own, constrained, settings. A readonly constraint on the initiator still applies (an untrusted initiator cannot enable the setting for its own on-cluster backup), so this does not weaken the restriction.
Durability for persistent S3 and S3Queue tables: enabling this only per session or profile is not durable across a restart. When the server reloads such a table from its stored definition (startup or RESTORE) it rebuilds the S3 client and re-applies the restriction with the startup context, so a table that relied on server-managed credentials and was created only under a session/profile s3_allow_server_credentials_in_user_queries = 1 is created successfully but becomes inaccessible after a restart (the table is left in place; queries against it fail until its credentials resolve to a permitted source again). The server itself still starts. Give such tables explicit credentials for durable access; alternatively, enabling the setting server-wide keeps them loading across restarts, at the cost of relaxing the restriction for all reloads.
To keep it disabled for untrusted users, pin it in their profile by both setting the value explicitly to 0 and marking it readonly:
This setting has no effect in clickhouse-local, where the user is the operator.
DataLakeCatalog databases (Glue, BigLake) are also covered, with one difference. A catalog object is created once and shared by every user of the database, so the value cannot be read per query; it is captured from the session that runs CREATE DATABASE (or a user ATTACH DATABASE). A database created while this setting is enabled (for example in a trusted session or profile) may use the server’s ambient credentials for its catalog, and every user able to query that database then shares them; created under the default, the catalog is restricted for everyone regardless of who queries it. When the server loads an already-created database from its own metadata (startup, RESTORE) the restriction is re-applied with the startup context, the same as for persistent S3/S3Queue tables: a catalog that resolves server-managed credentials is left unavailable and the database becomes inaccessible after a restart (the server still starts; the database loads with an unavailable catalog per s3_load_table_anonymously_if_credentials_restricted, and queries report the restriction). A catalog given explicit credentials (Glue: aws_access_key_id and aws_secret_access_key; BigLake: a complete Google ADC triple) works regardless and is durable across restart. Last modified on July 23, 2026
