Saltar a contenidoSaltar a navegación de páginas: página anterior [tecla acceso p]/página siguiente [tecla acceso n]
ContenidoContenido
Guía de administración
  1. Acerca de esta guía
  2. I Gestión en clúster
    1. 1 Privilegios de usuario y comandos de símbolos del sistema
    2. 2 Administración de un clúster de Salt
    3. 3 Copia de seguridad de la configuración y los datos del clúster
  3. II Funcionamiento de un clúster
    1. 4 Introducción
    2. 5 Gestión de los servicios de Ceph
    3. 6 Determinación del estado del clúster
    4. 7 Supervisión y alertas
    5. 8 Autenticación con cephx
    6. 9 Gestión de datos almacenados
    7. 10 Módulos de Ceph Manager
    8. 11 Gestión de repositorios de almacenamiento
    9. 12 Dispositivo de bloques RADOS
    10. 13 Repositorios codificados de borrado
    11. 14 Niveles de caché
    12. 15 Mejora del rendimiento con el caché de LVM
    13. 16 Configuración del clúster de Ceph
  4. III Acceso a los datos del clúster
    1. 17 Ceph Object Gateway
    2. 18 Ceph iSCSI Gateway
    3. 19 Sistema de archivos con agrupación en clúster
    4. 20 Exportación de datos de Ceph a través de Samba
    5. 21 NFS Ganesha: exportación de datos de Ceph a través de NFS
  5. IV Gestión del clúster con herramientas de interfaz gráfica de usuario
    1. 22 Ceph Dashboard
  6. V Integración con herramientas de virtualización
    1. 23 Uso de libvirt con Ceph
    2. 24 Ceph como procesador final para la instancia de QEMU KVM
  7. VI Preguntas frecuentes, consejos y solución de problemas
    1. 25 Consejos y sugerencias
    2. 26 Preguntas más frecuentes
    3. 27 Solución de problemas
  8. A Ejemplo personalizado de la fase 1 de DeepSea
  9. B Alertas por defecto para SUSE Enterprise Storage 6
  10. C Actualizaciones de mantenimiento de Ceph basadas en versiones secundarias superiores de Nautilus
  11. Glosario
  12. D Actualizaciones de la documentación
Navegación
Se aplica a SUSE Enterprise Storage 6

8 Autenticación con cephx Edit source

Para identificar a los clientes y protegerlos frente a ataques de tipo "man-in-the-middle", Ceph proporciona su propio sistema de autenticación: cephx. En este contexto, los clientes son usuarios humanos (por ejemplo, el usuario administrador) o servicios/daemons relacionados con Ceph (por ejemplo, los OSD, los monitores o las pasarelas Object Gateway).

Nota
Nota

El protocolo cephx no se hace cargo del cifrado de datos durante el transporte, como SSL/TLS.

8.1 Arquitectura de autenticación Edit source

cephx utiliza claves de secreto compartido para la autenticación, lo que significa que tanto el cliente como monitores Ceph Monitor tienen una copia de la clave de secreto del cliente. El protocolo de autenticación permite a ambas partes probarse entre sí que disponen de una copia de la clave sin revelarla. Esto proporciona autenticación mutua, lo que significa que el clúster está seguro de que el usuario posee la clave de secreto, y el usuario está seguro de que el clúster también tiene una copia.

Una característica fundamental para la capacidad de ampliación de Ceph es que se evita una interfaz centralizada en el almacén de objetos de Ceph. Esto significa que los clientes de Ceph pueden interactuar directamente con los OSD. Para proteger los datos, Ceph proporciona su propio sistema de autenticación, cephx, que autentica a los clientes de Ceph.

Cada monitor puede autenticar a los clientes y distribuir claves, por lo que no hay un punto único de error ni cuellos de botella cuando se utiliza cephx. El monitor devuelve una estructura de datos de autenticación que contiene una clave de sesión que se usará para obtener los servicios de Ceph. Esta clave de sesión está cifrada a su vez con la clave de secreto permanente del cliente, de forma que solo el cliente puede pedir servicios de los monitores de Ceph. El cliente utiliza entonces la clave de sesión para pedir los servicios que desea del monitor, y el monitor proporciona al cliente un ticket que autenticará al cliente en los OSD donde se gestionan realmente los datos. Los monitores de Ceph y los OSD comparten un secreto, por lo que el cliente puede utilizar el ticket proporcionado por el monitor con cualquier OSD o servidor de metadatos del clúster. Los tickets de cephx caducan, por lo que un atacante no puede utilizar un ticket caducado ni una clave de sesión que haya obtenido de forma fraudulenta.

