Prepararsi a configurare il backend con i driver SAN ONTAP
Suggerisci modifiche
PDF
Comprendere i requisiti e le opzioni di autenticazione per la configurazione di un backend ONTAP con i driver SAN ONTAP.
Requisiti
Per tutti i backend ONTAP, Astra Trident richiede almeno un aggregato assegnato alla SVM.
È inoltre possibile eseguire più di un driver e creare classi di storage che puntino all'una o all'altra. Ad esempio, è possibile configurare una san-dev classe che utilizza il ontap-san driver e una san-default classe che utilizza ontap-san-economy quella.
Tutti i nodi di lavoro di Kubernetes devono disporre dei tool iSCSI appropriati. Per ulteriori informazioni, fare riferimento alla "Preparare il nodo di lavoro" sezione.
Autenticare il backend ONTAP
Astra Trident offre due modalità di autenticazione di un backend ONTAP.
-
Basato sulle credenziali: Nome utente e password di un utente ONTAP con le autorizzazioni richieste. Si consiglia di utilizzare un ruolo di accesso di sicurezza predefinito, ad esempio
adminovsadminper garantire la massima compatibilità con le versioni di ONTAP. -
Basato su certificato: Astra Trident può anche comunicare con un cluster ONTAP utilizzando un certificato installato sul backend. In questo caso, la definizione di backend deve contenere i valori codificati in Base64 del certificato client, della chiave e del certificato CA attendibile, se utilizzato (consigliato).
È possibile aggiornare i backend esistenti per passare da un metodo basato su credenziali a un metodo basato su certificato. Tuttavia, è supportato un solo metodo di autenticazione alla volta. Per passare a un metodo di autenticazione diverso, è necessario rimuovere il metodo esistente dalla configurazione di back-end.
|
Se si tenta di fornire credenziali e certificati, la creazione del backend non riesce e viene visualizzato un errore che indica che nel file di configurazione sono stati forniti più metodi di autenticazione. |
Abilitare l'autenticazione basata su credenziali
Astra Trident richiede le credenziali di un amministratore con ambito SVM/cluster per comunicare con il backend ONTAP. Si consiglia di utilizzare ruoli standard predefiniti come admin o vsadmin. Ciò garantisce la compatibilità con le future release di ONTAP che potrebbero esporre le API delle funzionalità da utilizzare nelle future release di Astra Trident. È possibile creare e utilizzare un ruolo di accesso di sicurezza personalizzato con Astra Trident, ma non è consigliato.
Una definizione di back-end di esempio avrà un aspetto simile al seguente:
--- version: 1 backendName: ExampleBackend storageDriverName: ontap-san managementLIF: 10.0.0.1 svm: svm_nfs username: vsadmin password: password
{
"version": 1,
"backendName": "ExampleBackend",
"storageDriverName": "ontap-san",
"managementLIF": "10.0.0.1",
"svm": "svm_nfs",
"username": "vsadmin",
"password": "password"
}
Tenere presente che la definizione di backend è l'unica posizione in cui le credenziali vengono memorizzate in testo normale. Una volta creato il backend, i nomi utente e le password vengono codificati con Base64 e memorizzati come segreti Kubernetes. La creazione o l'aggiornamento di un backend è l'unico passaggio che richiede la conoscenza delle credenziali. Pertanto, si tratta di un'operazione di sola amministrazione, che deve essere eseguita dall'amministratore Kubernetes/storage.
Abilitare l'autenticazione basata su certificato
I backend nuovi ed esistenti possono utilizzare un certificato e comunicare con il backend ONTAP. Nella definizione di backend sono necessari tre parametri.
-
ClientCertificate: Valore del certificato client codificato con base64.
-
ClientPrivateKey: Valore codificato in base64 della chiave privata associata.
-
TrustedCACertificate: Valore codificato in base64 del certificato CA attendibile. Se si utilizza una CA attendibile, è necessario fornire questo parametro. Questa operazione può essere ignorata se non viene utilizzata alcuna CA attendibile.
Un workflow tipico prevede i seguenti passaggi.
-
Generare un certificato e una chiave del client. Durante la generazione, impostare il nome comune (CN) sull'utente ONTAP per l'autenticazione come.
openssl req -x509 -nodes -days 1095 -newkey rsa:2048 -keyout k8senv.key -out k8senv.pem -subj "/C=US/ST=NC/L=RTP/O=NetApp/CN=admin"
-
Aggiungere un certificato CA attendibile al cluster ONTAP. Questo potrebbe essere già gestito dall'amministratore dello storage. Ignorare se non viene utilizzata alcuna CA attendibile.
security certificate install -type server -cert-name <trusted-ca-cert-name> -vserver <vserver-name> ssl modify -vserver <vserver-name> -server-enabled true -client-enabled true -common-name <common-name> -serial <SN-from-trusted-CA-cert> -ca <cert-authority>
-
Installare il certificato e la chiave del client (dal passaggio 1) sul cluster ONTAP.
security certificate install -type client-ca -cert-name <certificate-name> -vserver <vserver-name> security ssl modify -vserver <vserver-name> -client-enabled true
-
Verificare che il ruolo di accesso di sicurezza ONTAP supporti il
certmetodo di autenticazione.security login create -user-or-group-name admin -application ontapi -authentication-method cert security login create -user-or-group-name admin -application http -authentication-method cert
-
Verifica dell'autenticazione utilizzando il certificato generato. Sostituire <LIF di gestione ONTAP> e <vserver name> con IP LIF di gestione e nome SVM.
curl -X POST -Lk https://<ONTAP-Management-LIF>/servlets/netapp.servlets.admin.XMLrequest_filer --key k8senv.key --cert ~/k8senv.pem -d '<?xml version="1.0" encoding="UTF-8"?><netapp xmlns="http://www.netapp.com/filer/admin" version="1.21" vfiler="<vserver-name>"><vserver-get></vserver-get></netapp>'
-
Codifica certificato, chiave e certificato CA attendibile con Base64.
base64 -w 0 k8senv.pem >> cert_base64 base64 -w 0 k8senv.key >> key_base64 base64 -w 0 trustedca.pem >> trustedca_base64
-
Creare il backend utilizzando i valori ottenuti dal passaggio precedente.
cat cert-backend.json { "version": 1, "storageDriverName": "ontap-san", "backendName": "SanBackend", "managementLIF": "1.2.3.4", "svm": "vserver_test", "clientCertificate": "Faaaakkkkeeee...Vaaalllluuuueeee", "clientPrivateKey": "LS0tFaKE...0VaLuES0tLS0K", "trustedCACertificate": "QNFinfO...SiqOyN", "storagePrefix": "myPrefix_" } tridentctl create backend -f cert-backend.json -n trident +------------+----------------+--------------------------------------+--------+---------+ | NAME | STORAGE DRIVER | UUID | STATE | VOLUMES | +------------+----------------+--------------------------------------+--------+---------+ | SanBackend | ontap-san | 586b1cd5-8cf8-428d-a76c-2872713612c1 | online | 0 | +------------+----------------+--------------------------------------+--------+---------+
Aggiornare i metodi di autenticazione o ruotare le credenziali
È possibile aggiornare un backend esistente per utilizzare un metodo di autenticazione diverso o per ruotare le credenziali. Questo funziona in entrambi i modi: I backend che utilizzano il nome utente/la password possono essere aggiornati per utilizzare i certificati; i backend che utilizzano i certificati possono essere aggiornati in base al nome utente/alla password. A tale scopo, è necessario rimuovere il metodo di autenticazione esistente e aggiungere il nuovo metodo di autenticazione. Quindi utilizzare il file backend.json aggiornato contenente i parametri necessari per eseguire tridentctl backend update.
cat cert-backend-updated.json
{
"version": 1,
"storageDriverName": "ontap-san",
"backendName": "SanBackend",
"managementLIF": "1.2.3.4",
"svm": "vserver_test",
"username": "vsadmin",
"password": "password",
"storagePrefix": "myPrefix_"
}
#Update backend with tridentctl
tridentctl update backend SanBackend -f cert-backend-updated.json -n trident
+------------+----------------+--------------------------------------+--------+---------+
| NAME | STORAGE DRIVER | UUID | STATE | VOLUMES |
+------------+----------------+--------------------------------------+--------+---------+
| SanBackend | ontap-san | 586b1cd5-8cf8-428d-a76c-2872713612c1 | online | 9 |
+------------+----------------+--------------------------------------+--------+---------+
|
Quando si ruotano le password, l'amministratore dello storage deve prima aggiornare la password per l'utente su ONTAP. Seguito da un aggiornamento back-end. Durante la rotazione dei certificati, è possibile aggiungere più certificati all'utente. Il backend viene quindi aggiornato per utilizzare il nuovo certificato, dopodiché il vecchio certificato può essere cancellato dal cluster ONTAP. |
L'aggiornamento di un backend non interrompe l'accesso ai volumi già creati, né influisce sulle connessioni dei volumi effettuate successivamente. Un aggiornamento back-end corretto indica che Astra Trident può comunicare con il backend ONTAP e gestire le future operazioni sui volumi.
Autenticare le connessioni con CHAP bidirezionale
Astra Trident è in grado di autenticare le sessioni iSCSI con CHAP bidirezionale per i ontap-san driver e. ontap-san-economy Ciò richiede l'attivazione dell' useCHAP`opzione nella definizione di backend. Quando è impostato su `true, Astra Trident configura la protezione dell'iniziatore predefinito della SVM su CHAP bidirezionale e imposta il nome utente e i segreti dal file backend. NetApp consiglia di utilizzare CHAP bidirezionale per autenticare le connessioni. Vedere la seguente configurazione di esempio:
--- version: 1 storageDriverName: ontap-san backendName: ontap_san_chap managementLIF: 192.168.0.135 svm: ontap_iscsi_svm useCHAP: true username: vsadmin password: password chapInitiatorSecret: cl9qxIm36DKyawxy chapTargetInitiatorSecret: rqxigXgkesIpwxyz chapTargetUsername: iJF4heBRT0TCwxyz chapUsername: uh2aNCLSd6cNwxyz
|
|
Il useCHAP parametro è un'opzione booleana che può essere configurata solo una volta. L'impostazione predefinita è false. Una volta impostato su true, non è possibile impostarlo su false.
|
Oltre a useCHAP=true, i chapInitiatorSecret chapTargetUsername campi , , chapTargetInitiatorSecret e chapUsername devono essere inclusi nella definizione backend. I segreti possono essere modificati dopo che un backend è stato creato eseguendo tridentctl update.
Come funziona
Impostando useCHAP su true, l'amministratore dello storage ordina ad Astra Trident di configurare CHAP sul backend dello storage. Ciò include quanto segue:
-
Impostazione di CHAP su SVM:
-
Se il tipo di protezione iniziatore predefinito della SVM è nessuno (impostato per impostazione predefinita) e non sono già presenti LUN preesistenti nel volume, Astra Trident imposterà il tipo di protezione predefinito su
CHAPe procederà alla configurazione del nome utente e dei segreti dell'iniziatore CHAP e di destinazione. -
Se la SVM contiene LUN, Astra Trident non attiverà CHAP sulla SVM. In questo modo, l'accesso ai LUN già presenti nella SVM non è limitato.
-
-
Configurazione dell'iniziatore CHAP e del nome utente e dei segreti di destinazione; queste opzioni devono essere specificate nella configurazione del backend (come mostrato sopra).
Una volta creato il backend, Astra Trident crea un CRD corrispondente tridentbackend e memorizza i segreti e i nomi utente CHAP come segreti di Kubernetes. Tutti i PVS creati da Astra Trident su questo backend verranno montati e fissati su CHAP.
Ruota le credenziali e aggiorna i back-end
È possibile aggiornare le credenziali CHAP aggiornando i parametri CHAP nel backend.json file. Questo richiederà l'aggiornamento dei segreti CHAP e l'utilizzo del tridentctl update comando per riflettere queste modifiche.
|
|
Quando si aggiornano i segreti CHAP per un backend, è necessario utilizzare tridentctl per aggiornare il backend. Non aggiornare le credenziali sul cluster di storage attraverso l'interfaccia utente CLI/ONTAP, in quanto Astra Trident non sarà in grado di rilevare queste modifiche.
|
cat backend-san.json
{
"version": 1,
"storageDriverName": "ontap-san",
"backendName": "ontap_san_chap",
"managementLIF": "192.168.0.135",
"svm": "ontap_iscsi_svm",
"useCHAP": true,
"username": "vsadmin",
"password": "password",
"chapInitiatorSecret": "cl9qxUpDaTeD",
"chapTargetInitiatorSecret": "rqxigXgkeUpDaTeD",
"chapTargetUsername": "iJF4heBRT0TCwxyz",
"chapUsername": "uh2aNCLSd6cNwxyz",
}
./tridentctl update backend ontap_san_chap -f backend-san.json -n trident
+----------------+----------------+--------------------------------------+--------+---------+
| NAME | STORAGE DRIVER | UUID | STATE | VOLUMES |
+----------------+----------------+--------------------------------------+--------+---------+
| ontap_san_chap | ontap-san | aa458f3b-ad2d-4378-8a33-1a472ffbeb5c | online | 7 |
+----------------+----------------+--------------------------------------+--------+---------+
Le connessioni esistenti rimarranno inalterate; continueranno a rimanere attive se le credenziali vengono aggiornate da Astra Trident sulla SVM. Le nuove connessioni utilizzeranno le credenziali aggiornate e le connessioni esistenti continueranno a rimanere attive. Disconnettendo e riconnettendo il vecchio PVS, verranno utilizzate le credenziali aggiornate.