s3_allow_server_credentials_for_system_table_disks
system データベース内のテーブルの動的な disk(type = s3, ...) が、s3_allow_server_credentials_in_user_queries の制限の適用対象外として、サーバー自身の 環境由来 な
S3 認証情報を使用できるようにします。これは、サーバーの identity を使ってシステムテーブルを S3 に送る
サーバー内部のインフラストラクチャ (cloud operator により system データベースに attached されるもの) 向けです。session 設定とは異なり、これは
server-level setting であるため、再起動時にテーブルがメタデータから再読み込みされた場合にも、この適用対象外は有効です。適用範囲は system
データベースに限定されており、通常のユーザーはそこにテーブルを作成できないため、ユーザークエリに対する制限が緩和されることはありません。
s3_credentials_provider_max_cache_size
s3_load_table_anonymously_if_credentials_restricted
S3 または S3Queue テーブル、動的な disk(type = s3, ...)、または
DataLakeCatalog (Glue、BigLake) データベースを既存のメタデータ (サーバー起動時または RESTORE 時) から読み込む際に、
その定義が s3_allow_server_credentials_in_user_queries によってユーザークエリでの使用を禁止されている
サーバー自身の (周囲環境から取得される) S3/クラウド認証情報に解決される場合の動作を制御します。
有効な場合 (デフォルト) 、起動を中断する代わりに、そのオブジェクトはそれらの認証情報なしで読み込まれます。つまり、
S3/S3Queue テーブルまたは動的な S3 disk は匿名 S3 client で構築され、
DataLakeCatalog データベースは利用できない catalog を持つ状態のままになります。サーバーは起動しますが、
そのオブジェクトにはアクセスできません (private bucket への requests は拒否されるか、catalog が明確な error を報告します) 。
認証情報が再び許可された取得元に解決されるようになるまで、この状態は続きます。サーバーの identity を
知らないうちに取り戻すことは決してありません。これにより、そのような単一のオブジェクト ― たとえば制限が存在する前の
古い version で作成されたものや、後からその named collection が
use_environment_credentials = 1 に再バインドされたもの ― によって、
サーバーの起動全体が中断されるのを防げます。
無効にすると、そのようなオブジェクトの読み込みは失敗し、サーバーが起動できなくなる可能性があります。
table、disk、または catalog データベースが気付かないうちにアクセス不能になるよりも、明確に失敗するほうを望む場合にのみ使用してください。