Para utilizar cephx, un administrador debe configurar primero clientes o usuarios. En el siguiente diagrama, el usuario client.admin invoca ceph auth get-o-create-key en la línea de comandos para generar un nombre de usuario y una clave de secreto. El subsistema auth de Ceph genera el nombre de usuario y la clave, almacena una copia con los monitores y transmite el secreto del usuario de nuevo al usuario client.admin. Esto significa que el cliente y el monitor comparten una clave de secreto.

Autenticación básica con cephx
Figura 8.1: Autenticación básica con cephx

Para autenticarse con el monitor, el cliente pasa el nombre de usuario al monitor. El monitor genera una clave de sesión, la cifra con la clave de secreto asociada con el nombre de usuario y transmite el ticket cifrado de vuelta al cliente. El cliente descifra los datos con la clave de secreto compartida para recuperar la clave de sesión. La clave de sesión identifica al usuario para la sesión actual. A continuación, el cliente pide un ticket relacionado con el usuario, que está firmado por la clave de sesión. El monitor genera un ticket, lo cifra con la clave de secreto del usuario y lo transmite al cliente. El cliente descifra el ticket y lo utiliza para firmar las peticiones a los OSD y los servidores de metadatos en todo el clúster.

Autenticación con cephx
Figura 8.2: Autenticación con cephx

El protocolo cephx autentica continuamente las comunicaciones entre el equipo del cliente y los servidores de Ceph. Cada mensaje que se envía entre un cliente y un servidor después de la autenticación inicial se firma con un ticket que los monitores, los OSD y los servidores de metadatos pueden verificar con su secreto compartido.

Autenticación con cephx: servidor de metadatos y OSD
Figura 8.3: Autenticación con cephx: servidor de metadatos y OSD
Importante
Importante

La protección que ofrece esta autenticación se produce entre el cliente de Ceph y los hosts del clúster de Ceph. La autenticación no se extiende más allá del cliente de Ceph. Si el usuario accede al cliente de Ceph desde un host remoto, la autenticación de Ceph no se aplica a la conexión entre el host del usuario y el host del cliente.

8.2 Gestión de claves Edit source

En esta sección se describen los usuarios del cliente de Ceph, así como su autenticación y autorización con el clúster de almacenamiento de Ceph. Los usuarios son personas o actores del sistema, como aplicaciones, que utilizan los clientes de Ceph para interactuar con los daemons del clúster de almacenamiento de Ceph.

Cuando se ejecuta Ceph con la autenticación y la autorización habilitadas (lo están por defecto), debe especificar un nombre de usuario y un anillo de claves que contenga la clave de secreto del usuario especificado (por lo general, a través de la línea de comandos). Si no especifica un nombre de usuario, Ceph usará client.admin como nombre de usuario por defecto. Si no especifica un anillo de claves, Ceph buscará un anillo de claves mediante el valor correspondiente del archivo de configuración de Ceph. Por ejemplo, si ejecuta el comando ceph health sin especificar un nombre de usuario o un anillo de claves, Ceph interpreta el comando así:

cephadm@adm > ceph -n client.admin --keyring=/etc/ceph/ceph.client.admin.keyring health

Si lo prefiere, puede utilizar la variable de entorno CEPH_ARGS para evitar tener que introducir de nuevo el nombre de usuario y el secreto.

8.2.1 Información básica Edit source

Independientemente del tipo de cliente de Ceph (por ejemplo, un dispositivo de bloques, almacenamiento de objetos, sistema de archivos o API nativa), Ceph almacena todos los datos como objetos en repositorios. Los usuarios de Ceph necesitan tener acceso a los repositorios a fin de poder leer y escribir los datos. Además, los usuarios de Ceph deben tener permisos de ejecución para usar los comandos de administración de Ceph. Los siguientes conceptos le ayudarán a comprender mejor la gestión de usuarios de Ceph.

