30 Autenticación con cephx
#
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).
El protocolo cephx
no se hace cargo del cifrado de datos durante el transporte, como SSL/TLS.
30.1 Arquitectura de autenticación #
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.
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.
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.
cephx
: servidor de metadatos y OSD #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.
30.2 Áreas clave de gestión #
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í:
cephuser@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.
30.2.1 Información básica #
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.
30.2.1.1 Usuario #
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á client
. 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.
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.
30.2.1.2 Autorización y permisos #
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
yallow profile permiso
.mon 'allow rwx' mon 'allow profile osd'
- Permisos de OSD
Incluye
r
,w
,x
,class-read
,class-write
yprofile 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.
30.2.1.3 Repositorios #
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
.
30.2.2 Gestión de usuarios #
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 30.2.3, “Gestión de anillos de claves”.
30.2.2.1 Listas de usuarios #
Para obtener una lista de los usuarios del clúster, ejecute lo siguiente:
cephuser@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
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.
30.2.2.2 Obtención de información sobre los usuarios #
Para recuperar información de un usuario, una clave y permisos concretos, ejecute lo siguiente:
cephuser@adm >
ceph auth get TYPE.ID
Por ejemplo:
cephuser@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:
cephuser@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.
30.2.2.3 Adición de usuarios #
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.
cephuser@adm >
ceph auth add client.john mon 'allow r' osd \ 'allow rw pool=liverpool'cephuser@adm >
ceph auth get-or-create client.paul mon 'allow r' osd \ 'allow rw pool=liverpool'cephuser@adm >
ceph auth get-or-create client.george mon 'allow r' osd \ 'allow rw pool=liverpool' -o george.keyringcephuser@adm >
ceph auth get-or-create-key client.ringo mon 'allow r' osd \ 'allow rw pool=liverpool' -o ringo.key
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.
30.2.2.4 Modificación de los permisos de usuario #
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:
cephuser@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:
cephuser@adm >
ceph auth get client.johncephuser@adm >
ceph auth caps client.john mon 'allow r' osd 'allow rw pool=prague'cephuser@adm >
ceph auth caps client.paul mon 'allow rw' osd 'allow r pool=prague'cephuser@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:
cephuser@adm >
ceph auth caps client.ringo mon ' ' osd ' '
30.2.2.5 Supresión de usuarios #
Para suprimir un usuario, utilice ceph auth del
:
cephuser@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.
30.2.2.6 Impresión de la clave de un usuario #
Para imprimir la clave de autenticación de un usuario con una salida estándar, ejecute lo siguiente:
cephuser@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:
#
mount -t ceph host:/ mount_point \
-o name=client.user,secret=`ceph auth print-key client.user`
30.2.2.7 Importación de usuarios #
Para importar uno o varios usuarios, utilice ceph auth import
y especifique un anillo de claves:
cephuser@adm >
ceph auth import -i /etc/ceph/ceph.keyring
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.
30.2.3 Gestión de anillos de claves #
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 30.2, “Áreas clave de gestión” 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.
30.2.3.1 Creación de un anillo de claves #
Cuando se utilizan los procedimientos de la Sección 30.2, “Áreas clave de gestión” 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:
cephuser@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:
cephuser@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
.
30.2.3.2 Adición de un usuario a un anillo de claves #
Cuando se añade un usuario al clúster de almacenamiento de Ceph (consulte la Sección 30.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:
cephuser@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:
cephuser@adm >
ceph-authtool /etc/ceph/ceph.keyring \
--import-keyring /etc/ceph/ceph.client.admin.keyring
Si el anillo de claves está en peligro, suprima la clave del directorio /etc/ceph
y vuelva a crear una clave nueva siguiendo las mismas instrucciones de la Sección 30.2.3.1, “Creación de un anillo de claves”.
30.2.3.3 Creación de un usuario #
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:
cephuser@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:
cephuser@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:
cephuser@adm >
ceph auth add client.ringo -i /etc/ceph/ceph.keyring
30.2.3.4 Modificación de usuarios #
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:
cephuser@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:
cephuser@adm >
ceph auth import -i /etc/ceph/ceph.keyring
Consulte la Sección 30.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.
30.2.4 Uso de la línea de comandos #
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, como
client.admin
oclient.user1
). Las opcionesid
,name
y-n
permiten especificar la parte del ID del nombre de usuario (por ejemplo,admin
ouser1
). Puede especificar el usuario con la opción ‑‑id y omitir el tipo. Por ejemplo, para especificar el usuario client.foo, escriba lo siguiente:cephuser@adm >
ceph --id foo --keyring /path/to/keyring healthcephuser@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, como
client.admin
oclient.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:cephuser@adm >
ceph --name client.foo --keyring /path/to/keyring healthcephuser@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 conauth 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:cephuser@adm >
rbd map --id foo --keyring /path/to/keyring mypool/myimage