스토리지 백엔드 암호화를 구성합니다
Astra Control Provisioner를 사용하면 관리형 클러스터와 스토리지 백엔드 간의 트래픽 암호화를 활성화하여 데이터 액세스 보안을 개선할 수 있습니다.
Astra Control Provisioner는 두 가지 유형의 스토리지 백엔드에 대해 Kerberos 암호화를 지원합니다.
-
* 온프레미스 ONTAP * - Astra Control Provisioner는 Red Hat OpenShift 및 업스트림 Kubernetes 클러스터에서 온프레미스 ONTAP 볼륨까지 NFSv3 및 NFSv4 연결을 통해 Kerberos 암호화를 지원합니다.
-
* Azure NetApp Files * - Astra Control Provisioner는 업스트림 Kubernetes 클러스터에서 Azure NetApp Files 볼륨으로의 NFSv4.1 연결을 통한 Kerberos 암호화를 지원합니다.
따라서 스냅샷을 생성하고, 삭제하고, 크기 조정하고, 스냅샷, 클론 읽기 전용 클론 생성 및 NFS 암호화를 사용하는 볼륨 가져오기
사내 ONTAP 볼륨과 전송 중인 Kerberos 암호화를 구성합니다
관리 클러스터와 온프레미스 ONTAP 스토리지 백엔드 사이의 스토리지 트래픽에 Kerberos 암호화를 활성화할 수 있습니다.
온프레미스 ONTAP 스토리지 백엔드를 통한 NFS 트래픽에 대한 Kerberos 암호화는 를 사용해야만 지원됩니다 ontap-nas 스토리지 드라이버.
|
-
가 있는지 확인합니다 "Astra Control Provisioner를 활성화했습니다" 관리 대상 클러스터에서.
-
에 액세스할 수 있는지 확인합니다
tridentctl
유틸리티. -
ONTAP 스토리지 백엔드에 대한 관리자 액세스 권한이 있어야 합니다.
-
ONTAP 스토리지 백엔드에서 공유할 볼륨의 이름을 알고 있어야 합니다.
-
NFS 볼륨에 대한 Kerberos 암호화를 지원하는 ONTAP 스토리지 VM을 준비했는지 확인합니다. 을 참조하십시오 "데이터 LIF에서 Kerberos를 사용하도록 설정합니다" 를 참조하십시오.
-
Kerberos 암호화로 사용하는 NFSv4 볼륨이 올바르게 구성되어 있는지 확인합니다. 의 NetApp NFSv4 도메인 구성 섹션(13페이지)을 참조하십시오 "NetApp NFSv4의 향상된 기능 및 모범 사례 가이드 를 참조하십시오".
ONTAP 엑스포트 정책을 추가 또는 수정합니다
기존 ONTAP 엑스포트 정책에 규칙을 추가하거나, ONTAP 스토리지 VM 루트 볼륨뿐 아니라 업스트림 Kubernetes 클러스터와 공유된 ONTAP 볼륨에 대해 Kerberos 암호화를 지원하는 새 엑스포트 정책을 생성해야 합니다. 추가한 내보내기 정책 규칙 또는 새로 만든 내보내기 정책은 다음 액세스 프로토콜 및 액세스 권한을 지원해야 합니다.
NFS, NFSv3 및 NFSv4 액세스 프로토콜을 사용하여 엑스포트 정책을 구성합니다.
볼륨에 대한 필요에 따라 세 가지 Kerberos 암호화 버전 중 하나를 구성할 수 있습니다.
-
* Kerberos 5 * - (인증 및 암호화)
-
* Kerberos 5i * - (인증 및 ID 보호 암호화)
-
* Kerberos 5p * - (인증 및 암호화, ID 및 개인 정보 보호)
적절한 액세스 권한을 사용하여 ONTAP 엑스포트 정책 규칙을 구성합니다. 예를 들어, 클러스터가 Kerberos 5i 및 Kerberos 5p 암호화가 혼합된 NFS 볼륨을 마운트하는 경우 다음 액세스 설정을 사용합니다.
유형 | 읽기 전용 액세스 | 읽기/쓰기 권한 | 고급 사용자 액세스 |
---|---|---|---|
Unix |
활성화됨 |
활성화됨 |
활성화됨 |
Kerberos 5i |
활성화됨 |
활성화됨 |
활성화됨 |
Kerberos 5p |
활성화됨 |
활성화됨 |
활성화됨 |
ONTAP 엑스포트 정책과 엑스포트 정책 규칙을 생성하는 방법은 다음 문서를 참조하십시오.
스토리지 백엔드를 생성합니다
Kerberos 암호화 기능을 포함하는 Astra Control Provisioner 스토리지 백엔드 구성을 생성할 수 있습니다.
Kerberos 암호화를 구성하는 스토리지 백엔드 구성 파일을 만들 때 를 사용하여 세 가지 Kerberos 암호화 버전 중 하나를 지정할 수 있습니다 spec.nfsMountOptions
매개 변수:
-
spec.nfsMountOptions: sec=krb5
(인증 및 암호화) -
spec.nfsMountOptions: sec=krb5i
(인증 및 암호화, ID 보호) -
spec.nfsMountOptions: sec=krb5p
(인증 및 암호화, ID 및 개인 정보 보호)
Kerberos 수준을 하나만 지정하십시오. 매개 변수 목록에서 Kerberos 암호화 수준을 두 개 이상 지정하면 첫 번째 옵션만 사용됩니다.
-
관리되는 클러스터에서 다음 예제를 사용하여 스토리지 백엔드 구성 파일을 생성합니다. 괄호 안의 값을 사용자 환경의 정보로 대체:
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
-
이전 단계에서 생성한 구성 파일을 사용하여 백엔드를 생성합니다.
tridentctl create backend -f <backend-configuration-file>
백엔드 생성에 실패하면 백엔드 구성에 문제가 있는 것입니다. 다음 명령을 실행하여 로그를 보고 원인을 확인할 수 있습니다.
tridentctl logs
구성 파일의 문제를 확인하고 수정한 후 create 명령을 다시 실행할 수 있습니다.
스토리지 클래스를 생성합니다
스토리지 클래스를 만들어 Kerberos 암호화를 사용하여 볼륨을 프로비저닝할 수 있습니다.
저장소 클래스 개체를 만들 때 를 사용하여 세 가지 Kerberos 암호화 버전 중 하나를 지정할 수 있습니다 mountOptions
매개 변수:
-
mountOptions: sec=krb5
(인증 및 암호화) -
mountOptions: sec=krb5i
(인증 및 암호화, ID 보호) -
mountOptions: sec=krb5p
(인증 및 암호화, ID 및 개인 정보 보호)
Kerberos 수준을 하나만 지정하십시오. 매개 변수 목록에서 Kerberos 암호화 수준을 두 개 이상 지정하면 첫 번째 옵션만 사용됩니다. 스토리지 백엔드 구성에서 지정한 암호화 수준이 스토리지 클래스 객체에 지정한 레벨과 다른 경우 스토리지 클래스 객체가 우선합니다.
-
다음 예제를 사용하여 StorageClass Kubernetes 개체를 생성합니다.
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
-
스토리지 클래스를 생성합니다.
kubectl create -f sample-input/storage-class-ontap-nas-sc.yaml
-
스토리지 클래스가 생성되었는지 확인합니다.
kubectl get sc ontap-nas-sc
다음과 유사한 출력이 표시됩니다.
NAME PROVISIONER AGE ontap-nas-sc csi.trident.netapp.io 15h
볼륨 프로비저닝
스토리지 백엔드와 스토리지 클래스를 생성한 후 이제 볼륨을 프로비저닝할 수 있습니다. 에 대해서는 이 지침을 참조하십시오 "볼륨 프로비저닝".
Azure NetApp Files 볼륨과 함께 전송 중인 Kerberos 암호화를 구성합니다
관리 클러스터와 단일 Azure NetApp Files 스토리지 백엔드 또는 Azure NetApp Files 스토리지 백엔드의 가상 풀 사이의 스토리지 트래픽에 Kerberos 암호화를 활성화할 수 있습니다.
-
관리형 Red Hat OpenShift 클러스터에서 Astra Control Provisioner를 활성화했는지 확인합니다. 을 참조하십시오 "Astra Control Provisioner를 활성화합니다" 를 참조하십시오.
-
에 액세스할 수 있는지 확인합니다
tridentctl
유틸리티. -
요구 사항을 확인하고 의 지침에 따라 Kerberos 암호화용 Azure NetApp Files 스토리지 백엔드를 준비했는지 확인합니다 "Azure NetApp Files 설명서".
-
Kerberos 암호화로 사용하는 NFSv4 볼륨이 올바르게 구성되어 있는지 확인합니다. 의 NetApp NFSv4 도메인 구성 섹션(13페이지)을 참조하십시오 "NetApp NFSv4의 향상된 기능 및 모범 사례 가이드 를 참조하십시오".
스토리지 백엔드를 생성합니다
Kerberos 암호화 기능을 포함하는 Azure NetApp Files 스토리지 백엔드 구성을 만들 수 있습니다.
Kerberos 암호화를 구성하는 스토리지 백엔드 구성 파일을 만들 때 다음 두 가지 가능한 수준 중 하나에 적용되도록 정의할 수 있습니다.
-
를 사용하는 * 스토리지 백엔드 레벨 *
spec.kerberos
필드에 입력합니다 -
를 사용하는 * 가상 풀 레벨 *
spec.storage.kerberos
필드에 입력합니다
가상 풀 레벨에서 구성을 정의하면 스토리지 클래스의 레이블을 사용하여 풀이 선택됩니다.
두 레벨에서 Kerberos 암호화의 세 가지 버전 중 하나를 지정할 수 있습니다.
-
kerberos: sec=krb5
(인증 및 암호화) -
kerberos: sec=krb5i
(인증 및 암호화, ID 보호) -
kerberos: sec=krb5p
(인증 및 암호화, ID 및 개인 정보 보호)
-
관리되는 클러스터에서 스토리지 백엔드(스토리지 백엔드 레벨 또는 가상 풀 레벨)를 정의해야 하는 위치에 따라 다음 예제 중 하나를 사용하여 스토리지 백엔드 구성 파일을 생성합니다. 괄호 안의 값을 사용자 환경의 정보로 대체:
스토리지 백엔드 레벨의 예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
가상 풀 레벨 예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
-
이전 단계에서 생성한 구성 파일을 사용하여 백엔드를 생성합니다.
tridentctl create backend -f <backend-configuration-file>
백엔드 생성에 실패하면 백엔드 구성에 문제가 있는 것입니다. 다음 명령을 실행하여 로그를 보고 원인을 확인할 수 있습니다.
tridentctl logs
구성 파일의 문제를 확인하고 수정한 후 create 명령을 다시 실행할 수 있습니다.
스토리지 클래스를 생성합니다
스토리지 클래스를 만들어 Kerberos 암호화를 사용하여 볼륨을 프로비저닝할 수 있습니다.
-
다음 예제를 사용하여 StorageClass Kubernetes 개체를 생성합니다.
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"
-
스토리지 클래스를 생성합니다.
kubectl create -f sample-input/storage-class-anf-sc-nfs.yaml
-
스토리지 클래스가 생성되었는지 확인합니다.
kubectl get sc anf-sc-nfs
다음과 유사한 출력이 표시됩니다.
NAME PROVISIONER AGE anf-sc-nfs csi.trident.netapp.io 15h
볼륨 프로비저닝
스토리지 백엔드와 스토리지 클래스를 생성한 후 이제 볼륨을 프로비저닝할 수 있습니다. 에 대해서는 이 지침을 참조하십시오 "볼륨 프로비저닝".