8.2.1.1 Usuario Edit source

Un usuario es una persona o un actor del sistema, como una aplicación. Crear usuarios permite controlar quién (o qué) puede acceder a su clúster de almacenamiento de Ceph, sus repositorios y los datos de los repositorios.

Ceph usa tipos de usuarios. Para la gestión de los usuarios, el tipo siempre será cliente. Ceph identifica a los usuarios con un formato delimitado por punto (.), formado por el tipo de usuario y el ID de usuario. Por ejemplo, TYPE.ID, client.admin o client.user1. Este formato se usa porque los monitores de Ceph, los OSD y los servidores de metadatos también utilizan el protocolo cephx, pero no son clientes. Distinguir el tipo de usuario ayuda a diferenciar entre los usuarios cliente y otros usuarios, además de optimizar el control de acceso, la supervisión del usuario y el seguimiento.

A veces, el tipo de usuario de Ceph puede parecer confuso, ya que la línea de comandos de Ceph permite especificar un usuario con o sin el tipo, dependiendo del uso que se haga de la línea de comandos. Si especifica ‑‑user o ‑‑id, puede omitir el tipo. Por lo tanto, client.user1 se puede introducir simplemente como user1. Si especifica ‑‑name o -no, debe especificar el tipo y el nombre, como client.user1. Se recomienda usar el tipo y el nombre como práctica recomendada siempre que sea posible.

Nota
Nota

Un usuario de clúster de almacenamiento de Ceph no es lo mismo que un usuario de almacenamiento de objetos de Ceph ni un usuario de sistema de archivos de Ceph. Ceph Object Gateway utiliza un usuario de clúster de almacenamiento de Ceph para la comunicación entre el daemon de pasarela y el clúster de almacenamiento, pero la pasarela tiene sus propias funciones de gestión de usuarios para los usuarios finales. El sistema de archivos de Ceph utiliza la semántica de POSIX. El espacio de usuarios asociado a ese sistema no es igual que un usuario de clúster de almacenamiento de Ceph.

8.2.1.2 Autorización y permisos Edit source

Ceph usa el término permisos (caps, o "capabilities" en inglés) para describir la autorización de un usuario autenticado para que pueda trabajar con los monitores, los OSD y los servidores de metadatos. Los permisos también pueden restringir el acceso a los datos de un repositorio o a un espacio de nombres de repositorio. Un usuario administrativo de Ceph define los permisos del usuario cuando lo crea o lo actualiza.

La sintaxis de los permisos sigue este formato:

daemon-type 'allow capability' [...]

A continuación encontrará una lista de permisos para cada tipo de servicio:

Permisos de monitor

Incluye r, w, x y allow profile permiso.

mon 'allow rwx'
mon 'allow profile osd'
Permisos de OSD

Incluye r, w, x, class-read, class-write y profile osd. Además, los permisos de OSD también permiten configurar el repositorio y el espacio de nombres.

osd 'allow capability' [pool=poolname] [namespace=namespace-name]
Permiso de servidor de metadatos

Solo es allow o se deja vacío.

mds 'allow'

Las siguientes entradas describen cada permiso:

allow

Precede a la configuración de acceso para un daemon. Implica rw solo para el servidor de metadatos.

r

Proporciona al usuario acceso de lectura. Es necesario para que los monitores puedan recuperar el mapa de CRUSH.

w

Proporciona al usuario acceso de escritura a los objetos.

x

Proporciona al usuario el permiso para llamar a métodos de clase (tanto de lectura como de escritura) y para llevar a cabo operaciones auth en los monitores.

class-read

Proporciona al usuario el permiso para llamar a métodos de lectura de clase. Subconjunto de x.

class-write

Proporciona al usuario el permiso para llamar a métodos de escritura de clase. Subconjunto de x.

*

Proporciona al usuario permisos de lectura, escritura y ejecución para un daemon o repositorio concreto, así como la capacidad de ejecutar comandos de administración.

profile osd

Proporciona a un usuario permiso para conectarse como un OSD a otros OSD o monitores. Se otorga en los OSD para permitirles gestionar el tráfico de subejecución de réplica y la elaboración de informes de estado.

