Segurança
Use as recomendações listadas aqui para garantir a segurança da instalação do seu Astra Trident.
Execute o Astra Trident em seu próprio namespace
É importante impedir que aplicações, administradores de aplicações, usuários e aplicações de gerenciamento acessem as definições de objetos do Astra Trident ou os pods para garantir um storage confiável e bloquear atividades maliciosas em potencial.
Para separar as outras aplicações e usuários do Astra Trident, instale sempre o Astra Trident em seu próprio namespace Kubernetes (trident
). A colocação do Astra Trident em seu próprio namespace garante que apenas o pessoal administrativo do Kubernetes tenha acesso ao pod Astra Trident e aos artefatos (como segredos de back-end e CHAP, se aplicável) armazenados nos objetos CRD com namespaces. Você deve garantir que somente os administradores acessem o namespace Astra Trident e, assim, o acesso tridentctl
à aplicação.
Use a autenticação CHAP com backends ONTAP SAN
O Astra Trident é compatível com autenticação baseada em CHAP para workloads SAN ONTAP (usando os ontap-san
drivers e ontap-san-economy
). A NetApp recomenda o uso de CHAP bidirecional com Astra Trident para autenticação entre um host e o back-end de storage.
Para backends ONTAP que usam os drivers de armazenamento SAN, o Astra Trident pode configurar CHAP bidirecional e gerenciar nomes de usuário e segredos do CHAP por meio `tridentctl`do . Veja "aqui" para entender como o Astra Trident configura o CHAP nos backends do ONTAP.
|
O suporte CHAP para backends ONTAP está disponível com o Trident 20,04 e posterior. |
Use a autenticação CHAP com backends NetApp HCI e SolidFire
O NetApp recomenda a implantação de CHAP bidirecional para garantir a autenticação entre um host e os backends NetApp HCI e SolidFire. O Astra Trident usa um objeto secreto que inclui duas senhas CHAP por locatário. Quando o Trident é instalado como um provisionador CSI, ele gerencia os segredos CHAP e os armazena em um tridentvolume
objeto CR para o respetivo PV. Quando você cria um PV, o CSI Astra Trident usa os segredos CHAP para iniciar uma sessão iSCSI e se comunicar com o sistema NetApp HCI e SolidFire através do CHAP.
|
Os volumes criados pelo CSI Trident não estão associados a nenhum Grupo de Acesso por volume. |
No frontend não-CSI, a vinculação de volumes como dispositivos nos nós de trabalho é tratada pelo Kubernetes. Após a criação de volume, o Astra Trident faz uma chamada de API para o sistema NetApp HCI/SolidFire para recuperar os segredos se o segredo para esse locatário ainda não existir. Em seguida, o Astra Trident passa os segredos para o Kubernetes. O kubelet localizado em cada nó acessa os segredos por meio da API do Kubernetes e os usa para executar/habilitar o CHAP entre cada nó acessando o volume e o sistema NetApp HCI/SolidFire onde os volumes estão localizados.
Use o Astra Trident com NVE e NAE
O NetApp ONTAP fornece criptografia de dados em repouso para proteger dados confidenciais caso um disco seja roubado, retornado ou reutilizado. Para obter detalhes, "Configurar a visão geral da encriptação de volume do NetApp"consulte .
-
Se o NAE estiver ativado no back-end, qualquer volume provisionado no Astra Trident será habilitado para NAE.
-
Se o NAE não estiver habilitado no back-end, qualquer volume provisionado no Astra Trident será habilitado para NVE, a menos que você defina o sinalizador de criptografia NVE como
false
na configuração de back-end.
|
Os volumes criados no Astra Trident em um back-end habilitado para NAE devem ser criptografados com NVE ou NAE.
|
-
Você pode criar manualmente um volume NVE no Astra Trident definindo explicitamente o sinalizador de criptografia NVE como
true
.
Para obter mais informações sobre opções de configuração de back-end, consulte:
Habilite a criptografia por volume no lado do host usando o Linux Unified Key Setup (LUKS)
Você pode ativar o LUKS (configuração de chave unificada do Linux) para criptografar volumes DE ECONOMIA SAN ONTAP e SAN ONTAP no Astra Trident. No Astra Trident, os volumes criptografados por LUKS usam a cifra e o modo aes-xts-plain64, conforme recomendado "NIST"pelo .
Para obter mais informações sobre opções de configuração de back-end para SAN ONTAP, consulte "Opções de configuração de SAN ONTAP"
-
Os nós de trabalho devem ter o cryptsetup 2,1 ou superior instalado. Para obter mais informações, visite "Gitlab: Cryptsetup".
-
Por motivos de desempenho, recomendamos que os nós de trabalho suportem Advanced Encryption Standard New Instructions (AES-NI). Para verificar o suporte ao AES-NI, execute o seguinte comando:
grep "aes" /proc/cpuinfo
Se nada for devolvido, o processador não suporta AES-NI. Para obter mais informações sobre o AES-NI, visite: "Intel: Advanced Encryption Standard Instructions (AES-NI)".
-
Defina atributos de criptografia LUKS na configuração de back-end.
"storage": [ { "labels":{"luks": "true"}, "zone":"us_east_1a", "defaults": { "luksEncryption": "true" } }, { "labels":{"luks": "false"}, "zone":"us_east_1a", "defaults": { "luksEncryption": "false" } }, ]
-
Use
parameters.selector
para definir os pools de armazenamento usando a criptografia LUKS. Por exemplo:apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: luks provisioner: netapp.io/trident parameters: selector: "luks=true" csi.storage.k8s.io/node-stage-secret-name: luks-${pvc.name} csi.storage.k8s.io/node-stage-secret-namespace: ${pvc.namespace}
-
Crie um segredo que contenha a frase-passe LUKS. Por exemplo:
apiVersion: v1 kind: Secret metadata: name: luks-pvc1 stringData: luks-passphrase-name: B luks-passphrase: secretB previous-luks-passphrase-name: A previous-luks-passphrase: secretA
Limitações
-
Os volumes criptografados LUKS não poderão aproveitar a deduplicação e a compactação do ONTAP.
-
Neste momento, a rotação da frase-passe LUKS não é suportada. Para alterar senhas, copie manualmente os dados de um PVC para outro.