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、role_arn ベースの STS assume-role、または GCP OAuth metadata service から 認証情報 を解決できません。これらの server-managed source のいずれか (たとえば use_environment_credentials = 1、role_arn、または http_client = gcp_oauth) を要求しながら、使用可能な明示的 認証情報 を指定していないリクエストは、ACCESS_DENIED で拒否されます。これらを一切要求しないリクエストは、NOSIGN を指定した場合と同様に、署名なし (anonymous) で送信されます。
認証情報 を持たないリクエストが 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 がサーバー自身の (ambient) 認証情報 を使って 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 の場合) 、そうでないとサーバーの ambient 認証情報 にフォールバックしてしまうため、引き続き拒否されます。そのような endpoint では、明示的オプション、NOSIGN、use_environment_credentials = 0、または以下の escape hatch も指定する必要があります。
信頼された管理クライアントでは、正当な操作のために server-managed 認証情報 が必要になる場合があります (たとえば、s3_plain_rewritable ディスク上のシステムテーブルを SQL 経由で attach する場合) 。そのようなクライアントの session または settings profile でこの設定を有効にすると、それが許可されます。
BACKUP/RESTORE ... ON CLUSTER では、この設定のイニシエーターの値が他の hosts に伝播され、そこでそのまま使われます。これらの hosts は、デフォルトではイニシエーターの USER なしで distributed DDL queue を通じて操作のホストごとの継続処理を実行するため、そうでなければこの制限をそれぞれ自分自身の default profile に対して評価することになります。しかし、イニシエーターはすでに同じ backup destination を自身の制限付き settings で開いているため、代わりにその値が維持されます。イニシエーターに対する readonly 制約は引き続き適用されるため (信頼されていないイニシエーターは、自身の on-cluster backup のためにこの設定を有効化できません) 、この挙動によって制限が弱まることはありません。
永続的な S3 および S3Queue テーブルの耐久性: これをセッション単位またはプロファイル単位でのみ有効にしても、再起動後には維持されません。サーバーがそのようなテーブルを保存済みの定義 (起動時または RESTORE 時) から再読み込みすると、S3 クライアントを再構築し、起動時のコンテキストで制限を再適用します。そのため、server-managed credentials に依存し、セッション/プロファイルの s3_allow_server_credentials_in_user_queries = 1 のもとでのみ作成されたテーブルは、作成自体は成功しても、再起動後はアクセスできなくなります (テーブル自体はそのまま残りますが、認証情報が再び許可されたソースに解決されるまで、そのテーブルに対するクエリは失敗します) 。サーバー自体は引き続き起動します。このようなテーブルに永続的なアクセスを確保するには、明示的な認証情報を指定してください。あるいは、この設定をサーバー全体で有効にすると、すべての再読み込みで制限が緩和される代わりに、再起動後もそれらのテーブルが読み込まれるようになります。
信頼できないユーザーに対してこれを無効のままにしておくには、値を明示的に 0 に設定し、さらに readonly としてマークして、そのプロファイルに固定してください:
clickhouse-local では効果がありません。
DataLakeCatalog データベース (Glue、BigLake) も対象ですが、1 つだけ違いがあります。カタログオブジェクトは一度作成されると、そのデータベースのすべてのユーザーで共有されるため、値をクエリごとに読み取ることはできません。代わりに、CREATE DATABASE (またはユーザーによる ATTACH DATABASE) を実行したセッションから取り込まれます。この設定を有効にした状態で作成されたデータベース (たとえば、信頼されたセッションやプロファイルで作成されたもの) は、そのカタログでサーバーの ambient credentials を使用することがあり、そのデータベースにクエリできるすべてのユーザーがそれを共有することになります。デフォルト設定のまま作成された場合は、だれがクエリするかに関係なく、そのカタログは全員に対して制限されます。サーバーが自身のメタデータから既存のデータベースを読み込む場合 (起動時、RESTORE) 、永続的な S3/S3Queue テーブルと同様に、起動時のコンテキストでその制限が再適用されます。server-managed credentials を解決するカタログは利用不可のままとなり、再起動後はそのデータベースにアクセスできなくなります (サーバー自体は起動します。データベースは s3_load_table_anonymously_if_credentials_restricted に従って利用不可のカタログを持つものとして読み込まれ、クエリではその制限が報告されます) 。明示的な認証情報が指定されたカタログ (Glue: aws_access_key_id と aws_secret_access_key、BigLake: 完全な Google ADC の 3 要素) は常に動作し、再起動後も有効です。