profile mds

Proporciona a un usuario permiso para conectarse como un servidor de metadatos a otros servidores de metadatos o monitores.

profile bootstrap-osd

Proporciona a un usuario permisos para cargar un OSD. Se delega a las herramientas de distribución para que tengan permisos para añadir claves cuando se carga un OSD.

profile bootstrap-mds

Proporciona a un usuario permisos para cargar un servidor de metadatos. Se delega a las herramientas de distribución para que tengan permisos para añadir claves cuando se carga un servidor de metadatos.

8.2.1.3 Repositorios Edit source

Un repositorio es una partición lógica donde los usuarios almacenan los datos. En distribuciones de Ceph, es común crear un repositorio como una partición lógica para tipos similares de datos. Por ejemplo, al distribuir Ceph como procesador final para OpenStack, una distribución típica tendría repositorios para los volúmenes, las imágenes, las copias de seguridad, las máquinas virtuales y los usuarios como client.glance o client.cinder.

8.2.2 Gestión de usuarios Edit source

La funcionalidad de gestión de usuarios proporciona a los administradores de clústeres de Ceph la capacidad de crear, actualizar y suprimir usuarios directamente en el clúster de Ceph.

Al crear o suprimir usuarios en el clúster de Ceph, puede ser necesario distribuir claves a los clientes para que se puedan añadir a anillos de claves. Para obtener más información, consulte: Sección 8.2.3, “Gestión de anillos de claves”.

8.2.2.1 Listas de usuarios Edit source

Para obtener una lista de los usuarios del clúster, ejecute lo siguiente:

cephadm@adm > ceph auth list

Ceph mostrará a todos los usuarios del clúster. Por ejemplo, en un clúster de dos nodos, ceph auth list da como resultado algo parecido a esto:

installed auth entries:

osd.0
        key: AQCvCbtToC6MDhAATtuT70Sl+DymPCfDSsyV4w==
        caps: [mon] allow profile osd
        caps: [osd] allow *
osd.1
        key: AQC4CbtTCFJBChAAVq5spj0ff4eHZICxIOVZeA==
        caps: [mon] allow profile osd
        caps: [osd] allow *
client.admin
        key: AQBHCbtT6APDHhAA5W00cBchwkQjh3dkKsyPjw==
        caps: [mds] allow
        caps: [mon] allow *
        caps: [osd] allow *
client.bootstrap-mds
        key: AQBICbtTOK9uGBAAdbe5zcIGHZL3T/u2g6EBww==
        caps: [mon] allow profile bootstrap-mds
client.bootstrap-osd
        key: AQBHCbtT4GxqORAADE5u7RkpCN/oo4e5W0uBtw==
        caps: [mon] allow profile bootstrap-osd
Nota
Nota: notación TYPE.ID

Tenga en cuenta que se aplica la notación TYPE.ID para los usuarios, de forma que osd.0 especifica un usuario de tipo osd cuyo ID es 0. client.admin es un usuario de tipo client cuyo ID es admin. Tenga en cuenta también que cada entrada tiene una entrada key: valor y una o más entradas caps:.

Puede utilizar la opción -o nombre de archivo con ceph auth list para guardar el resultado en un archivo.

8.2.2.2 Obtención de información sobre los usuarios Edit source

Para recuperar información de un usuario, una clave y permisos concretos, ejecute lo siguiente:

cephadm@adm > ceph auth get TYPE.ID

Por ejemplo:

cephadm@adm > ceph auth get client.admin
exported keyring for client.admin
[client.admin]
	key = AQA19uZUqIwkHxAAFuUwvq0eJD4S173oFRxe0g==
	caps mds = "allow"
	caps mon = "allow *"
 caps osd = "allow *"

Los desarrolladores también pueden ejecutar lo siguiente:

cephadm@adm > ceph auth export TYPE.ID

El comando auth export es idéntico al comando auth get, pero también imprime el ID de autenticación interno.

8.2.2.3 Adición de usuarios Edit source

Al añadir un usuario, se crea un nombre de usuario (TYPE.ID), una clave de secreto y cualquier permiso incluido en el comando que se utiliza para crear el usuario.

