> ## 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.

# configurações de sessão s3_allow_*

> Configurações de sessão do ClickHouse no grupo s3_allow_* gerado automaticamente.

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
  }}>Tipo</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{type}</div>
      <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>Padrão</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{default_value}</div>
      {changeable_without_restart && <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>
          Pode ser alterado sem reiniciar
        </div>}
      {changeable_without_restart && <div style={{
    overflowWrap: "anywhere"
  }}>
          {changeable_without_restart}
        </div>}
    </div>;
};

Estas configurações estão disponíveis em [system.settings](/docs/pt-BR/reference/system-tables/settings) e são geradas automaticamente a partir do [código-fonte](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": "Nova configuração."}]}]} />

Permite cópia em múltiplas partes no S3.

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

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

Usa várias threads no upload multipart do S3. Isso pode resultar em uso de memória ligeiramente maior

<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": "Nova configuração para bloquear o acesso ao S3 a partir de SQL do usuário de resolver as próprias credenciais de ambiente do servidor (environment\/IMDS\/IRSA\/instance-profile\/AWS-config-file\/role_arn-STS\/GCP-OAuth-metadata). O comportamento anterior (permitido) é restaurado com configurações de compatibilidade."}]}]} />

Permite que o acesso ao S3 originado de SQL do usuário use credenciais gerenciadas pelo servidor.

Quando desabilitado (o padrão), as funções de tabela `s3`/`s3Cluster`, os motores `S3`/`S3Queue`, as named collections de S3, as definições dinâmicas de `disk(type=s3, ...)`, `BACKUP`/`RESTORE TO S3`, as leituras de dados de tabela do DataLake e os bancos de dados `DataLakeCatalog` (Glue, BigLake) não podem resolver credenciais do ambiente, dos metadados da instância (IMDS), do IRSA, ECS, perfil da instância, SSO, arquivos de config/credenciais da AWS, STS assume-role baseado em `role_arn` ou do serviço de metadados OAuth do GCP. Uma solicitação que peça uma dessas fontes gerenciadas pelo servidor (por exemplo, `use_environment_credentials = 1`, um `role_arn` ou `http_client = gcp_oauth`) sem fornecer credenciais explícitas utilizáveis é rejeitada com `ACCESS_DENIED`. Uma solicitação que não peça nenhuma delas é enviada sem assinatura (anônima), da mesma forma que se `NOSIGN` tivesse sido fornecido.

Se uma solicitação sem credenciais pede credenciais de ambiente é algo determinado por `use_environment_credentials`. As named collections o definem como `0` por padrão, então uma collection que especifica apenas uma URL lê anonimamente. As funções de tabela `s3`/`s3Cluster` e os motores `S3`/`S3Queue` usam o padrão interno (`1`), a menos que a config `<s3>` do servidor o defina de outra forma; defina `<s3><use_environment_credentials>0</use_environment_credentials></s3>` para fazer com que as leituras sem credenciais também sejam anônimas por padrão (caso contrário, essa solicitação é recusada e deve usar `NOSIGN`). Discos definidos na configuração do servidor não são afetados e continuam usando credenciais de ambiente por padrão; definições dinâmicas de `disk(type = s3, ...)` criadas pelo usuário são cobertas pela restrição (veja acima) e são rejeitadas quando dependem de credenciais padrão/de ambiente.

Isso impede que um usuário autenticado faça o servidor acessar o S3 com suas próprias credenciais de ambiente. As credenciais fornecidas explicitamente não são afetadas: chaves passadas na consulta, chaves estáticas em uma named collection (criada via SQL ou definida na config) e chaves na config `<s3>` do servidor continuam funcionando.

A forma recomendada de conceder acesso ao S3 para consultas de usuário é usar uma named collection com credenciais explícitas (ou `NOSIGN` para public buckets): as chaves ficam fora do texto da consulta, e o uso de cada collection é controlado com RBAC (`GRANT NAMED COLLECTION ON <name> TO <user>`), assim você concede a usuários específicos buckets específicos em vez de expor a identidade do próprio servidor.

Escopo (deliberadamente fora do escopo): esta configuração bloqueia apenas as fontes de credenciais de ambiente do servidor listadas acima. Ela não bloqueia `access_key_id`/`secret_access_key` estáticos provisionados pelo operador a partir da config `<s3>` do servidor ou de uma named collection definida em config: eles são tratados como credenciais explícitas e continuam funcionando. Observe, no entanto, que material de solicitação da config, como `access_header` ou chaves de criptografia server-side, não é, por si só, tratado aqui como credencial: uma solicitação que carregue apenas esse material, mas nenhum par de chaves explícito (e o padrão `use_environment_credentials = 1`), ainda será recusada, porque, de outra forma, recorreria às credenciais de ambiente do servidor. Esse endpoint também deve fornecer chaves explícitas, `NOSIGN`, `use_environment_credentials = 0` ou a exceção abaixo.

Um client administrativo confiável pode precisar de credenciais gerenciadas pelo servidor para operações legítimas (por exemplo, anexar system tables em um disco `s3_plain_rewritable` via SQL). Habilite esta configuração na sessão desse client ou no perfil de configurações para permitir isso.

Para `BACKUP`/`RESTORE ... ON CLUSTER`, o valor dessa configuração no initiator é propagado para os outros hosts e usado neles como está. Esses hosts executam a continuação da operação por host por meio da fila de DDL distribuído, por padrão sem o usuário do initiator, então, de outra forma, eles avaliariam a restrição em relação ao próprio perfil padrão; em vez disso, o valor do initiator é preservado, porque ele já abriu o mesmo backup destination com suas próprias configurações restritas. Uma restrição `readonly` no initiator ainda se aplica (um initiator não confiável não pode habilitar a configuração para seu próprio backup on-cluster), então isso não enfraquece a restrição.

Durabilidade de tabelas persistentes `S3` e `S3Queue`: habilitar isso apenas por sessão ou perfil não resiste a uma reinicialização. Quando o servidor recarrega uma tabela desse tipo a partir da definição armazenada (na inicialização ou em `RESTORE`), ele recria o client do S3 e reaplica a restrição com o contexto de inicialização. Assim, uma tabela que dependia de credenciais gerenciadas pelo servidor e foi criada apenas em uma sessão/perfil com `s3_allow_server_credentials_in_user_queries = 1` é criada com sucesso, mas se torna inacessível após uma reinicialização (a tabela permanece no lugar; as consultas a ela falham até que as credenciais voltem a ser resolvidas para uma origem permitida). O próprio servidor continua iniciando normalmente. Forneça a essas tabelas credenciais explícitas para garantir acesso persistente; como alternativa, habilitar a configuração no servidor inteiro faz com que elas continuem sendo carregadas após reinicializações, ao custo de afrouxar a restrição para todos os recarregamentos.

Para mantê-la desabilitada para usuários não confiáveis, fixe-a no perfil deles definindo explicitamente o valor como `0` e marcando-a como `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>
```

Esta configuração não tem efeito no `clickhouse-local`, em que o usuário é o operador.

Os bancos de dados `DataLakeCatalog` (Glue, BigLake) também são abrangidos, com uma diferença. Um objeto de catálogo é criado uma única vez e compartilhado por todos os usuários do banco de dados, portanto o valor não pode ser lido por consulta; ele é capturado da sessão que executa `CREATE DATABASE` (ou por um usuário com `ATTACH DATABASE`). Um banco de dados criado enquanto esta configuração está habilitada (por exemplo, em uma sessão ou perfil confiável) pode usar as credenciais de ambiente do servidor para seu catálogo, e todos os usuários capazes de consultar esse banco de dados então as compartilham; se for criado com o padrão, o catálogo ficará restrito para todos, independentemente de quem o consultar. Quando o servidor carrega um banco de dados já criado a partir de seus próprios metadados (inicialização, `RESTORE`), a restrição é reaplicada com o contexto de inicialização, da mesma forma que para tabelas persistentes `S3`/`S3Queue`: um catálogo que resolve credenciais gerenciadas pelo servidor permanece indisponível, e o banco de dados se torna inacessível após uma reinicialização (o servidor ainda inicia; o banco de dados é carregado com um catálogo indisponível conforme `s3_load_table_anonymously_if_credentials_restricted`, e as consultas relatam a restrição). Um catálogo ao qual são fornecidas credenciais explícitas (Glue: `aws_access_key_id` e `aws_secret_access_key`; BigLake: uma tripla completa do Google ADC) funciona independentemente disso e permanece estável após a reinicialização.