s3_allow_multipart_copy
s3_allow_parallel_part_upload
s3_allow_server_credentials_in_user_queries
s3/s3Cluster table function、S3/S3Queue エンジン、S3 named collection、動的な disk(type=s3, ...) 定義、BACKUP/RESTORE TO S3、DataLake の table-data read、および DataLakeCatalog データベース (Glue、BigLake) は、環境、インスタンスメタデータ (IMDS) 、IRSA、ECS、instance profile、SSO、AWS config/credentials files、または GCP OAuth metadata service から 認証情報 を解決できません。これらの server-managed source のいずれか (たとえば use_environment_credentials = 1 または http_client = gcp_oauth) を要求しながら、使用可能な明示的 認証情報 を指定していないリクエストは、ACCESS_DENIED で拒否されます。これらを一切要求しないリクエストは、NOSIGN を指定した場合と同様に、署名なし (anonymous) で送信されます。
role_arn ベースの STS assume-role (extra_credentials(role_arn = '...')) は、この設定が無効でも引き続き許可されます。対象の role はサーバーが実行される identity を明示的に信頼する必要があり、クエリの S3 リクエストに署名するのは常に assume された role の認証情報だけであるため、サーバー自身の認証情報がクエリに公開されることはありません。これは、ClickHouse Cloud に private bucket へのアクセスを許可するための文書化された方法です。クエリが完全な pair を指定する場合、role はクエリ自身の base keys で assume されます。それ以外の場合、STS AssumeRole 呼び出しはサーバーの ambient identity によって署名されます。サーバー <s3>/endpoint config または named collection の静的なオプションが、クエリ指定の role の STS base として使用されることはなく、サーバー <s3> config で設定された role_arn はユーザークエリには一切適用されません。動的な disk(type=s3, role_arn=...) 定義は引き続きこの制限の対象です。
認証情報 を持たないリクエストが environment 認証情報 を要求するかどうかは、use_environment_credentials によって決まります。named collection ではデフォルト値が 0 のため、URL だけを指定した collection は匿名で読み取られます。s3/s3Cluster table function と S3/S3Queue エンジンは、サーバーの <s3> config で別途設定されていない限り、組み込みのデフォルト値 (1) を使用します。認証情報 なしの read もデフォルトで匿名にしたい場合は、<s3><use_environment_credentials>0</use_environment_credentials></s3> を設定してください (そうしない場合、そのようなリクエストは拒否され、NOSIGN を使う必要があります) 。server configuration で定義されたディスクは影響を受けず、引き続きデフォルトで environment 認証情報 を使用します。一方、ユーザーが作成した動的な disk(type = s3, ...) 定義はこの制限の対象となり (上記参照) 、デフォルト値または environment 認証情報 に依存している場合は拒否されます。
これにより、authenticated user がサーバー自身の (アンビエント認証情報) を使って S3 にアクセスさせることを防げます。明示的に指定された 認証情報 は影響を受けません。クエリで渡されたオプション、named collection 内の静的なオプション (SQL で作成されたもの、または config で定義されたもの) 、およびサーバー <s3> config 内のオプションは、引き続き機能します。
ユーザークエリに S3 アクセスを許可する推奨方法は、明示的 認証情報 を持つ named collection (または public buckets 用の NOSIGN) を使うことです。これにより、オプションをクエリテキストに含めずに済み、各 collection の利用は RBAC (GRANT NAMED COLLECTION ON <name> TO <user>) で制御されるため、サーバー自身の identity を公開する代わりに、特定のユーザーに特定の bucket へのアクセスだけを許可できます。
スコープ (意図的に対象外) : この設定がブロックするのは、上記に挙げたサーバーの ambient credential sources のみです。サーバー <s3> config や、config で定義された named collection にある、オペレーターがプロビジョニングした静的な access_key_id/secret_access_key はブロックしません。これらは明示的 認証情報 として扱われ、引き続き機能します。ただし、access_header や server-side-encryption keys のような config のリクエスト情報は、それ自体ではここで 認証情報 とは見なされない点に注意してください。そのような情報だけを持ち、明示的な key pair を持たないリクエストは (かつデフォルトの use_environment_credentials = 1 の場合) 、そうでないとサーバーの アンビエント認証情報 にフォールバックしてしまうため、引き続き拒否されます。そのような endpoint では、明示的オプション、NOSIGN、use_environment_credentials = 0、または以下の escape hatch も指定する必要があります。
信頼できる管理クライアントでは、正当な操作のために サーバー管理の認証情報 が必要になる場合があります (たとえば、SQL を介して s3_plain_rewritable ディスク上のシステムテーブルをアタッチする場合) 。これを許可するには、そのクライアントのセッションまたは設定プロファイルでこの設定を有効にしてください。
BACKUP/RESTORE ... ON CLUSTER では、この設定のイニシエーター側の値が他のホストに伝播され、そこでそのまま使用されます。これらのホストは、デフォルトではイニシエーターのユーザーを使用せず、分散 DDL キューを介して操作のホストごとの継続処理を実行します。そのため、通常は各ホスト自身のデフォルトプロファイルに対して制限を評価します。しかし、イニシエーターはすでに自身の制限付き設定で同じバックアップ宛先を開いているため、代わりにイニシエーターの値が保持されます。イニシエーターに対する readonly 制約は引き続き適用されるため (信頼できないイニシエーターは自身のオン クラスター バックアップに対してこの設定を有効にできません) 、この動作によって制限が弱まることはありません。
永続的な S3 および S3Queue テーブルの耐久性: これをセッション単位またはプロファイル単位でのみ有効にしても、再起動後には維持されません。サーバーがそのようなテーブルを保存済みの定義 (起動時または RESTORE 時) から再読み込みすると、S3 クライアントを再構築し、起動時のコンテキストで制限を再適用します。そのため、サーバー管理の認証情報 に依存し、セッション/プロファイルの s3_allow_server_credentials_in_user_queries = 1 のもとでのみ作成されたテーブルは、作成自体は成功しても、再起動後はアクセスできなくなります (テーブル自体はそのまま残りますが、認証情報が再び許可されたソースに解決されるまで、そのテーブルに対するクエリは失敗します) 。サーバー自体は引き続き起動します。このようなテーブルに永続的なアクセスを確保するには、明示的な認証情報を指定してください。あるいは、この設定をサーバー全体で有効にすると、すべての再読み込みで制限が緩和される代わりに、再起動後もそれらのテーブルが読み込まれるようになります。
信頼できないユーザーに対してこれを無効のままにしておくには、値を明示的に 0 に設定し、さらに readonly としてマークして、そのプロファイルに固定してください:
clickhouse-local では効果がありません。
DataLakeCatalog データベース (Glue、BigLake) も対象ですが、1 つだけ違いがあります。カタログオブジェクトは一度作成されると、そのデータベースのすべてのユーザーで共有されるため、値をクエリごとに読み取ることはできません。代わりに、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 の 3 要素) は常に動作し、再起動後も有効です。