La clave del usuario permite a este autenticarse con el clúster de almacenamiento de Ceph. Los permisos del usuario autorizan a este a leer, escribir o ejecutar en los monitores de Ceph (mon), los OSD de Ceph (osd) o los servidores de metadatos de Ceph (mds).

Hay varios comandos disponibles para añadir un usuario:

ceph auth add

Este comando es la manera canónica de añadir un usuario. Crea el usuario, genera una clave y añade cualquier permiso especificado.

ceph auth get-or-create

Este comando suele ser la forma más cómoda de crear un usuario, ya que devuelve un formato de archivo de clave con el nombre de usuario (entre corchetes) y la clave. Si el usuario ya existe, este comando simplemente devuelve el nombre de usuario y la clave con formato de archivo de clave. Puede utilizar la opción -o nombre de archivo para guardar el resultado en un archivo.

ceph auth get-or-create-key

Este comando es un método sencillo de crear un usuario y devolver (solo) la clave del usuario. Resulta útil para clientes que solo necesitan la clave (por ejemplo, libvirt). Si el usuario ya existe, este comando solo devuelve la clave. Puede utilizar la opción -o nombre de archivo para guardar el resultado en un archivo.

Cuando se crean usuarios de cliente, puede crear un usuario sin permisos. Un usuario sin permisos puede autenticarse, pero nada más. Un cliente de este tipo no puede recuperar el mapa del clúster del monitor. Sin embargo, puede crear un usuario sin permisos si desea añadir los permisos más tarde con el comando ceph auth caps.

Un usuario típico tiene al menos el permiso de lectura en el monitor de Ceph y de lectura y escritura en los OSD de Ceph. Además, los permisos de OSD de un usuario a menudo están restringidos al acceso a un repositorio concreto.

cephadm@adm > ceph auth add client.john mon 'allow r' osd \
 'allow rw pool=liverpool'
cephadm@adm > ceph auth get-or-create client.paul mon 'allow r' osd \
 'allow rw pool=liverpool'
cephadm@adm > ceph auth get-or-create client.george mon 'allow r' osd \
 'allow rw pool=liverpool' -o george.keyring
cephadm@adm > ceph auth get-or-create-key client.ringo mon 'allow r' osd \
 'allow rw pool=liverpool' -o ringo.key
Importante
Importante

Si proporciona a un usuario permisos para los OSD, pero no restringe el acceso a repositorios concretos, el usuario tendrá acceso a todos los repositorios del clúster.

8.2.2.4 Modificación de los permisos de usuario Edit source

El comando ceph auth caps permite especificar un usuario y cambiar sus permisos. Al definir nuevos permisos, se sobrescribirán los existentes. Para ver los permisos actuales, ejecute ceph auth get USERTYPE.USERID. Para añadir permisos, también debe especificar los permisos existentes con el formato siguiente:

cephadm@adm > ceph auth caps USERTYPE.USERID daemon 'allow [r|w|x|*|...] \
     [pool=pool-name] [namespace=namespace-name]' [daemon 'allow [r|w|x|*|...] \
     [pool=pool-name] [namespace=namespace-name]']

Por ejemplo:

cephadm@adm > ceph auth get client.john
cephadm@adm > ceph auth caps client.john mon 'allow r' osd 'allow rw pool=prague'
cephadm@adm > ceph auth caps client.paul mon 'allow rw' osd 'allow r pool=prague'
cephadm@adm > ceph auth caps client.brian-manager mon 'allow *' osd 'allow *'

Para eliminar un permiso, puede restablecerlo. Si desea que el usuario no tenga acceso a un daemon concreto que se ha definido previamente, especifique una cadena vacía:

cephadm@adm > ceph auth caps client.ringo mon ' ' osd ' '

8.2.2.5 Supresión de usuarios Edit source

Para suprimir un usuario, utilice ceph auth del:

cephadm@adm > ceph auth del TYPE.ID

donde TYPE es client, osd, mon o mds, e ID es el nombre del usuario o el ID del daemon.

Si ha creado usuarios con permisos estrictamente para un repositorio que ya no existe, plantéese también la posibilidad de suprimir dichos usuarios.

