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

# ajustes de sesión s3_allow_*

> Ajustes de sesión de ClickHouse en el grupo generado s3_allow_*.

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"
  }}>Predeterminado</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{default_value}</div>
      {changeable_without_restart && <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>
          Modificable sin reiniciar
        </div>}
      {changeable_without_restart && <div style={{
    overflowWrap: "anywhere"
  }}>
          {changeable_without_restart}
        </div>}
    </div>;
};

Estas configuraciones están disponibles en [system.settings](/docs/es/reference/system-tables/settings) y se autogeneran a partir del [código fuente](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": "Nueva configuración."}]}]} />

Permite realizar copias multiparte en S3.

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

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

Usa varios hilos para la carga multiparte de S3. Puede provocar un uso de memoria ligeramente mayor

<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": "Nueva configuración para impedir que el acceso a S3 desde SQL de usuario resuelva las propias credenciales implícitas del servidor (environment\/IMDS\/IRSA\/instance-profile\/AWS-config-file\/role_arn-STS\/GCP-OAuth-metadata). El comportamiento anterior (permitido) se restablece con la configuración de compatibilidad."}]}]} />

Permite que el acceso a S3 originado desde SQL de usuario use credenciales administradas por el servidor.

Cuando está deshabilitado (valor predeterminado), las funciones de tabla `s3`/`s3Cluster`, los motores `S3`/`S3Queue`, las colecciones con nombre de S3, las definiciones dinámicas `disk(type=s3, ...)`, `BACKUP`/`RESTORE TO S3`, las lecturas de datos de tablas de DataLake y las bases de datos `DataLakeCatalog` (Glue, BigLake) no pueden resolver credenciales desde el entorno, los metadatos de instancia (IMDS), IRSA, ECS, el perfil de instancia, SSO, los archivos de configuración/credenciales de AWS, la asunción de roles de STS basada en `role_arn` ni el servicio de metadatos OAuth de GCP. Una solicitud que pida una de esas fuentes administradas por el servidor (por ejemplo, `use_environment_credentials = 1`, un `role_arn` o `http_client = gcp_oauth`) sin proporcionar credenciales explícitas válidas se rechaza con `ACCESS_DENIED`. Una solicitud que no pida ninguna de ellas se envía sin firmar (anónima), igual que si se hubiera indicado `NOSIGN`.

Si una solicitud sin credenciales pide credenciales del entorno se determina mediante `use_environment_credentials`. Las colecciones con nombre lo establecen en `0` de forma predeterminada, por lo que una colección que solo especifica una URL lee de forma anónima. Las funciones de tabla `s3`/`s3Cluster` y los motores `S3`/`S3Queue` usan el valor predeterminado incorporado (`1`) salvo que la configuración `<s3>` del servidor indique lo contrario; configure `<s3><use_environment_credentials>0</use_environment_credentials></s3>` para que sus lecturas sin credenciales también sean anónimas de forma predeterminada (de lo contrario, esa solicitud se rechaza y debe usar `NOSIGN`). Los discos definidos en la configuración del servidor no se ven afectados y siguen usando credenciales del entorno de forma predeterminada; las definiciones dinámicas `disk(type = s3, ...)` creadas por el usuario sí están sujetas a la restricción (véase arriba) y se rechazan cuando dependen de credenciales predeterminadas/del entorno.

Esto impide que un usuario autenticado haga que el servidor acceda a S3 con sus propias credenciales implícitas. Las credenciales proporcionadas explícitamente no se ven afectadas: las claves pasadas en la consulta, las claves estáticas de una colección con nombre (creada mediante SQL o definida en la configuración) y las claves de la configuración `<s3>` del servidor siguen funcionando.

La forma recomendada de dar acceso a S3 a las consultas de usuario es una colección con nombre con credenciales explícitas (o `NOSIGN` para buckets públicos): las claves no aparecen en el texto de la consulta y el uso de cada colección se controla con RBAC (`GRANT NAMED COLLECTION ON <name> TO <user>`), de modo que se concede a usuarios concretos acceso a buckets concretos en lugar de exponer la propia identidad del servidor.

Alcance (deliberadamente fuera de alcance): esta configuración bloquea solo las fuentes de credenciales implícitas del servidor enumeradas arriba. No bloquea `access_key_id`/`secret_access_key` estáticos aprovisionados por el operador desde la configuración `<s3>` del servidor ni desde una colección con nombre definida en la configuración: se tratan como credenciales explícitas y siguen funcionando. Tenga en cuenta, no obstante, que material de solicitud de la configuración como `access_header` o claves de cifrado del lado del servidor no se considera por sí solo una credencial en este caso: una solicitud que lleve solo ese material, pero no un par de claves explícitas (y con el valor predeterminado `use_environment_credentials = 1`), sigue rechazándose, porque de lo contrario recurriría a las credenciales implícitas del servidor. Ese endpoint también debe proporcionar claves explícitas, `NOSIGN`, `use_environment_credentials = 0` o la excepción indicada a continuación.

Un client administrativo de confianza puede necesitar credenciales administradas por el servidor para operaciones legítimas (por ejemplo, adjuntar system tables en un disco `s3_plain_rewritable` mediante SQL). Habilite esta configuración en la sesión o el perfil de configuración de ese client para permitirlo.

Para `BACKUP`/`RESTORE ... ON CLUSTER`, el valor de esta configuración en el initiator se propaga a los demás hosts y se usa allí tal cual. Esos hosts ejecutan la continuación por host de la operación a través de la cola de DDL distribuido, de forma predeterminada sin el usuario del initiator, por lo que de otro modo evaluarían la restricción con respecto a su propio default profile; en su lugar, se conserva el valor del initiator, porque ya ha abierto el mismo backup destination con su propia configuración restringida. Una restricción `readonly` en el initiator sigue aplicándose (un initiator no fiable no puede habilitar la configuración para su propio backup on-cluster), por lo que esto no debilita la restricción.

Durabilidad de las tablas persistentes `S3` y `S3Queue`: habilitar esto solo por sesión o perfil no es persistente tras un reinicio. Cuando el servidor vuelve a cargar una tabla de este tipo desde su definición almacenada (inicio o `RESTORE`), reconstruye el cliente de S3 y vuelve a aplicar la restricción con el contexto de inicio, por lo que una tabla que dependía de credenciales administradas por el servidor y que se creó únicamente con una sesión/perfil `s3_allow_server_credentials_in_user_queries = 1` se crea correctamente, pero queda inaccesible después de un reinicio (la tabla permanece en su sitio; las consultas contra ella fallan hasta que sus credenciales vuelvan a resolverse a una fuente permitida). El servidor en sí sigue iniciándose. Proporcione credenciales explícitas a esas tablas para un acceso persistente; como alternativa, habilitar la configuración en todo el servidor permite que sigan cargándose tras los reinicios, a costa de relajar la restricción para todas las recargas.

Para mantenerlo deshabilitado para usuarios no confiables, fíjelo en su perfil estableciendo explícitamente el valor en `0` y marcándolo 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 configuración no tiene efecto en `clickhouse-local`, donde el usuario es el operador.

Las bases de datos `DataLakeCatalog` (Glue, BigLake) también se incluyen, con una diferencia. Un objeto de catálogo se crea una sola vez y lo comparten todos los usuarios de la base de datos, por lo que el valor no puede leerse por consulta; se toma de la sesión que ejecuta `CREATE DATABASE` (o un usuario `ATTACH DATABASE`). Una base de datos creada mientras esta configuración está habilitada (por ejemplo, en una sesión o perfil de confianza) puede usar las credenciales implícitas del servidor para su catálogo, y entonces las comparte cualquier usuario que pueda consultar esa base de datos; si se crea con el valor predeterminado, el catálogo queda restringido para todos, independientemente de quién la consulte. Cuando el servidor carga una base de datos ya creada desde sus propios metadatos (inicio, `RESTORE`), la restricción se vuelve a aplicar con el contexto de inicio, igual que para las tablas persistentes `S3`/`S3Queue`: un catálogo que obtiene credenciales administradas por el servidor queda no disponible y la base de datos pasa a ser inaccesible después de un reinicio (el servidor sigue arrancando; la base de datos se carga con un catálogo no disponible según `s3_load_table_anonymously_if_credentials_restricted`, y las consultas informan de la restricción). Un catálogo al que se le proporcionan credenciales explícitas (Glue: `aws_access_key_id` y `aws_secret_access_key`; BigLake: un triple ADC completo de Google) funciona en cualquier caso y sigue siendo válido tras el reinicio.