Skip to main content
Astra Control Service
All cloud providers
  • Amazon Web Services
  • Google Cloud
  • Microsoft Azure
  • All cloud providers

Configure storage backend encryption

Contributors netapp-mwallis netapp-dbagwell
PDFs

Using Astra Control Provisioner, you can improve data access security by enabling encryption for the traffic between your managed cluster and the storage backend.

Astra Control Provisioner supports Kerberos encryption for two types of storage backends:

  • On-premises ONTAP - Astra Control Provisioner supports Kerberos encryption over NFSv3 and NFSv4 connections from Red Hat OpenShift and upstream Kubernetes clusters to on-premises ONTAP volumes.

  • Azure NetApp Files - Astra Control Provisioner supports Kerberos encryption over NFSv4.1 connections from upstream Kubernetes clusters to Azure NetApp Files volumes.

You can create, delete, resize, snapshot, clone, read-only clone, and import volumes that use NFS encryption.

Configure in-flight Kerberos encryption with on-premises ONTAP volumes

You can enable Kerberos encryption on the storage traffic between your managed cluster and an on-premises ONTAP storage backend.

Note Kerberos encryption for NFS traffic with on-premises ONTAP storage backends is only supported using the ontap-nas storage driver.
Before you begin

  • Ensure that you have enabled Astra Control Provisioner on the managed cluster.

  • Ensure that you have access to the tridentctl utility.

  • Ensure you have administrator access to the ONTAP storage backend.

  • Ensure you know the name of the volume or volumes you will be sharing from the ONTAP storage backend.

  • Ensure that you have prepared the ONTAP storage VM to support Kerberos encryption for NFS volumes. Refer to Enable Kerberos on a data LIF for instructions.

  • Ensure that any NFSv4 volumes you use with Kerberos encryption are configured correctly. Refer to the NetApp NFSv4 Domain Configuration section (page 13) of the NetApp NFSv4 Enhancements and Best Practices Guide.

Add or modify ONTAP export policies

You need to add rules to existing ONTAP export policies or create new export polices that support Kerberos encryption for the ONTAP storage VM root volume as well as any ONTAP volumes shared with the upstream Kubernetes cluster. The export policy rules you add, or new export policies you create, need to support the following access protocols and access permissions:

Access protocols

Configure the export policy with NFS, NFSv3, and NFSv4 access protocols.

Access details

You can configure one of three different versions of Kerberos encryption, depending on your needs for the volume:

  • Kerberos 5 - (authentication and encryption)

  • Kerberos 5i - (authentication and encryption with identity protection)

  • Kerberos 5p - (authentication and encryption with identity and privacy protection)

Configure the ONTAP export policy rule with the appropriate access permissions. For example, if clusters will be mounting the NFS volumes with a mixture of Kerberos 5i and Kerberos 5p encryption, use the following access settings:

Type Read-only access Read/Write access Superuser access

UNIX

Enabled

Enabled

Enabled

Kerberos 5i

Enabled

Enabled

Enabled

Kerberos 5p

Enabled

Enabled

Enabled

Refer to the following documentation for how to create ONTAP export policies and export policy rules:

Create a storage backend

You can create an Astra Control Provisioner storage backend configuration that includes Kerberos encryption capability.

About this task

When you create a storage backend configuration file that configures Kerberos encryption, you can specify one of three different versions of Kerberos encryption using the spec.nfsMountOptions parameter:

  • spec.nfsMountOptions: sec=krb5 (authentication and encryption)

  • spec.nfsMountOptions: sec=krb5i (authentication and encryption with identity protection)

  • spec.nfsMountOptions: sec=krb5p (authentication and encryption with identity and privacy protection)

Specify only one Kerberos level. If you specify more than one Kerberos encryption level in the parameter list, only the first option is used.

Steps

  1. On the managed cluster, create a storage backend configuration file using the following example. Replace values in brackets <> with information from your environment:

    apiVersion: v1
kind: Secret
metadata:
  name: backend-ontap-nas-secret
type: Opaque
stringData:
  clientID: <CLIENT_ID>
  clientSecret: <CLIENT_SECRET>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-ontap-nas
spec:
  version: 1
  storageDriverName: "ontap-nas"
  managementLIF: <STORAGE_VM_MGMT_LIF_IP_ADDRESS>
  dataLIF: <PROTOCOL_LIF_FQDN_OR_IP_ADDRESS>
  svm: <STORAGE_VM_NAME>
  username: <STORAGE_VM_USERNAME_CREDENTIAL>
  password: <STORAGE_VM_PASSWORD_CREDENTIAL>
  nasType: nfs
  nfsMountOptions: ["sec=krb5i"] #can be krb5, krb5i, or krb5p
  qtreesPerFlexvol:
  credentials:
    name: backend-ontap-nas-secret

  2. Use the configuration file you created in the previous step to create the backend:

    tridentctl create backend -f <backend-configuration-file>

    If the backend creation fails, something is wrong with the backend configuration. You can view the logs to determine the cause by running the following command:

    tridentctl logs

    After you identify and correct the problem with the configuration file, you can run the create command again.

Create a storage class

You can create a storage class to provision volumes with Kerberos encryption.

About this task

When you create a storage class object, you can specify one of three different versions of Kerberos encryption using the mountOptions parameter:

  • mountOptions: sec=krb5 (authentication and encryption)

  • mountOptions: sec=krb5i (authentication and encryption with identity protection)

  • mountOptions: sec=krb5p (authentication and encryption with identity and privacy protection)

Specify only one Kerberos level. If you specify more than one Kerberos encryption level in the parameter list, only the first option is used. If the level of encryption you specified in the storage backend configuration is different than the level you specify in the storage class object, the storage class object takes precedence.