8.2.2.6 Impresión de la clave de un usuario Edit source

Para imprimir la clave de autenticación de un usuario con una salida estándar, ejecute lo siguiente:

cephadm@adm > ceph auth print-key TYPE.ID

donde TYPE es client, osd, mon o mds, e ID es el nombre del usuario o el ID del daemon.

Imprimir la clave de un usuario resulta útil si necesita completar el software de cliente con la clave de un usuario (por ejemplo, libvirt), tal y como se muestra en el siguiente ejemplo:

root # mount -t ceph host:/ mount_point \
-o name=client.user,secret=`ceph auth print-key client.user`

8.2.2.7 Importación de usuarios Edit source

Para importar uno o varios usuarios, utilice ceph auth import y especifique un anillo de claves:

cephadm@adm > ceph auth import -i /etc/ceph/ceph.keyring
Nota
Nota

El clúster de almacenamiento de Ceph añadirá los nuevos usuarios, sus claves y sus permisos, además de actualizar los usuarios existentes, sus claves y sus permisos.

8.2.3 Gestión de anillos de claves Edit source

Si accede a Ceph a través de un cliente de Ceph, el cliente buscará un anillo de claves local. Ceph incluye cuatro nombres de anillos de claves por defecto, por lo que no es necesario definirlos en el archivo de configuración de Ceph, a menos que desee sustituir esos valores por defecto:

/etc/ceph/cluster.name.keyring
/etc/ceph/cluster.keyring
/etc/ceph/keyring
/etc/ceph/keyring.bin

La metavariable cluster es el nombre de su clúster de Ceph definido en el archivo de configuración de Ceph. ceph.conf significa que el nombre del clúster es ceph, como en ceph.keyring. La metavariable name es el tipo de usuario y el ID de usuario; por ejemplo, client.admin, como en ceph.client.admin.keyring.

Después de crear un usuario (por ejemplo, client.ringo), debe obtener la clave y añadirla a un anillo de claves en un cliente de Ceph para que el usuario pueda acceder el clúster de almacenamiento de Ceph.

En la Sección 8.2, “Gestión de claves” se detalla cómo mostrar una lista de usuario y obtener, añadir, modificar y suprimir usuarios directamente en el clúster de almacenamiento de Ceph. Sin embargo, Ceph también proporciona la utilidad ceph-authtool, que permite gestionar anillos de claves desde un cliente de Ceph.

8.2.3.1 Creación de un anillo de claves Edit source

Cuando se utilizan los procedimientos de la Sección 8.2, “Gestión de claves” para crear usuarios, debe proporcionar las claves de usuario a los clientes de Ceph para que puedan recuperar la clave para el usuario especificado y autenticarse con el clúster de almacenamiento de Ceph. Los clientes de Ceph acceden a los anillos de claves para buscar un nombre de usuario y recuperar la clave del usuario:

cephadm@adm > ceph-authtool --create-keyring /path/to/keyring

Cuando se crea un anillo de claves con varios usuarios, es recomendable utilizar el nombre del clúster (por ejemplo cluster.keyring) para el nombre de archivo del anillo de claves y guardarlo en el directorio /etc/ceph. De esta forma, la configuración por defecto del anillo de claves tomará el nombre de archivo sin que sea necesario especificarlo en la copia local del archivo de configuración de Ceph. Por ejemplo, para crear ceph.keyring, ejecute lo siguiente:

cephadm@adm > ceph-authtool -C /etc/ceph/ceph.keyring

Cuando se crea un anillo de claves con un solo usuario, se recomienda usar el nombre del clúster, el tipo de usuario y el nombre de usuario y guardarlo en el directorio /etc/ceph. Por ejemplo, ceph.client.admin.keyring para el usuario client.admin.

8.2.3.2 Adición de un usuario a un anillo de claves Edit source

Cuando se añade un usuario al clúster de almacenamiento de Ceph (consulte la Sección 8.2.2.3, “Adición de usuarios”), puede recuperar el usuario, la clave y los permisos, y guardar el usuario en un anillo de claves.

Si solo desea utilizar un usuario por anillo de claves, el comando ceph auth get con la opción -o guardará el resultado en el formato de archivo del anillo de claves. Por ejemplo, para crear un anillo de claves para el usuario client.admin, ejecute lo siguiente:

