> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-detect-table-modification.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# s3_allow_* セッション設定

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

export const VersionHistory = ({rows = []}) => {
  if (rows.length === 0) {
    return null;
  }
  const headers = ["バージョン", "デフォルト値", "コメント"];
  const border = "1px solid rgba(128, 128, 128, 0.3)";
  const cell = {
    border,
    padding: "0.25rem 0.5rem",
    textAlign: "start",
    verticalAlign: "top"
  };
  return <details className="not-prose" style={{
    border,
    borderRadius: "0.5rem",
    margin: "0.5rem 0",
    padding: "0.5rem 0.75rem",
    fontSize: "0.8125rem",
    lineHeight: "1.125rem"
  }}>
      <summary style={{
    cursor: "pointer",
    fontWeight: 600,
    opacity: 0.72
  }}>
        バージョン履歴
      </summary>
      <table style={{
    borderCollapse: "collapse",
    width: "100%",
    margin: "0.5rem 0 0"
  }}>
        <thead>
          <tr>
            {headers.map(header => <th key={header} style={{
    ...cell,
    fontWeight: 600,
    opacity: 0.72
  }}>
                {header}
              </th>)}
          </tr>
        </thead>
        <tbody>
          {rows.map((row, row_index) => <tr key={row.id ?? row_index}>
              {(row.items ?? []).map((item, item_index) => <td key={item_index} style={{
    ...cell,
    overflowWrap: "anywhere"
  }}>
                  {item?.label}
                </td>)}
            </tr>)}
        </tbody>
      </table>
    </details>;
};

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](/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 アクセスで、サーバー自身の アンビエント認証情報（environment\/IMDS\/IRSA\/instance-profile\/AWS-config-file\/GCP-OAuth-metadata）が解決されないようにする新しい設定です。明示的な role_arn ベースの STS assume-role は引き続き許可されます。以前の動作（許可）は互換性設定で復元できます。"}]}]} />

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

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

```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`) を実行したセッションから取り込まれます。この設定を有効にした状態で作成されたデータベース (たとえば、信頼されたセッションやプロファイルで作成されたもの) は、そのカタログでサーバーの アンビエント認証情報 を使用することがあり、そのデータベースにクエリできるすべてのユーザーがそれを共有することになります。デフォルト設定のまま作成された場合は、だれがクエリするかに関係なく、そのカタログは全員に対して制限されます。サーバーが自身のメタデータから既存のデータベースを読み込む場合 (起動時、`RESTORE`) 、永続的な `S3`/`S3Queue` テーブルと同様に、起動時のコンテキストでその制限が再適用されます。サーバー管理の認証情報 を解決するカタログは利用不可のままとなり、再起動後はそのデータベースにアクセスできなくなります (サーバー自体は起動します。データベースは `s3_load_table_anonymously_if_credentials_restricted` に従って利用不可のカタログを持つものとして読み込まれ、クエリではその制限が報告されます) 。明示的な認証情報が指定されたカタログ (Glue: `aws_access_key_id` と `aws_secret_access_key`、BigLake: 完全な Google ADC の 3 要素) は常に動作し、再起動後も有効です。