O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

Preparação

10/23/2024 Colaboradores

PDFs

Saiba mais sobre como se preparar para configurar um back-end ONTAP com drivers SAN ONTAP. Para todos os back-ends ONTAP, o Astra Trident requer pelo menos um agregado atribuído ao SVM.

Lembre-se de que você também pode executar mais de um driver e criar classes de armazenamento que apontam para um ou outro. Por exemplo, você pode configurar uma san-dev classe que usa o ontap-san driver e uma san-default classe que usa a ontap-san-economy mesma.

Todos os seus nós de trabalho do Kubernetes precisam ter as ferramentas iSCSI apropriadas instaladas. "aqui"Consulte para obter mais detalhes.

Autenticação

O Astra Trident oferece dois modos de autenticação no back-end do ONTAP.

Baseado em credenciais: O nome de usuário e senha para um usuário do ONTAP com as permissões necessárias. Recomenda-se a utilização de uma função de início de sessão de segurança predefinida, como admin ou vsadmin para garantir a máxima compatibilidade com as versões do ONTAP.
Baseado em certificado: O Astra Trident também pode se comunicar com um cluster ONTAP usando um certificado instalado no back-end. Aqui, a definição de back-end deve conter valores codificados em Base64 do certificado de cliente, chave e certificado de CA confiável, se usado (recomendado).

Os usuários também podem optar por atualizar os backends existentes, optando por mover-se de credenciais para baseadas em certificados e vice-versa. Se as credenciais e os certificados forem fornecidos, o Astra Trident usará os certificados por padrão ao emitir um aviso para remover as credenciais da definição de back-end.

Ative a autenticação baseada em credenciais

O Astra Trident requer as credenciais para um administrador com escopo SVM/cluster para se comunicar com o back-end do ONTAP. Recomenda-se a utilização de funções padrão predefinidas, como admin ou vsadmin. Isso garante compatibilidade direta com futuras versões do ONTAP que podem expor APIs de recursos a serem usadas por futuras versões do Astra Trident. Uma função de login de segurança personalizada pode ser criada e usada com o Astra Trident, mas não é recomendada.

Uma definição de backend de exemplo será assim:

{
  "version": 1,
  "backendName": "ExampleBackend",
  "storageDriverName": "ontap-san",
  "managementLIF": "10.0.0.1",
  "dataLIF": "10.0.0.2",
  "svm": "svm_nfs",
  "username": "vsadmin",
  "password": "secret",
}

Tenha em mente que a definição de back-end é o único lugar onde as credenciais são armazenadas em texto simples. Depois que o back-end é criado, os nomes de usuário/senhas são codificados com Base64 e armazenados como segredos do Kubernetes. A criação/updation de um backend é a única etapa que requer conhecimento das credenciais. Como tal, é uma operação somente de administrador, a ser realizada pelo administrador do Kubernetes/storage.

Ativar autenticação baseada em certificado

Backends novos e existentes podem usar um certificado e se comunicar com o back-end do ONTAP. Três parâmetros são necessários na definição de backend.

ClientCertificate: Valor codificado base64 do certificado do cliente.
ClientPrivateKey: Valor codificado em base64 da chave privada associada.
TrustedCACertificate: Valor codificado base64 do certificado CA confiável. Se estiver usando uma CA confiável, esse parâmetro deve ser fornecido. Isso pode ser ignorado se nenhuma CA confiável for usada.

Um fluxo de trabalho típico envolve as etapas a seguir.

Passos

Gerar um certificado e chave de cliente. Ao gerar, defina Nome Comum (CN) para o usuário ONTAP para autenticar como.

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"

Adicionar certificado de CA confiável ao cluster do ONTAP. Isso pode já ser Tratado pelo administrador do armazenamento. Ignore se nenhuma CA confiável for usada.

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>

Instale o certificado e a chave do cliente (a partir do passo 1) no cluster do ONTAP.

security certificate install -type client-ca -cert-name <certificate-name> -vserver <vserver-name>
security ssl modify -vserver <vserver-name> -client-enabled true

Confirme se a função de login de segurança do ONTAP suporta cert o método de autenticação.

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

Teste a autenticação usando certificado gerado. Substitua o ONTAP Management LIF> e o <vserver name> por IP de LIF de gerenciamento e nome da 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>'

Codificar certificado, chave e certificado CA confiável com Base64.

