s3_allow_multipart_copy
s3_allow_parallel_part_upload
s3_allow_server_credentials_in_user_queries
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:
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.