> ## 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/ko/reference/system-tables/settings)에서 확인할 수 있으며, [source](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에서 multipart copy를 허용합니다.

<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\/role_arn-STS\/GCP-OAuth-metadata)을 확인하지 못하도록 차단하는 새로운 설정입니다. 이전 동작(허용)은 compatibility 설정으로 복원할 수 있습니다."}]}]} />

사용자 SQL에서 시작된 S3 접근이 서버 관리 자격 증명을 사용하도록 허용합니다.

비활성화된 경우(기본값), `s3`/`s3Cluster` 테이블 함수, `S3`/`S3Queue` 엔진, S3 이름이 지정된 컬렉션, 동적 `disk(type=s3, ...)` 정의, `BACKUP`/`RESTORE TO S3`, DataLake 테이블 데이터 읽기, `DataLakeCatalog` 데이터베이스(Glue, BigLake)는 환경, 인스턴스 메타데이터(IMDS), IRSA, ECS, 인스턴스 프로필, SSO, AWS config/credentials 파일, `role_arn` 기반 STS assume-role, GCP OAuth metadata service에서 자격 증명을 확인할 수 없습니다. 이러한 서버 관리 소스 중 하나를 요청하면서(예: `use_environment_credentials = 1`, `role_arn`, 또는 `http_client = gcp_oauth`) 사용 가능한 명시적 자격 증명을 제공하지 않으면 요청은 `ACCESS_DENIED`로 거부됩니다. 이들 중 어느 것도 요청하지 않으면 요청은 서명 없이(익명으로) 전송되며, 이는 `NOSIGN`을 지정한 경우와 같습니다.

자격 증명이 없는 요청이 환경 자격 증명을 요청하는지는 `use_environment_credentials`로 결정됩니다. 이름이 지정된 컬렉션에서는 기본값이 `0`이므로 URL만 지정한 컬렉션은 익명으로 읽습니다. `s3`/`s3Cluster` 테이블 함수와 `S3`/`S3Queue` 엔진은 서버 `<s3>` 구성이 다르게 설정하지 않는 한 내장 기본값(`1`)을 사용합니다. 이들의 자격 증명 없는 읽기도 기본적으로 익명으로 처리되게 하려면 `<s3><use_environment_credentials>0</use_environment_credentials></s3>`를 설정하십시오(그렇지 않으면 이러한 요청은 거부되며 `NOSIGN`을 사용해야 합니다). 서버 구성에 정의된 디스크는 영향을 받지 않으며 기본적으로 계속 환경 자격 증명을 사용합니다. 사용자가 생성한 동적 `disk(type = s3, ...)` 정의에는 이 제한이 적용되며(위 참조), 기본값/환경 자격 증명에 의존하면 거부됩니다.

이 설정은 인증된 사용자가 서버 자체의 (주변) 자격 증명을 사용해 S3에 접근하도록 서버를 유도하는 것을 방지합니다. 명시적으로 제공된 자격 증명은 영향을 받지 않습니다. 쿼리에서 전달한 키, 이름이 지정된 컬렉션(SQL로 생성되었거나 구성에 정의됨)의 정적 키, 서버 `<s3>` 구성의 키는 모두 계속 사용할 수 있습니다.

사용자 쿼리에 S3 접근 권한을 부여하는 권장 방법은 명시적 자격 증명이 포함된 이름이 지정된 컬렉션을 사용하는 것입니다(또는 public buckets에는 `NOSIGN`). 이렇게 하면 키가 쿼리 텍스트에 노출되지 않으며, 각 컬렉션의 사용은 RBAC(`GRANT NAMED COLLECTION ON <name> TO <user>`)로 제어되므로 서버 자체의 자격 증명을 노출하는 대신 특정 사용자에게 특정 버킷만 부여할 수 있습니다.

