ONTAP SAN 드라이버로 백엔드 구성을 준비합니다.
ONTAP SAN 드라이버로 ONTAP 백엔드를 구성하기 위한 요구 사항과 인증 옵션을 이해합니다.
요구 사항
모든 ONTAP 백엔드의 경우 Trident 최소한 하나의 집계가 SVM에 할당되어야 합니다.
|
|
"ASA r2 시스템"다른 ONTAP 시스템(ASA, AFF 및 FAS)과 저장 계층 구현 방식이 다릅니다. ASA r2 시스템에서는 집계 대신 스토리지 가용성 영역이 사용됩니다. 참조하다"이것" ASA r2 시스템에서 SVM에 집계를 할당하는 방법에 대한 지식 기반 문서입니다. |
두 개 이상의 드라이버를 실행하고, 하나 또는 다른 하나를 가리키는 스토리지 클래스를 생성할 수도 있습니다. 예를 들어 다음을 구성할 수 있습니다. san-dev 를 사용하는 클래스 ontap-san 운전자와 san-default 를 사용하는 클래스 ontap-san-economy 하나.
모든 Kubernetes 워커 노드에는 적절한 iSCSI 도구가 설치되어 있어야 합니다. 참조하다 "워커 노드 준비" 자세한 내용은.
ONTAP 백엔드 인증
Trident ONTAP 백엔드를 인증하는 두 가지 모드를 제공합니다.
-
자격 증명 기반: 필요한 권한이 있는 ONTAP 사용자의 사용자 이름과 비밀번호입니다. 다음과 같은 미리 정의된 보안 로그인 역할을 사용하는 것이 좋습니다.
admin또는vsadminONTAP 버전과의 최대 호환성을 보장합니다. -
인증서 기반: Trident 백엔드에 설치된 인증서를 사용하여 ONTAP 클러스터와 통신할 수도 있습니다. 여기서 백엔드 정의에는 클라이언트 인증서, 키, 신뢰할 수 있는 CA 인증서(사용되는 경우)의 Base64 인코딩 값이 포함되어야 합니다(권장).
기존 백엔드를 업데이트하여 자격 증명 기반 방식과 인증서 기반 방식 사이를 전환할 수 있습니다. 하지만 한 번에 하나의 인증 방법만 지원됩니다. 다른 인증 방법으로 전환하려면 백엔드 구성에서 기존 방법을 제거해야 합니다.
|
|
*자격 증명과 인증서*를 모두 제공하려고 하면 구성 파일에 두 개 이상의 인증 방법이 제공되었다는 오류와 함께 백엔드 생성이 실패합니다. |
자격 증명 기반 인증 활성화
Trident ONTAP 백엔드와 통신하기 위해 SVM 범위/클러스터 범위 관리자의 자격 증명이 필요합니다. 다음과 같은 표준 사전 정의된 역할을 활용하는 것이 좋습니다. admin 또는 vsadmin . 이를 통해 향후 Trident 릴리스에서 사용할 수 있는 기능 API를 공개할 수 있는 향후 ONTAP 릴리스와의 호환성이 보장됩니다. Trident 사용하면 사용자 정의 보안 로그인 역할을 만들어 사용할 수 있지만 권장하지는 않습니다.
백엔드 정의의 예는 다음과 같습니다.
---
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"
}
백엔드 정의는 자격 증명이 일반 텍스트로 저장되는 유일한 곳이라는 점을 명심하세요. 백엔드가 생성된 후 사용자 이름/비밀번호는 Base64로 인코딩되어 Kubernetes 비밀로 저장됩니다. 백엔드를 만들거나 업데이트하는 것은 자격 증명에 대한 지식이 필요한 유일한 단계입니다. 따라서 이는 Kubernetes/스토리지 관리자가 수행해야 하는 관리자 전용 작업입니다.
인증서 기반 인증 활성화
새로운 백엔드와 기존 백엔드는 인증서를 사용하고 ONTAP 백엔드와 통신할 수 있습니다. 백엔드 정의에는 세 개의 매개변수가 필요합니다.
-
clientCertificate: 클라이언트 인증서의 Base64로 인코딩된 값입니다.
-
clientPrivateKey: 연관된 개인 키의 Base64 인코딩된 값입니다.
-
trustedCACertificate: 신뢰할 수 있는 CA 인증서의 Base64로 인코딩된 값입니다. 신뢰할 수 있는 CA를 사용하는 경우 이 매개변수를 제공해야 합니다. 신뢰할 수 있는 CA를 사용하지 않으면 무시할 수 있습니다.
일반적인 작업 흐름은 다음 단계로 구성됩니다.
-
클라이언트 인증서와 키를 생성합니다. 생성할 때, 인증할 ONTAP 사용자로 일반 이름(CN)을 설정합니다.
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"
-
ONTAP 클러스터에 신뢰할 수 있는 CA 인증서를 추가합니다. 이 문제는 이미 스토리지 관리자가 처리했을 수도 있습니다. 신뢰할 수 있는 CA가 사용되지 않으면 무시합니다.
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>
-
ONTAP 클러스터에 클라이언트 인증서와 키(1단계)를 설치합니다.
security certificate install -type client-ca -cert-name <certificate-name> -vserver <vserver-name> security ssl modify -vserver <vserver-name> -client-enabled true
-
ONTAP 보안 로그인 역할이 지원되는지 확인하세요.
cert인증방법.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
-
생성된 인증서를 사용하여 인증을 테스트합니다. < ONTAP 관리 LIF> 및 <vserver 이름>을 관리 LIF IP 및 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>'
-
Base64로 인증서, 키 및 신뢰할 수 있는 CA 인증서를 인코딩합니다.
base64 -w 0 k8senv.pem >> cert_base64 base64 -w 0 k8senv.key >> key_base64 base64 -w 0 trustedca.pem >> trustedca_base64
-
이전 단계에서 얻은 값을 사용하여 백엔드를 생성합니다.
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 | +------------+----------------+--------------------------------------+--------+---------+
인증 방법 업데이트 또는 자격 증명 순환
기존 백엔드를 업데이트하여 다른 인증 방법을 사용하거나 자격 증명을 순환할 수 있습니다. 이는 양방향으로 작동합니다. 사용자 이름/비밀번호를 사용하는 백엔드는 인증서를 사용하도록 업데이트할 수 있고, 인증서를 활용하는 백엔드는 사용자 이름/비밀번호 기반으로 업데이트할 수 있습니다. 이렇게 하려면 기존 인증 방법을 제거하고 새로운 인증 방법을 추가해야 합니다. 그런 다음 필요한 매개변수를 포함하는 업데이트된 backend.json 파일을 사용하여 실행합니다. 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 |
+------------+----------------+--------------------------------------+--------+---------+
|
|
비밀번호를 순환할 때 스토리지 관리자는 먼저 ONTAP 에서 사용자의 비밀번호를 업데이트해야 합니다. 이어서 백엔드 업데이트가 진행됩니다. 인증서를 순환할 때 사용자에게 여러 개의 인증서를 추가할 수 있습니다. 그런 다음 백엔드를 업데이트하여 새 인증서를 사용하고, 그 후 ONTAP 클러스터에서 이전 인증서를 삭제할 수 있습니다. |
백엔드를 업데이트해도 이미 생성된 볼륨에 대한 액세스는 중단되지 않으며, 이후에 만들어진 볼륨 연결에도 영향을 미치지 않습니다. 백엔드 업데이트가 성공하면 Trident ONTAP 백엔드와 통신하고 향후 볼륨 작업을 처리할 수 있음을 나타냅니다.
Trident 에 대한 사용자 정의 ONTAP 역할 생성
Trident 에서 작업을 수행하기 위해 ONTAP 관리자 역할을 사용하지 않아도 되도록 최소한의 권한으로 ONTAP 클러스터 역할을 만들 수 있습니다. Trident 백엔드 구성에 사용자 이름을 포함하면 Trident 사용자가 만든 ONTAP 클러스터 역할을 사용하여 작업을 수행합니다.
참조하다"Trident 사용자 정의 역할 생성기" Trident 사용자 정의 역할 생성에 대한 자세한 내용은 다음을 참조하세요.
-
다음 명령을 사용하여 새 역할을 만듭니다.
security login role create <role_name\> -cmddirname "command" -access all –vserver <svm_name\> -
Trident 사용자에 대한 사용자 이름을 만듭니다.
security login create -username <user_name\> -application ontapi -authmethod <password\> -role <name_of_role_in_step_1\> –vserver <svm_name\> -comment "user_description" -
사용자에게 역할을 매핑합니다.
security login modify username <user_name\> –vserver <svm_name\> -role <role_name\> -application ontapi -application console -authmethod <password\>
ONTAP 시스템 관리자에서 다음 단계를 수행합니다.
-
사용자 정의 역할 만들기:
-
클러스터 수준에서 사용자 지정 역할을 만들려면 *클러스터 > 설정*을 선택합니다.
(또는) SVM 수준에서 사용자 지정 역할을 만들려면 저장소 > 저장소 VM >
required SVM> 설정 > 사용자 및 역할. -
사용자 및 역할 옆에 있는 화살표 아이콘(→)을 선택합니다.
-
*역할*에서 *+추가*를 선택합니다.
-
역할에 대한 규칙을 정의하고 *저장*을 클릭합니다.
-
-
* Trident 사용자에게 역할 매핑*: + 사용자 및 역할 페이지에서 다음 단계를 수행합니다.
-
사용자 아래에 있는 추가 아이콘 *+*을 선택합니다.
-
필요한 사용자 이름을 선택하고, 역할 드롭다운 메뉴에서 역할을 선택합니다.
-
*저장*을 클릭하세요.
-
자세한 내용은 다음 페이지를 참조하세요.
양방향 CHAP를 사용하여 연결 인증
Trident 양방향 CHAP를 사용하여 iSCSI 세션을 인증할 수 있습니다. ontap-san 그리고 ontap-san-economy 운전자. 이를 위해서는 다음을 활성화해야 합니다. useCHAP 백엔드 정의에 옵션을 추가하세요. 설정 시 true Trident SVM의 기본 이니시에이터 보안을 양방향 CHAP로 구성하고 백엔드 파일에서 사용자 이름과 비밀번호를 설정합니다. NetApp 양방향 CHAP를 사용하여 연결을 인증할 것을 권장합니다. 다음 샘플 구성을 참조하세요.
---
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
|
|
그만큼 useCHAP 매개변수는 한 번만 구성할 수 있는 부울 옵션입니다. 기본적으로 false로 설정됩니다. true로 설정한 후에는 false로 설정할 수 없습니다.
|
또한 useCHAP=true , 그 chapInitiatorSecret , chapTargetInitiatorSecret , chapTargetUsername , 그리고 chapUsername 필드는 백엔드 정의에 포함되어야 합니다. 백엔드가 생성된 후 다음을 실행하여 비밀을 변경할 수 있습니다. tridentctl update .
작동 원리
설정하여 useCHAP true로 설정하면 스토리지 관리자가 Trident 스토리지 백엔드에서 CHAP를 구성하도록 지시합니다. 여기에는 다음이 포함됩니다.
-
SVM에 CHAP 설정:
-
SVM의 기본 이니시에이터 보안 유형이 없음(기본적으로 설정됨)이고 볼륨에 이미 존재하는 LUN이 없는 경우 Trident 기본 보안 유형을 다음과 같이 설정합니다.
CHAPCHAP 이니시에이터와 대상 사용자 이름 및 비밀번호를 구성합니다. -
SVM에 LUN이 포함되어 있으면 Trident SVM에서 CHAP를 활성화하지 않습니다. 이렇게 하면 SVM에 이미 있는 LUN에 대한 액세스가 제한되지 않습니다.
-
-
CHAP 이니시에이터와 대상 사용자 이름 및 비밀번호를 구성합니다. 이러한 옵션은 백엔드 구성에서 지정해야 합니다(위에 표시된 대로).
백엔드가 생성된 후 Trident 해당 백엔드를 생성합니다. tridentbackend CRD를 사용하여 CHAP 비밀과 사용자 이름을 Kubernetes 비밀로 저장합니다. 이 백엔드에서 Trident 가 생성한 모든 PV는 CHAP를 통해 마운트되고 연결됩니다.
자격 증명을 순환하고 백엔드를 업데이트합니다.
CHAP 매개변수를 업데이트하여 CHAP 자격 증명을 업데이트할 수 있습니다. backend.json 파일. 이렇게 하려면 CHAP 비밀을 업데이트하고 다음을 사용해야 합니다. tridentctl update 이러한 변경 사항을 반영하기 위한 명령입니다.
|
|
백엔드의 CHAP 비밀을 업데이트할 때는 다음을 사용해야 합니다. tridentctl 백엔드를 업데이트합니다. Trident 이러한 변경 사항을 선택할 수 없으므로 ONTAP CLI 또는 ONTAP 시스템 관리자를 사용하여 스토리지 클러스터의 자격 증명을 업데이트하지 마십시오.
|
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 |
+----------------+----------------+--------------------------------------+--------+---------+
기존 연결은 영향을 받지 않으며, SVM에서 Trident 가 자격 증명을 업데이트하면 계속 활성 상태를 유지합니다. 새로운 연결은 업데이트된 자격 증명을 사용하고 기존 연결은 계속 활성 상태를 유지합니다. 이전 PV의 연결을 끊었다가 다시 연결하면 업데이트된 자격 증명을 사용하게 됩니다.