base64 -w 0 k8senv.pem >> cert_base64
base64 -w 0 k8senv.key >> key_base64
base64 -w 0 trustedca.pem >> trustedca_base64

Crie backend usando os valores obtidos na etapa anterior.

$ cat cert-backend.json
{
"version": 1,
"storageDriverName": "ontap-san",
"backendName": "SanBackend",
"managementLIF": "1.2.3.4",
"dataLIF": "1.2.3.8",
"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 |
+------------+----------------+--------------------------------------+--------+---------+

Atualizar métodos de autenticação ou girar credenciais

Você pode atualizar um back-end existente para fazer uso de um método de autenticação diferente ou para girar suas credenciais. Isso funciona de ambas as maneiras: Backends que fazem uso de nome de usuário / senha podem ser atualizados para usar certificados; backends que utilizam certificados podem ser atualizados para nome de usuário / senha com base. Para fazer isso, use um arquivo atualizado backend.json contendo os parâmetros necessários para executar `tridentctl backend update`o .

$ cat cert-backend-updated.json
{
"version": 1,
"storageDriverName": "ontap-san",
"backendName": "SanBackend",
"managementLIF": "1.2.3.4",
"dataLIF": "1.2.3.8",
"svm": "vserver_test",
"username": "vsadmin",
"password": "secret",
"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 |
+------------+----------------+--------------------------------------+--------+---------+

Ao girar senhas, o administrador de armazenamento deve primeiro atualizar a senha do usuário no ONTAP. Isso é seguido por uma atualização de back-end. Ao girar certificados, vários certificados podem ser adicionados ao usuário. O back-end é então atualizado para usar o novo certificado, seguindo o qual o certificado antigo pode ser excluído do cluster do ONTAP.

A atualização de um back-end não interrompe o acesso a volumes que já foram criados, nem afeta as conexões de volume feitas depois. Uma atualização de back-end bem-sucedida indica que o Astra Trident pode se comunicar com o back-end do ONTAP e lidar com operações de volume futuras.

Especifique grupos

O Astra Trident usa os grupos para controlar o acesso aos volumes (LUNs) provisionados. Os administradores têm duas opções quando se trata de especificar grupos para backends:

O Astra Trident pode criar e gerenciar automaticamente um grupo por back-end. Se igroupName não estiver incluído na definição de back-end, o Astra Trident criará um grupo nomeado trident-<backend-UUID> no SVM. Isso garantirá que cada back-end tenha um iggroup dedicado e tratará da adição/exclusão automatizada de IQNs do nó Kubernetes.
Alternativamente, os grupos pré-criados também podem ser fornecidos em uma definição de back-end. Isso pode ser feito usando o igroupName parâmetro config. O Astra Trident adicionará/excluirá IQNs de nós do Kubernetes ao grupo pré-existente.

Para backends que igroupName tenham definido, o igroupName pode ser excluído com um tridentctl backend update para ter os grupos de auto-manipulação Astra Trident. Isso não interromperá o acesso a volumes que já estão anexados a cargas de trabalho. Conexões futuras serão tratadas usando o igroup Astra Trident criado.

Dedicar um grupo para cada instância única do Astra Trident é uma prática recomendada que é benéfica para o administrador do Kubernetes, bem como para o administrador de storage. O CSI Trident automatiza a adição e remoção de IQNs de nó de cluster ao igrupo, simplificando muito seu gerenciamento. Ao usar o mesmo SVM em ambientes Kubernetes (e instalações Astra Trident), o uso de um grupo dedicado garante que as alterações feitas em um cluster do Kubernetes não influenciem os grupos associados a outro. Além disso, também é importante garantir que cada nó no cluster do Kubernetes tenha uma IQN exclusiva. Como mencionado acima, o Astra Trident lida automaticamente com a adição e remoção de IQNs. A reutilização de IQNs entre hosts pode levar a cenários indesejáveis nos quais os hosts se confundem uns com os outros e o acesso a LUNs é negado.

Se o Astra Trident estiver configurado para funcionar como um supervisor do CSI, os IQNs do nó do Kubernetes serão automaticamente adicionados/removidos do grupo. Quando os nós são adicionados a um cluster Kubernetes, trident-csi o DaemonSet implanta um pod (trident-csi-xxxxx) nos nós recém-adicionados e Registra os novos nós aos quais pode anexar volumes. Os IQNs de nó também são adicionados ao igroup do back-end. Um conjunto semelhante de etapas manipula a remoção de IQNs quando os nós são cordonados, drenados e excluídos do Kubernetes.

Se o Astra Trident não for executado como um supervisor de CSI, o grupo deve ser atualizado manualmente para conter os IQNs iSCSI de cada nó de trabalho no cluster do Kubernetes. As IQNs de nós que ingressam no cluster do Kubernetes precisarão ser adicionadas ao grupo. Da mesma forma, as IQNs de nós removidos do cluster do Kubernetes devem ser removidas do grupo.

Autentique conexões com CHAP bidirecional

O Astra Trident pode autenticar sessões iSCSI com CHAP bidirecional para os ontap-san drivers e ontap-san-economy. Isso requer a ativação da useCHAP opção na definição de backend. Quando definido como true, o Astra Trident configura a segurança do iniciador padrão do SVM para CHAP bidirecional e define o nome de usuário e os segredos do arquivo de back-end. O NetApp recomenda o uso de CHAP bidirecional para autenticar conexões. Veja a seguinte configuração de exemplo:

{
    "version": 1,
    "storageDriverName": "ontap-san",
    "backendName": "ontap_san_chap",
    "managementLIF": "192.168.0.135",
    "svm": "ontap_iscsi_svm",
    "useCHAP": true,
    "username": "vsadmin",
    "password": "FaKePaSsWoRd",
    "igroupName": "trident",
    "chapInitiatorSecret": "cl9qxIm36DKyawxy",
    "chapTargetInitiatorSecret": "rqxigXgkesIpwxyz",
    "chapTargetUsername": "iJF4heBRT0TCwxyz",
    "chapUsername": "uh2aNCLSd6cNwxyz",
}

O useCHAP parâmetro é uma opção booleana que pode ser configurada apenas uma vez. Ele é definido como false por padrão. Depois de configurá-lo como verdadeiro, você não pode configurá-lo como falso.

Além useCHAP=true do , os chapInitiatorSecret campos , chapTargetInitiatorSecret, chapTargetUsername, e chapUsername devem ser incluídos na definição de back-end. Os segredos podem ser alterados depois que um backend é criado executando tridentctl update.

Como funciona

Ao definir useCHAP como verdadeiro, o administrador de storage instrui o Astra Trident a configurar o CHAP no back-end de storage. Isso inclui o seguinte:

Configuração do CHAP no SVM:
- Se o tipo de segurança do iniciador padrão da SVM for nenhum (definido por padrão) e não houver LUNs pré-existentes no volume, o Astra Trident definirá o tipo de segurança padrão CHAP e continuará configurando o iniciador CHAP e o nome de usuário e os segredos de destino.
- Se o SVM contiver LUNs, o Astra Trident não ativará o CHAP no SVM. Isso garante que o acesso a LUNs que já estão presentes no SVM não seja restrito.
Configurando o iniciador CHAP e o nome de usuário e os segredos de destino; essas opções devem ser especificadas na configuração de back-end (como mostrado acima).
Gerenciando a adição de iniciadores ao igroupName dado no back-end. Se não for especificado, o padrão é trident.

Depois que o back-end é criado, o Astra Trident cria um CRD correspondente tridentbackend e armazena os segredos e nomes de usuário do CHAP como segredos do Kubernetes. Todos os PVS criados pelo Astra Trident neste back-end serão montados e anexados através do CHAP.

Gire credenciais e atualize os backends

Você pode atualizar as credenciais CHAP atualizando os parâmetros CHAP no backend.json arquivo. Isso exigirá a atualização dos segredos CHAP e o uso do tridentctl update comando para refletir essas alterações.

Ao atualizar os segredos CHAP para um backend, você deve usar tridentctl para atualizar o backend. Não atualize as credenciais no cluster de storage por meio da IU da CLI/ONTAP, pois o Astra Trident não conseguirá aceitar essas alterações.

$ 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": "FaKePaSsWoRd",
    "igroupName": "trident",
    "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 |
+----------------+----------------+--------------------------------------+--------+---------+

As conexões existentes não serão afetadas. Elas continuarão ativas se as credenciais forem atualizadas pelo Astra Trident no SVM. As novas conexões usarão as credenciais atualizadas e as conexões existentes continuam ativas. Desconetar e reconetar PVS antigos resultará em eles usando as credenciais atualizadas.