범위(의도적으로 범위에서 제외): 이 설정은 위에 나열된 서버의 주변 자격 증명 소스만 차단합니다. 서버 `<s3>` 구성 또는 구성에 정의된 이름이 지정된 컬렉션의 운영자가 프로비저닝한 정적 `access_key_id`/`secret_access_key`는 차단하지 않습니다. 이들은 명시적 자격 증명으로 취급되며 계속 작동합니다. 다만 `access_header` 또는 서버 측 암호화 키와 같은 구성 요청 자료는 그 자체만으로는 여기서 자격 증명으로 취급되지 않습니다. 이러한 자료만 포함하고 명시적 키 쌍은 없는 요청은(기본 `use_environment_credentials = 1`인 경우) 여전히 거부됩니다. 그렇지 않으면 서버의 주변 자격 증명으로 대체되기 때문입니다. 이러한 엔드포인트는 명시적 키, `NOSIGN`, `use_environment_credentials = 0`, 또는 아래에 설명된 예외 수단도 제공해야 합니다.

신뢰할 수 있는 관리용 클라이언트는 정당한 작업을 위해 서버 관리 자격 증명이 필요할 수 있습니다(예: SQL을 통해 `s3_plain_rewritable` 디스크의 system tables를 attach하는 경우). 이를 허용하려면 해당 클라이언트의 세션 또는 설정 프로필에서 이 설정을 활성화하십시오.

`BACKUP`/`RESTORE ... ON CLUSTER`의 경우 이 설정의 initiator 값은 다른 hosts로 전파되어 그대로 사용됩니다. 이들 hosts는 기본적으로 initiator의 사용자 없이 분산 DDL 큐를 통해 작업의 호스트별 후속 단계를 실행하므로, 그렇지 않으면 각자의 default profile을 기준으로 이 제한을 평가하게 됩니다. 대신 initiator의 값이 유지되는데, 이는 initiator가 이미 동일한 backup destination을 자신의 제한된 설정으로 열었기 때문입니다. initiator의 `readonly` 제약은 여전히 적용되므로(신뢰할 수 없는 initiator는 자신의 on-cluster backup에 대해 이 설정을 활성화할 수 없음) 이로 인해 제한이 약화되지는 않습니다.

영구적인 `S3` 및 `S3Queue` 테이블의 내구성: 이 설정을 세션 또는 프로필별로만 활성화하면 재시작 후에는 유지되지 않습니다. 서버가 저장된 정의에서 이러한 테이블을 다시 로드할 때(시작 시 또는 `RESTORE`) S3 클라이언트를 다시 구성하고 시작 Context로 제한을 다시 적용하므로, 서버 관리 자격 증명에 의존하고 세션/프로필 `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)에도 동일하게 적용되지만, 한 가지 차이점이 있습니다. catalog 객체는 한 번 생성되면 해당 데이터베이스의 모든 사용자가 공유하므로, 그 값을 쿼리별로 읽어 올 수는 없습니다. 대신 `CREATE DATABASE`(또는 사용자가 `ATTACH DATABASE`를 수행할 때)를 실행한 session에서 값이 캡처됩니다. 이 설정이 활성화된 상태에서 생성된 데이터베이스(예: 신뢰된 session 또는 profile에서 생성된 경우)는 해당 catalog에 서버의 주변 자격 증명을 사용할 수 있으며, 이후 그 데이터베이스를 쿼리할 수 있는 모든 사용자가 이를 공유하게 됩니다. 반대로 기본 설정으로 생성된 경우에는 누가 쿼리하든 관계없이 catalog가 모든 사용자에게 제한됩니다. 서버가 자체 metadata에서 이미 생성된 데이터베이스를 로드할 때(시작 시, `RESTORE`)는 영속적인 `S3`/`S3Queue` table과 마찬가지로 시작 Context를 기준으로 이 제한이 다시 적용됩니다. 즉, 서버 관리 자격 증명으로 확인되는 catalog는 계속 사용할 수 없는 상태로 남고, 그 결과 재시작 후에는 해당 데이터베이스에 접근할 수 없게 됩니다(서버 자체는 계속 시작되며, 데이터베이스는 `s3_load_table_anonymously_if_credentials_restricted`에 따라 사용할 수 없는 catalog와 함께 로드되고, 쿼리에는 이 제한이 표시됩니다). 반면 명시적인 자격 증명(Glue: `aws_access_key_id` 및 `aws_secret_access_key`, BigLake: 완전한 Google ADC 3요소 세트)이 지정된 catalog는 이와 무관하게 정상적으로 작동하며 재시작 후에도 유지됩니다.