Steps

  1. Create a StorageClass Kubernetes object, using the following example:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ontap-nas-sc
provisioner: csi.trident.netapp.io
mountOptions: ["sec=krb5i"] #can be krb5, krb5i, or krb5p
parameters:
  backendType: "ontap-nas"
  storagePools: "ontapnas_pool"
  trident.netapp.io/nasType: "nfs"
allowVolumeExpansion: True

  2. Create the storage class:

    kubectl create -f sample-input/storage-class-ontap-nas-sc.yaml

  3. Make sure that the storage class has been created:

    kubectl get sc ontap-nas-sc

    You should see output similar to the following:

    NAME            PROVISIONER             AGE
ontap-nas-sc    csi.trident.netapp.io   15h

Provision volumes

After you create a storage backend and a storage class, you can now provision a volume. Refer to these instructions for provisioning a volume.

Configure in-flight Kerberos encryption with Azure NetApp Files volumes

You can enable Kerberos encryption on the storage traffic between your managed cluster and a single Azure NetApp Files storage backend or a virtual pool of Azure NetApp Files storage backends.

Before you begin

  • Ensure that you have enabled Astra Control Provisioner on the managed Red Hat OpenShift cluster. Refer to Enable Astra Control Provisioner for instructions.

  • Ensure that you have access to the tridentctl utility.

  • Ensure that you have prepared the Azure NetApp Files storage backend for Kerberos encryption by noting the requirements and following the instructions in Azure NetApp Files documentation.

  • Ensure that any NFSv4 volumes you use with Kerberos encryption are configured correctly. Refer to the NetApp NFSv4 Domain Configuration section (page 13) of the NetApp NFSv4 Enhancements and Best Practices Guide.

Create a storage backend

You can create an Azure NetApp Files storage backend configuration that includes Kerberos encryption capability.

About this task

When you create a storage backend configuration file that configures Kerberos encryption, you can define it so that it should be applied at one of two possible levels:

  • The storage backend level using the spec.kerberos field

  • The virtual pool level using the spec.storage.kerberos field

When you define the configuration at the virtual pool level, the pool is selected using the label in the storage class.

At either level, you can specify one of three different versions of Kerberos encryption:

  • kerberos: sec=krb5 (authentication and encryption)

  • kerberos: sec=krb5i (authentication and encryption with identity protection)

  • kerberos: sec=krb5p (authentication and encryption with identity and privacy protection)

Steps

  1. On the managed cluster, create a storage backend configuration file using one of the following examples, depending on where you need to define the storage backend (storage backend level or virtual pool level). Replace values in brackets <> with information from your environment:

    Storage backend level example
    apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-anf-secret
type: Opaque
stringData:
  clientID: <CLIENT_ID>
  clientSecret: <CLIENT_SECRET>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-tbc-anf
spec:
  version: 1
  storageDriverName: azure-netapp-files
  subscriptionID: <SUBSCRIPTION_ID>
  tenantID: <TENANT_ID>
  location: <AZURE_REGION_LOCATION>
  serviceLevel: Standard
  networkFeatures: Standard
  capacityPools: <CAPACITY_POOL>
  resourceGroups: <RESOURCE_GROUP>
  netappAccounts: <NETAPP_ACCOUNT>
  virtualNetwork: <VIRTUAL_NETWORK>
  subnet: <SUBNET>
  nasType: nfs
  kerberos: sec=krb5i #can be krb5, krb5i, or krb5p
  credentials:
    name: backend-tbc-anf-secret
    Virtual pool level example
    apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-anf-secret
type: Opaque
stringData:
  clientID: <CLIENT_ID>
  clientSecret: <CLIENT_SECRET>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-tbc-anf
spec:
  version: 1
  storageDriverName: azure-netapp-files
  subscriptionID: <SUBSCRIPTION_ID>
  tenantID: <TENANT_ID>
  location: <AZURE_REGION_LOCATION>
  serviceLevel: Standard
  networkFeatures: Standard
  capacityPools: <CAPACITY_POOL>
  resourceGroups: <RESOURCE_GROUP>
  netappAccounts: <NETAPP_ACCOUNT>
  virtualNetwork: <VIRTUAL_NETWORK>
  subnet: <SUBNET>
  nasType: nfs
  storage:
    - labels:
        type: encryption
      kerberos: sec=krb5i #can be krb5, krb5i, or krb5p
  credentials:
    name: backend-tbc-anf-secret

  2. Use the configuration file you created in the previous step to create the backend:

    tridentctl create backend -f <backend-configuration-file>

    If the backend creation fails, something is wrong with the backend configuration. You can view the logs to determine the cause by running the following command:

    tridentctl logs

    After you identify and correct the problem with the configuration file, you can run the create command again.

Create a storage class

You can create a storage class to provision volumes with Kerberos encryption.

Steps

  1. Create a StorageClass Kubernetes object, using the following example:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: anf-sc-nfs
provisioner: csi.trident.netapp.io
parameters:
  backendType: "azure-netapp-files"
  trident.netapp.io/nasType: "nfs"
  selector: "type=encryption"

  2. Create the storage class:

    kubectl create -f sample-input/storage-class-anf-sc-nfs.yaml

  3. Make sure that the storage class has been created:

    kubectl get sc anf-sc-nfs

    You should see output similar to the following:

    NAME         PROVISIONER             AGE
anf-sc-nfs    csi.trident.netapp.io   15h

Provision volumes

After you create a storage backend and a storage class, you can now provision a volume. Refer to these instructions for provisioning a volume.