30 Autenticazione con cephx
#
Per identificare i client e proteggerli da attacchi man-in-the-middle, in Ceph è disponibile il rispettivo sistema di autenticazione cephx
. I client in questo contesto sono utenti umani, come l'utente amministratore, o servizi/daemon correlati a Ceph, ad esempio OSD, monitoraggi o Object Gateway.
Il protocollo cephx
non indirizza la cifratura dati nel trasporto, come TLS/SSL.
30.1 Architettura di autenticazione #
cephx
utilizza chiavi segrete condivise per l'autenticazione, vale a dire che sia il client che i Ceph Monitor dispongono di una copia della chiave segreta del client. Il protocollo di autenticazione consente a entrambe le parti di provare a vicenda l'esistenza di una copia della chiave senza rivelarla effettivamente. In tal modo se esegue un'autenticazione reciproca, che assicura sia all'utente sia al cluster che entrambi possiedono rispettivamente la chiave segreta e la copia della stessa.
Una funzione di scalabilità della chiave di Ceph consente di evitare un'interfaccia centralizzata nell'archivio dati Ceph. Ciò significa che i client Ceph possono interagire direttamente con gli OSD. Per proteggere i dati, in Ceph è disponibile il sistema di autenticazione cephx
, che consente di autenticare i client Ceph.
Ciascun monitoraggio in grado di autenticare client e distribuire chiavi, pertanto non si verifica alcun single point of failure o collo di bottiglia quando si utilizza cephx
. Il monitoraggio restituisce una struttura di dati di autenticazione nella quale è inclusa una chiave sessione quando si ottengono i servizi Ceph. Tale chiave sessione è cifrata con la chiave segreta permanente del client in modo che solo quest'ultimo sia in grado di richiedere servizi dai Ceph monitor. La chiave sessione viene quindi utilizzata dal client per richiedere i rispettivi servizi desiderati dal monitoraggio e questo a sua volta fornisce un ticket tramite il quale il client eseguirà l'autenticazione negli OSD in cui vengono effettivamente gestiti i dati. I Ceph monitor e gli OSD condividono un segreto in modo che il client possa utilizzare il ticket fornito dal monitoraggio con qualsiasi OSD o server di metadati nel cluster. Poiché i ticket cephx
hanno una scadenza, l'autore di un attacco non può utilizzare un ticket scaduto o una chiave sessione ottenuti in modo illecito.
Per utilizzare cephx
, l'amministratore deve prima configurare i client/gli utenti. Nel seguente diagramma, l'utente client.admin
richiama ceph auth get-or-create-key
dalla riga di comando per generare un nome utente e una chiave segreta. Nel sottosistema auth
di Ceph vengono generati nome utente e chiave, quindi viene memorizzata una copia con il o i monitoraggio e il segreto dell'utente viene trasmesso di nuovo all'utente client.admin
. Vale a dire che client e monitoraggio condividono una chiave segreta.
cephx
di base #Per eseguire l'autenticazione con il monitoraggio, il client trasmette al monitoraggio il nome utente. Il monitoraggio genera una chiave sessione che viene cifrata con la chiave segreta associata al nome utente e il ticket cifrato viene trasmesso di nuovo al client. I dati con la chiave segreta condivisa vengono quindi decifrati nel client in modo da recuperare la chiave sessione. La chiave sessione consente di identificare l'utente per la sessione attuale. Il client richiede quindi un ticket correlato all'utente, che viene firmato dalla chiave sessione. Il monitoraggio genera un ticket, che viene poi cifrato con la chiave segreta dell'utente e trasmesso di nuovo al client. Il ticket viene quindi decifrato dal client e utilizzato per firmare le richieste agli OSD e ai server di metadati nel cluster.
cephx
autenticazione #
Il protocollo cephx
consente di autenticare le comunicazioni in corso tra il computer client e i server Ceph. Ciascun messaggio inviato tra un client e un server dopo l'autenticazione iniziale viene firmato mediante l'uso di un ticket che può essere verificato da monitoraggi, OSD, e server di metadati tramite il rispettivo segreto condiviso.
cephx
- MDS e OSD #La protezione offerta da questa autenticazione viene applicata tra il client Ceph e gli host del cluster Ceph. L'autenticazione non viene estesa oltre il client Ceph. Se un utente accede al client Ceph da un host remoto, l'autenticazione Ceph non viene applicata alla connessione tra l'host dell'utente e l'host client.
30.2 Gestione delle chiavi #
In questa sezione sono descritti gli utenti del client Ceph e le rispettive autenticazioni e autorizzazioni con il cluster di memorizzazione Ceph. Gli utenti sono individui o attori di sistema, come le applicazioni, che utilizzano i client Ceph per interagire con i daemon del cluster di memorizzazione Ceph.
Quando Ceph viene eseguito con l'autenticazione e l'autorizzazione abilitate (abilitate per default), è necessario specificare un nome utente e un portachiavi contenente la chiave segreta dell'utente specificato (di solito tramite riga di comando). Se non si specifica un nome utente, Ceph utilizzerà client.admin
come nome utente di default. Se non si specifica un portachiavi, Ceph ne ricercherà uno tramite l'impostazione del portachiavi nel file di configurazione Ceph. Ad esempio, se si esegue il comando ceph health
senza specificare un nome utente o un portachiavi, il comando viene interpretato da Ceph nel seguente modo:
cephuser@adm >
ceph -n client.admin --keyring=/etc/ceph/ceph.client.admin.keyring health
In alternativa, è possibile utilizzare la variabile di ambiente CEPH_ARGS
per evitare di immettere di nuovo il nome utente e il segreto.
30.2.1 Informazioni di background #
Indipendentemente dal tipo di client Ceph (ad esempio, dispositivo di blocco, spazio di memorizzazione degli oggetti, file system, API nativa), Ceph memorizza tutti i dati come oggetti nei pool. Gli utenti Ceph devono disporre dell'accesso ai pool per leggere e scrivere i dati. Inoltre, gli utenti Ceph devono eseguire le autorizzazioni per utilizzare i comandi amministrativi Ceph. Di seguito sono spiegati i concetti per comprendere come gestire gli utenti Ceph.
30.2.1.1 Utente #
Un utente è un individuo o un attore di sistema, come ad esempio un'applicazione. La creazione di utenti consente di controllare chi (o cosa) può accedere al cluster di memorizzazione Ceph, ai rispettivi pool e ai dati in essi contenuti.
Ceph utilizza tipi di utenti. Ai fini della gestione degli utenti, il tipo sarà sempre client
. Ceph identifica gli utenti nella forma delimitata da un punto (.), costituita dal tipo di utente e ID utente. Ad esempio, TYPE.ID
, client.admin
o client.user1
. Il motivo dell'uso del tipo di utente sta nel fatto che anche i Ceph monitor, gli OSD e i server di metadati utilizzano il protocollo cephx, ma non sono client. La distinzione del tipo di utenti consente di distinguere gli utenti del client dagli altri, semplificando il controllo degli accessi, nonché il monitoraggio e la tracciabilità degli utenti.
A volte non è semplice capire qual è il tipo di utente. A seconda di come viene utilizzata, la riga di comando di Ceph consente infatti di specificare l'utente con o senza tipo. Se si specifica --user
o --id
, è possibile omettere il tipo. client.user1
può quindi essere immesso semplicemente come user1
. Se si specifica --name
o -n
, è necessario indicare il tipo e il nome, ad esempio client.user1
. Laddove possibile, come best practice si consiglia di utilizzare anche il tipo e il nome.
Un utente del cluster di memorizzazione Ceph non è lo stesso di un'unità di memorizzazione degli oggetti Ceph o di un utente del file system Ceph. Ceph Object Gateway utilizza un utente del cluster di memorizzazione Ceph per la comunicazione tra il daemon del gateway e il cluster di memorizzazione, ma il gateway dispone di una funzionalità di gestione degli utenti propria per gli utenti finali. Nel file system Ceph viene utilizzata la semantica POSIX. Lo spazio utente associato a esso non è lo stesso dell'utente di un cluster di memorizzazione Ceph.
30.2.1.2 Autorizzazione e funzionalità #
In Ceph, con il termine "capabilities" (caps, funzionalità) si intende l'autorizzazione di un utente autenticato a praticare la funzionalità di monitoraggio, OSD e server dei metadati. Le capacità possono inoltre limitare l'accesso ai dati all'interno di un pool o di uno spazio dei nomi del pool. Le funzionalità di un utente vengono impostate da un utente amministrativo Ceph durante la creazione o l'aggiornamento di un utente.
La sintassi delle funzionalità presenta la forma seguente:
daemon-type 'allow capability' [...]
Di seguito è riportato un elenco di funzionalità per ciascun tipo di servizio:
- Funzionalità di monitoraggio
includono
r
,w
,x
eallow profile cap
.mon 'allow rwx' mon 'allow profile osd'
- Funzionalità OSD
includono
r
,w
,x
,class-read
,class-write
eprofile osd
. Le funzionalità OSD consentono inoltre le impostazioni di pool spazio dei nomi.osd 'allow capability' [pool=poolname] [namespace=namespace-name]
- Funzionalità MDS
richiedono semplicemente
allow
o è possibile lasciare vuoto.mds 'allow'
Le voci seguenti descrivono ciascuna funzionalità:
- allow
Precede le impostazioni di accesso per un daemon. Implica
rw
solo per MDS.- r
Fornisce all'utente l'accesso in lettura. Richiesta con monitoraggi per il recupero della mappa CRUSH.
- w
Fornisce all'utente l'accesso in scrittura agli oggetti.
- x
Fornisce all'utente la funzionalità di chiamare metodi di classe (lettura e scrittura) per eseguire operazioni
auth
nei monitoraggi.- class-read
Fornisce all'utente la funzionalità di chiamare metodi di lettura di classe. Sottoinsieme di
x
.- class-write
Fornisce all'utente la funzionalità di chiamare metodi di scrittura di classe. Sottoinsieme di
x
.- *
Fornisce all'utente autorizzazioni per la lettura, scrittura ed esecuzione di un determinato daemon/pool, nonché la capacità di eseguire comandi amministrativi.
- profile osd
Fornisce all'utente le autorizzazioni per connettere un OSD ad altri OSD o monitoraggi. Concessa sugli OSD per abilitarli a gestire il traffico heartbeat delle repliche e le segnalazioni dello stato.
- profile mds
Fornisce all'utente le autorizzazioni per connettere un MDS ad altri MDS o monitoraggi.
- profile bootstrap-osd
Fornisce all'utente le autorizzazioni per eseguire il bootstrap su un OSD. Delegata agli strumenti di distribuzione in modo che dispongano delle autorizzazioni per aggiungere chiavi quando si esegue il bootstrap di un OSD.
- profile bootstrap-mds
Fornisce all'utente le autorizzazioni per eseguire il bootstrap su un server dei metadati. Delegata agli strumenti di distribuzione in modo che dispongano delle autorizzazioni per aggiungere chiavi quando si esegue il bootstrap di un server dei metadati.
30.2.1.3 Pool #
Un pool è una partizione logica in cui vengono memorizzati i dati degli utenti. Nelle distribuzioni Ceph, è prassi comune creare un pool come partizione logica per tipi di dati simili. Ad esempio, quando si distribuisce Ceph come back end per OpenStack, una distribuzione tipica comprende pool per volumi, immagini, backup, macchine virtuali e utenti come client.glance
o client.cinder
.
30.2.2 Gestione degli utenti #
La funzionalità di gestione degli utenti offre agli amministratori del cluster Ceph la possibilità di creare, aggiornare ed eliminare utenti direttamente nel cluster Ceph.
Quando si creano o si eliminano utenti nel cluster Ceph, potrebbe essere necessario distribuire chiavi ai client in modo che possano essere aggiunte ai portachiavi. Per informazioni, vedere Sezione 30.2.3, «Gestione dei portachiavi».
30.2.2.1 Elenco degli utenti #
Per elencare gli utenti nel cluster, eseguire quanto riportato di seguito:
cephuser@adm >
ceph auth list
Ceph elencherà tutti gli utenti nel cluster. Ad esempio, in un cluster con due nodi, l'output ceph auth list
ha un aspetto simile:
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
Si noti che viene applicata la notazione TYPE.ID
per gli utenti in modo che osd.0
specifichi un utente di tipo osd
con ID 0
. client.admin
è un utente di tipo client
con ID admin
. Inoltre, ogni voce presenta una voce key: value
e una o più voci caps:
.
È possibile utilizzare l'opzione -o filename
con ceph auth list
per salvare l'output in un file.
30.2.2.2 Ottenimento delle informazioni sugli utenti #
Per recuperare un utente, una chiave e funzionalità specifiche, eseguire quanto riportato di seguito:
cephuser@adm >
ceph auth get TYPE.ID
Esempio:
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 *"
Gli sviluppatori possono eseguire anche:
cephuser@adm >
ceph auth export TYPE.ID
Il comando auth export
è identico a auth get
, ma consente anche di stampare l'ID autenticazione interno.
30.2.2.3 Aggiunta di utenti #
Con l'aggiunta di un utente si creano un nome utente (TYPE.ID
), una chiave segreta e tutte le funzionalità incluse nel comando utilizzato per creare l'utente.
La chiave di un utente consente a quest'ultimo di eseguire l'autenticazione con il cluster di memorizzazione Ceph. Le funzionalità dell'utente gli forniscono le autorizzazione in lettura, scrittura o esecuzione nei Ceph monitor (mon), Ceph OSD (osd) server dei metadati Ceph (mds).
Per aggiungere un utente sono disponibili alcuni comandi:
ceph auth add
Questo comando è il modo canonico per aggiungere un utente. Consente di creare l'utente, generare una chiave e aggiungere tutte le funzionalità specificate.
ceph auth get-or-create
Questo comando è spesso il modo più pratico per creare un utente perché restituisce un formato keyfile con nome utente (tra parentesi) e chiave. Se l'utente esiste già, questo comando restituisce semplicemente il nome utente e la chiave nel formato keyfile. È possibile utilizzare l'opzione
-o filename
per salvare l'output in un file.ceph auth get-or-create-key
Questo comando è un modo pratico per creare un utente e restituire (solo) la chiave utente. È utile per i client per i quali è necessaria solo la chiave (ad esempio
libvirt
). Se l'utente esiste già, questo comando restituisce semplicemente la chiave. È possibile utilizzare l'opzione-o filename
per salvare l'output in un file.
Quando si creano utenti del client, è possibile creare un utente senza alcuna funzionalità. Un utente privo di funzionalità può eseguire solo ed esclusivamente l'autenticazione. Tale client non è in grado di recuperare la mappa del cluster dal monitoraggio. È tuttavia possibile creare un utente senza funzionalità se si desidera rinviare l'aggiunta delle funzionalità in un momento successivo mediante l'uso del comando ceph auth caps
.
Un utente tipico dispone almeno delle funzionalità di lettura sul Ceph monitor e delle funzionalità di lettura e scrittura sui Ceph OSD. Inoltre, le autorizzazioni OSD di un utente sono spesso limitate per l'accesso a un determinato pool.
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
Se si forniscono a un utente le funzionalità per gli OSD, ma non si limita l'accesso a un determinato pool, l'utente potrà accedere a tutti i pool nel cluster.
30.2.2.4 Modifica delle funzionalità utente #
Il comando ceph auth caps
consente di specificare un utente e di modificarne le funzionalità. Quando si impostano nuove funzionalità, quelle attuali verranno sovrascritte. Per visualizzare le funzionalità attuali, eseguire ceph auth get USERTYPE.USERID
. Per aggiungere funzionalità, è necessario specificare anche le funzionalità esistenti quando si utilizza la forma seguente:
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]']
Esempio:
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 *'
Per rimuovere una funzionalità, è possibile reimpostarla. Se si desidera che l'utente non disponga di alcun accesso a un determinato daemon impostato precedentemente, specificare una stringa vuota:
cephuser@adm >
ceph auth caps client.ringo mon ' ' osd ' '
30.2.2.5 Eliminazione di utenti #
Per eliminare un utente, utilizzare ceph auth del
:
cephuser@adm >
ceph auth del TYPE.ID
dove TYPE è un client
, osd
, mon
o mds
e ID è il nome utente o l'ID del daemon.
Se sono stati creati utenti con autorizzazioni esclusivamente per un pool non più esistente, considerare di eliminare anche tali utenti.
30.2.2.6 Stampa di una chiave utente #
Per stampare una chiave di autenticazione dell'utente nell'output standard, eseguire quanto riportato di seguito:
cephuser@adm >
ceph auth print-key TYPE.ID
dove TYPE è un client
, osd
, mon
o mds
e ID è il nome utente o l'ID del daemon.
È utile stampare una chiave utente quando è necessario popolare il software del client con una chiave utente (come libvirt
), come nell'esempio seguente:
#
mount -t ceph host:/ mount_point \
-o name=client.user,secret=`ceph auth print-key client.user`
30.2.2.7 Importazione di utenti #
Per importare uno o più utenti, utilizzare ceph auth import
e specificare un portachiavi:
cephuser@adm >
ceph auth import -i /etc/ceph/ceph.keyring
Nel cluster di memorizzazione Ceph verranno aggiunti nuovi utenti, le rispettive chiavi e funzionalità e verranno aggiornati gli utenti esistenti, insieme alle rispettive chiavi e funzionalità.
30.2.3 Gestione dei portachiavi #
Quando si accede a Ceph tramite il cliente Ceph, questo ricercherà un portachiavi locale. In Ceph l'impostazione dei portachiavi è preimpostata per default con i quattro nomi seguenti, quindi non è necessario impostarli nel file di configurazione Ceph a meno che non si desideri ignorare le impostazioni di default:
/etc/ceph/cluster.name.keyring /etc/ceph/cluster.keyring /etc/ceph/keyring /etc/ceph/keyring.bin
La metavariabile cluster è il nome del cluster Ceph definito dal nome del file di configurazione Ceph. ceph.conf
significa che il nome del cluster è ceph
, pertanto ceph.keyring
. La metavariabile name è il tipo di utente e l'ID utente, ad esempio client.admin
, pertanto ceph.client.admin.keyring
.
Dopo aver creato un utente (ad esempio client.ringo
), è necessario ottenere la chiave e aggiungerla a un portachiavi in un client Ceph in modo che l'utente possa accedere al cluster di memorizzazione Ceph.
Nella Sezione 30.2, «Gestione delle chiavi» è spiegato come elencare, ottenere, aggiungere, modificare ed eliminare utenti direttamente nel cluster di memorizzazione Ceph. Ceph, tuttavia, fornisce anche l'utility ceph-authtool
per consentire la gestione dei portachiavi da un client Ceph.
30.2.3.1 Creazione di un portachiavi #
Quando si utilizzano le procedure indicate nella Sezione 30.2, «Gestione delle chiavi» per creare utenti, è necessario fornire chiavi utente ai client Ceph in modo che il client possa recuperare la chiave per l'utente specificato ed eseguire l'autenticazione con il cluster di memorizzazione Ceph. I client Ceph accedono ai portachiavi per ricercare un nome utente e recuperare la chiave dell'utente:
cephuser@adm >
ceph-authtool --create-keyring /path/to/keyring
Quando si crea un portachiavi con più utenti, si consiglia di utilizzare il nome cluster (ad esempio cluster.keyring) per il nome file del portachiavi e salvarlo nella directory /etc/ceph
, in modo che l'impostazione di default della configurazione del portachiavi selezioni il nome file senza doverlo specificare nella copia locale del file di configurazione Ceph. Ad esempio, creare ceph.keyring
eseguendo quanto riportato di seguito:
cephuser@adm >
ceph-authtool -C /etc/ceph/ceph.keyring
Quando si crea un portachiavi con un singolo utente, si consiglia di utilizzare il nome del cluster, il tipo di utente e il nome utente e salvarlo nella directory /etc/ceph
. Ad esempio, ceph.client.admin.keyring
per l'utente client.admin
.
30.2.3.2 Aggiunta di un utente a un portachiavi #
Quando si aggiunge un utente al cluster di memorizzazione Ceph (vedere Sezione 30.2.2.3, «Aggiunta di utenti»), è possibile recuperare utente, chiave e funzionalità e salvare l'utente in un portachiavi.
Se si desidera solo utilizzare un utente per portachiavi, con il comando ceph auth get
e l'opzione -o
l'output verrà salvato nel formato file del portachiavi. Ad esempio, per creare un portachiavi per l'utente client.admin
, eseguire quanto riportato di seguito:
cephuser@adm >
ceph auth get client.admin -o /etc/ceph/ceph.client.admin.keyring
Quando si desidera importare utenti in un portachiavi, è possibile utilizzare ceph-authtool
per specificare il portachiavi di destinazione e quello di origine:
cephuser@adm >
ceph-authtool /etc/ceph/ceph.keyring \
--import-keyring /etc/ceph/ceph.client.admin.keyring
Se il portachiavi è compromesso, eliminare la chiave dalla directory /etc/ceph
e crearne una nuova seguendo le stesse istruzioni della Sezione 30.2.3.1, «Creazione di un portachiavi».
30.2.3.3 Creazione di un utente #
In Ceph è disponibile il comando ceph auth add
per creare un utente direttamente nel cluster di memorizzazione Ceph. È tuttavia possibile creare anche un utente, chiavi e funzionalità direttamente in un portachiavi client Ceph. Quindi, è possibile importare l'utente nel cluster di memorizzazione Ceph:
cephuser@adm >
ceph-authtool -n client.ringo --cap osd 'allow rwx' \
--cap mon 'allow rwx' /etc/ceph/ceph.keyring
È altresì possibile creare un portachiavi e aggiungervi un utente simultaneamente:
cephuser@adm >
ceph-authtool -C /etc/ceph/ceph.keyring -n client.ringo \
--cap osd 'allow rwx' --cap mon 'allow rwx' --gen-key
Negli scenari precedenti, il nuovo utente client.ringo
è presente solo nel portachiavi. Per aggiungere un nuovo utente al cluster di memorizzazione Ceph, è comunque necessario aggiungerlo al cluster:
cephuser@adm >
ceph auth add client.ringo -i /etc/ceph/ceph.keyring
30.2.3.4 Modifica di utenti #
Per modificare le funzionalità di un record utente in un portachiavi, specificare il portachiavi e l'utente seguiti dalle funzionalità:
cephuser@adm >
ceph-authtool /etc/ceph/ceph.keyring -n client.ringo \
--cap osd 'allow rwx' --cap mon 'allow rwx'
Per aggiornare l'utente modificato nell'ambiente cluster Ceph, è necessario importare le modifiche dal portachiavi alla voce utente nel cluster Ceph:
cephuser@adm >
ceph auth import -i /etc/ceph/ceph.keyring
Vedere Sezione 30.2.2.7, «Importazione di utenti» per informazioni più dettagliate sull'aggiornamento di un cluster di memorizzazione Ceph da un portachiavi.
30.2.4 Utilizzo della riga di comando #
Il comando ceph
supporta le seguenti opzioni correlate alla modifica del nome utente e del segreto:
--id
o--user
Ceph identifica gli utenti con tipo e ID (TYPE.ID, come
client.admin
oclient.user1
). Le opzioniid
,name
e-n
consentono di specificare la parte ID del nome utente (ad esempioadmin
ouser1
). È possibile specificare l'utente con --id e omettere il tipo. Ad esempio, per specificare l'utente client.foo immettere quanto indicato di seguito:cephuser@adm >
ceph --id foo --keyring /path/to/keyring healthcephuser@adm >
ceph --user foo --keyring /path/to/keyring health--name
o-n
Ceph identifica gli utenti con tipo e ID (TYPE.ID, come
client.admin
oclient.user1
). Le opzioni--name
e-n
consentono di specificare il nome utente completo. È necessario specificare il tipo di utente (di normaclient
) con l'ID utente:cephuser@adm >
ceph --name client.foo --keyring /path/to/keyring healthcephuser@adm >
ceph -n client.foo --keyring /path/to/keyring health--keyring
Percorso del portachiavi contenente uno o più nomi utente e segreti. L'opzione
--secret
offre la stessa funzionalità, ma non funzione con Object Gateway, in cui viene utilizzata--secret
per altri scopi. È possibile recuperare un portachiavi conceph auth get-or-create
e memorizzarlo localmente. Questo è l'approccio preferito perché è possibile cambiare i nomi utenti senza dover cambiare il percorso del portachiavi:cephuser@adm >
rbd map --id foo --keyring /path/to/keyring mypool/myimage