ClickHouse/docs/es/operations/access_rights.md
Ivan Blinkov f315e5079b
More complete "es" translation (#9791)
* replace exit with assert in test_single_page

* improve save_raw_single_page docs option

* More grammar fixes

* "Built from" link in new tab

* fix mistype

* Example of include in docs

* add anchor to meeting form

* Draft of translation helper

* WIP on translation helper

* Replace some fa docs content with machine translation

* add normalize-en-markdown.sh

* normalize some en markdown

* normalize some en markdown

* admonition support

* normalize

* normalize

* normalize

* support wide tables

* normalize

* normalize

* normalize

* normalize

* normalize

* normalize

* normalize

* normalize

* normalize

* normalize

* normalize

* normalize

* normalize

* lightly edited machine translation of introdpection.md

* lightly edited machhine translation of lazy.md

* WIP on translation utils

* Normalize ru docs

* Normalize other languages

* some fixes

* WIP on normalize/translate tools

* add requirements.txt

* [experimental] add es docs language as machine translated draft

* remove duplicate script

* Back to wider tab-stop (narrow renders not so well)

* Links to nowhere check at least for English

* use f string

* More complete es translation
2020-03-21 12:17:06 +03:00

6.7 KiB

Derechos de acceso

Los usuarios y los derechos de acceso se configuran en la configuración del usuario. Esto suele ser users.xml.

Los usuarios se registran en el users apartado. Aquí hay un fragmento de la users.xml file:

<!-- Users and ACL. -->
<users>
    <!-- If the user name is not specified, the 'default' user is used. -->
    <default>
        <!-- Password could be specified in plaintext or in SHA256 (in hex format).

             If you want to specify password in plaintext (not recommended), place it in 'password' element.
             Example: <password>qwerty</password>.
             Password could be empty.

             If you want to specify SHA256, place it in 'password_sha256_hex' element.
             Example: <password_sha256_hex>65e84be33532fb784c48129675f9eff3a682b27168c0ea744b2cf58ee02337c5</password_sha256_hex>

             How to generate decent password:
             Execute: PASSWORD=$(base64 < /dev/urandom | head -c8); echo "$PASSWORD"; echo -n "$PASSWORD" | sha256sum | tr -d '-'
             In first line will be password and in second - corresponding SHA256.
        -->
        <password></password>

        <!-- A list of networks that access is allowed from.
            Each list item has one of the following forms:
            <ip> The IP address or subnet mask. For example: 198.51.100.0/24 or 2001:DB8::/32.
            <host> Host name. For example: example01. A DNS query is made for verification, and all addresses obtained are compared with the address of the customer.
            <host_regexp> Regular expression for host names. For example, ^example\d\d-\d\d-\d\.host\.ru$
                To check it, a DNS PTR request is made for the client's address and a regular expression is applied to the result.
                Then another DNS query is made for the result of the PTR query, and all received address are compared to the client address.
                We strongly recommend that the regex ends with \.host\.ru$.

            If you are installing ClickHouse yourself, specify here:
                <networks>
                        <ip>::/0</ip>
                </networks>
        -->
        <networks incl="networks" />

        <!-- Settings profile for the user. -->
        <profile>default</profile>

        <!-- Quota for the user. -->
        <quota>default</quota>
    </default>

    <!-- For requests from the Yandex.Metrica user interface via the API for data on specific counters. -->
    <web>
        <password></password>
        <networks incl="networks" />
        <profile>web</profile>
        <quota>default</quota>
        <allow_databases>
           <database>test</database>
        </allow_databases>
        <allow_dictionaries>
           <dictionary>test</dictionary>
        </allow_dictionaries>
    </web>
</users>

Puede ver una declaración de dos usuarios: defaultyweb. Hemos añadido el web usuario por separado.

El default usuario se elige en los casos en que no se pasa el nombre de usuario. El default usuario también se utiliza para el procesamiento de consultas distribuidas, si la configuración del servidor o clúster no user y password (véase la sección sobre el Distribuido motor).

El usuario que se utiliza para intercambiar información entre servidores combinados en un clúster no debe tener restricciones o cuotas sustanciales; de lo contrario, las consultas distribuidas fallarán.

La contraseña se especifica en texto sin cifrar (no recomendado) o en SHA-256. El hash no es salado. En este sentido, no debe considerar estas contraseñas como proporcionar seguridad contra posibles ataques maliciosos. Más bien, son necesarios para la protección de los empleados.

Se especifica una lista de redes desde las que se permite el acceso. En este ejemplo, la lista de redes para ambos usuarios se carga desde un archivo independiente (/etc/metrika.xml) que contiene el networks sustitución. Aquí hay un fragmento de eso:

<yandex>
    ...
    <networks>
        <ip>::/64</ip>
        <ip>203.0.113.0/24</ip>
        <ip>2001:DB8::/32</ip>
        ...
    </networks>
</yandex>

Puede definir esta lista de redes directamente en users.xml o en un archivo en el users.d (para obtener más información, consulte la sección “Archivos de configuración”).

La configuración incluye comentarios que explican cómo abrir el acceso desde todas partes.

Para su uso en producción, sólo especifique ip elementos (direcciones IP y sus máscaras), ya que usan host y hoost_regexp podría causar latencia adicional.

A continuación se especifica el perfil de configuración de usuario (consulte la sección “Perfiles de configuración”. Puede especificar el perfil predeterminado, default'. El perfil puede tener cualquier nombre. Puede especificar el mismo perfil para diferentes usuarios. Lo más importante que puede escribir en el perfil de configuración es readonly=1, que asegura el acceso de sólo lectura. A continuación, especifique la cuota que se utilizará (consulte la sección “Cuota”). Puede especificar la cuota predeterminada: default. Se establece en la configuración de forma predeterminada para contar solo el uso de recursos, sin restringirlo. La cuota puede tener cualquier nombre. Puede especificar la misma cuota para diferentes usuarios; en este caso, el uso de recursos se calcula para cada usuario individualmente.

En el opcional <allow_databases> sección, también puede especificar una lista de bases de datos a las que el usuario puede acceder. De forma predeterminada, todas las bases de datos están disponibles para el usuario. Puede especificar el default base. En este caso, el usuario recibirá acceso a la base de datos de forma predeterminada.

En el opcional <allow_dictionaries> sección, también puede especificar una lista de diccionarios a los que el usuario puede acceder. De forma predeterminada, todos los diccionarios están disponibles para el usuario.

Acceso a la system base de datos siempre está permitida (ya que esta base de datos se utiliza para procesar consultas).

El usuario puede obtener una lista de todas las bases de datos y tablas en ellos mediante el uso de SHOW Consultas o tablas del sistema, incluso si no se permite el acceso a bases de datos individuales.

El acceso a la base de datos no está sólo lectura configuración. No puede conceder acceso completo a una base de datos y readonly acceso a otro.

Artículo Original