cephadm@adm > ceph auth get client.admin -o /etc/ceph/ceph.client.admin.keyring

Si desea importar usuarios en un anillo de claves, puede utilizar ceph-authtool para especificar el anillo de claves de destino y el anillo de claves de origen:

cephadm@adm > ceph-authtool /etc/ceph/ceph.keyring \
  --import-keyring /etc/ceph/ceph.client.admin.keyring

8.2.3.3 Creación de un usuario Edit source

Ceph proporciona el comando ceph auth add para crear un usuario directamente en el clúster de almacenamiento de Ceph. Sin embargo, también puede crear un usuario, las claves y los permisos directamente en un anillo de claves del cliente de Ceph. A continuación, puede importar el usuario en el clúster de almacenamiento de Ceph:

cephadm@adm > ceph-authtool -n client.ringo --cap osd 'allow rwx' \
  --cap mon 'allow rwx' /etc/ceph/ceph.keyring

También puede crear un anillo de claves y añadirle simultáneamente un usuario nuevo:

cephadm@adm > ceph-authtool -C /etc/ceph/ceph.keyring -n client.ringo \
  --cap osd 'allow rwx' --cap mon 'allow rwx' --gen-key

En las situaciones anteriores, el nuevo usuario client.ringo está solo en el anillo de claves. Para añadir el nuevo usuario al clúster de almacenamiento de Ceph, sigue siendo necesario añadir el nuevo usuario al clúster:

cephadm@adm > ceph auth add client.ringo -i /etc/ceph/ceph.keyring

8.2.3.4 Modificación de usuarios Edit source

Para modificar los permisos de un registro de usuario en un anillo de claves, especifique el anillo de claves y el usuario seguidos de los permisos:

cephadm@adm > ceph-authtool /etc/ceph/ceph.keyring -n client.ringo \
  --cap osd 'allow rwx' --cap mon 'allow rwx'

Para actualizar el usuario modificado en el entorno de clúster de Ceph, debe importar los cambios desde el anillo de claves en la entrada de usuario del clúster de Ceph:

cephadm@adm > ceph auth import -i /etc/ceph/ceph.keyring

Consulte la Sección 8.2.2.7, “Importación de usuarios” para obtener información sobre cómo actualizar el clúster de almacenamiento de Ceph desde un anillo de claves.

8.2.4 Uso de la línea de comandos Edit source

El comando ceph admite las siguientes opciones relacionadas con el nombre de usuario y la manipulación del secreto:

‑‑id o ‑‑user

Ceph identifica a los usuarios con un tipo y un ID (TYPE.ID; por ejemplo, client.admin o client.user1). Las opciones id, name y -n permiten especificar la parte del ID del nombre de usuario (por ejemplo, admin o user1). Puede especificar el usuario con la opción ‑‑id y omitir el tipo. Por ejemplo, para especificar el usuario client.foo, escriba lo siguiente:

cephadm@adm > ceph --id foo --keyring /path/to/keyring health
cephadm@adm > ceph --user foo --keyring /path/to/keyring health
‑‑name o ‑n

Ceph identifica a los usuarios con un tipo y un ID (TYPE.ID; por ejemplo, client.admin o client.user1). Las opciones ‑‑name y ‑n permiten especificar el nombre completo del usuario. Debe especificar el tipo de usuario (generalmente, client) con el ID de usuario:

cephadm@adm > ceph --name client.foo --keyring /path/to/keyring health
cephadm@adm > ceph -n client.foo --keyring /path/to/keyring health
‑‑keyring

La vía al anillo de claves que contiene uno o más nombres de usuario y secretos. La opción ‑‑secret ofrece las mismas funciones, pero no funciona con Object Gateway, que utiliza ‑‑secret para otro fin. Puede recuperar un anillo de claves con auth ceph get-or-create y almacenarlo localmente. Se trata del enfoque preferido, ya que permite cambiar de nombres de usuario sin tener que cambiar la vía del anillo de claves:

cephadm@adm > rbd map --id foo --keyring /path/to/keyring mypool/myimage
Imprimir esta página