> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# s3_allow_* セッション設定

> s3_allow_* 生成グループに含まれる ClickHouse のセッション設定。

export const SettingsInfoBlock = ({type, default_value, changeable_without_restart}) => {
  return <div className="not-prose" style={{
    display: "flex",
    flexWrap: "wrap",
    alignItems: "baseline",
    columnGap: "0.5rem",
    rowGap: "0.125rem",
    margin: "0.375rem 0",
    fontSize: "0.8125rem",
    lineHeight: "1.125rem"
  }}>
      <div style={{
    fontWeight: 600,
    opacity: 0.72
  }}>型</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{type}</div>
      <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>デフォルト値</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{default_value}</div>
      {changeable_without_restart && <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>
          再起動せずに変更可能
        </div>}
      {changeable_without_restart && <div style={{
    overflowWrap: "anywhere"
  }}>
          {changeable_without_restart}
        </div>}
    </div>;
};

これらの設定は [system.settings](/docs/ja/reference/system-tables/settings) で参照でき、[ソースコード](https://github.com/ClickHouse/ClickHouse/blob/master/src/Core/Settings.cpp) から自動生成されています。

<div id="s3_allow_multipart_copy">
  ## s3\_allow\_multipart\_copy
</div>

<SettingsInfoBlock type="Bool" default_value="1" />

<VersionHistory rows={[{"id": "row-1","items": [{"label": "25.2"},{"label": "1"},{"label": "新しい設定"}]}]} />

S3 でのマルチパートコピーを有効にします。

<div id="s3_allow_parallel_part_upload">
  ## s3\_allow\_parallel\_part\_upload
</div>

<SettingsInfoBlock type="Bool" default_value="1" />

S3 のマルチパートアップロードで複数のスレッドを使用します。これにより、メモリ使用量がわずかに増加する場合があります

<div id="s3_allow_server_credentials_in_user_queries">
  ## s3\_allow\_server\_credentials\_in\_user\_queries
</div>

<SettingsInfoBlock type="Bool" default_value="0" />

<VersionHistory rows={[{"id": "row-1","items": [{"label": "26.7"},{"label": "0"},{"label": "ユーザー SQL からの S3 アクセスで、サーバー自身の ambient 認証情報（environment\/IMDS\/IRSA\/instance-profile\/AWS-config-file\/role_arn-STS\/GCP-OAuth-metadata）が解決されないようにする新しい設定です。以前の動作（許可）は互換性設定で復元できます。"}]}]} />

ユーザー SQL に起因する S3 アクセスで、server-managed 認証情報 の使用を許可します。

無効時 (デフォルト) には、`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` としてマークして、そのプロファイルに固定してください:

```xml theme={null}
<profiles>
    <untrusted>
        <!-- The explicit value is required: a `readonly` constraint alone only blocks direct changes,
             but `compatibility` with a version before this setting was introduced would otherwise
             restore the old (allowing) default. Setting the value explicitly defeats `compatibility`. -->
        <s3_allow_server_credentials_in_user_queries>0</s3_allow_server_credentials_in_user_queries>
        <constraints>
            <s3_allow_server_credentials_in_user_queries>
                <readonly/>
            </s3_allow_server_credentials_in_user_queries>
        </constraints>
    </untrusted>
</profiles>
```

この設定は、ユーザーがオペレーターとなる `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 要素) は常に動作し、再起動後も有効です。