TLS를 통한 NFS 구성
변경 제안
PDF
TLS를 통한 NFS는 vserver nfs tls interface 명령 제품군, /api/protocols/nfs/tls/interfaces REST 엔드포인트 또는 System Manager의 NFS 설정을 사용하여 LIF별로 구성됩니다.
엑스포트 정책 규칙에 일치하는 클라이언트에 대해 TLS 전용 액세스를 강제할 수 있는 보조 필드가 추가되었습니다. 명령 참조는 "docs.netapp.com"을 참조하세요. 내장된 Swagger 문서를 통해 REST API를 대화형으로 탐색할 수 있습니다. 브라우저에서 `https://<cluster-mgmt-ip>/api/docs`로 이동하기만 하면 됩니다.
ONTAP 사전 요구 사항
아래에 설명된 절차는 다음 전제 조건이 충족되었다고 가정합니다.
-
ONTAP 9.19.1 이상
-
NFS 프로토콜이 활성화된 SVM
-
기본 NFS 액세스를 위해 하나 이상의 데이터 LIF가 구성되어 있어야 합니다.
1단계: ONTAP에서 루트 CA 생성
|
외부 CA 옵션. 조직에서 외부 CA를 사용하는 경우 이 단계를 건너뛰십시오. 2단계와 5단계에서 생성된 CSR을 외부 CA에 제출하고, 생성된 서명된 인증서를 ONTAP에 설치합니다. 나머지 절차는 동일합니다. |
ONTAP는 연구실 및 내부 배포 환경에서 내부 인증 기관(CA) 역할을 수행할 수 있습니다. 이 단계에서는 서버 인증서(및 선택적으로 상호 TLS를 위한 클라이언트 인증서)에 서명하는 데 사용될 자체 서명 루트 CA를 SVM에 생성합니다.
ontap9::> security certificate create -vserver <svm> -common-name <ca-name> -type root-ca -size 2048 -hash-function SHA256 -expire-days 3652 -country US -state <state> -locality <city> -organization <org> -unit <unit>
명령 실행이 완료되면 CA 일련 번호를 검색하여 기록하십시오. 이 번호는 2단계와 (상호 TLS를 사용하는 경우) 5단계에서 필요합니다.
ontap9::> security certificate show -vserver <svm> -common-name <ca-name> -type root-ca -fields serial
일련번호를 기록해 두세요. 이 번호는 이후 단계에서 <ca-serial> 사용됩니다.
2단계: 데이터 LIF용 서버 인증서 생성
ONTAP는 TLS 핸드셰이크 중에 이 인증서를 NFS 클라이언트에 제공합니다. 클라이언트의 tlshd가 서버 ID를 LIF의 FQDN 및 IP 주소 모두에 대해 검증하므로, 인증서의 일반 이름(CN)과 주체 대체 이름(SAN)은 LIF의 FQDN 및 IP 주소와 일치해야 합니다.
|
IP SAN 요구 사항. NFSv4.1 세션 트렁킹을 TLS를 통한 NFS로 구성하거나 마운트 명령에서 호스트 이름 대신 원시 IP 주소를 사용하는 경우, 클라이언트가 연결할 모든 LIF IP에 대한 IP SAN 항목이 인증서에 포함되어야 합니다. 이 항목이 없으면 IP 주소 경로에 대해 "인증서 소유자를 알 수 없음" 오류와 함께 TLS 핸드셰이크가 실패합니다. |
ONTAP CSR 생성기(security certificate generate-csr)는 쉼표로 구분된 IP 주소 목록을 허용하는 `-ipaddr`를 통해 IP SAN을 직접 지원합니다.
2a. CSR 및 개인 키를 생성합니다.
NFS over TLS 트래픽을 전송할 모든 LIF IP의 쉼표로 구분된 목록과 함께 `-ipaddr`을 포함하십시오. 마운트 명령에 사용되는 호스트 이름에 대해 `-dns-name`을 포함하십시오.
ontap9::> security certificate generate-csr -common-name <lif-fqdn> -security-strength 128 -hash-function SHA256 -extended-key-usage serverAuth -dns-name <lif-fqdn> -ipaddr <lif-ip>[,<lif-ip-2>,...] -country US -state <state> -locality <city> -organization <org> -unit <unit>
예를 들어, 단일 LIF의 경우:
ontap9::> security certificate generate-csr -common-name nfs.example.com -security-strength 128 -hash-function SHA256 -extended-key-usage serverAuth -dns-name nfs.example.com -ipaddr 192.0.2.130 -country US -state CA -locality SanJose -organization "MyOrg" -unit "Storage"
두 개의 LIF IP 주소 간 세션 트렁킹을 위해 두 IP 주소를 쉼표로 구분된 목록으로 입력하십시오.
ontap9::> security certificate generate-csr -common-name nfs.example.com -security-strength 128 -hash-function SHA256 -extended-key-usage serverAuth -dns-name nfs.example.com -ipaddr 192.0.2.130,192.0.2.131 -country US -state CA -locality SanJose -organization "MyOrg" -unit "Storage"
이 명령은 인증서 서명 요청(CSR) PEM 블록과 개인 키 PEM 블록을 출력합니다. 두 블록 모두 복사하여 저장하십시오. 개인 키는 한 번만 표시됩니다.
서명하기 전에 CSR에 예상되는 SAN이 포함되어 있는지 확인하려면 OpenSSL이 설치된 클라이언트에서 다음 명령을 실행하십시오.
echo <paste CSR PEM> | openssl req -noout -text | grep -A3 "Subject Alternative"
예상 출력:
X509v3 Subject Alternative Name: critical
DNS:nfs.example.com, IP Address:192.0.2.130
2b. ONTAP CA로 CSR에 서명합니다.
ontap9::> security certificate sign -vserver <svm> -ca <ca-name> -ca-serial <ca-serial> -expire-days 365 -hash-function SHA256
요청이 나오면 CSR PEM 블록을 붙여넣으십시오. 출력에서 서명된 인증서 PEM을 복사하십시오.
2c. 서명된 서버 인증서를 설치합니다.
ontap9::> security certificate install -vserver <svm> -type server -cert-name <cert-name>
요청 시:
-
서명된 인증서 PEM을 붙여넣으십시오.
-
개인 키 PEM을 붙여넣으십시오.
-
중간 인증서 또는 루트 인증서를 요청하는 메시지가 나타나면 CA 인증서 PEM을 붙여넣고 Enter 키를 누른 다음, 인증서 추가를 중지하려면 n을 입력하십시오.
2d. 설치된 인증서를 확인합니다.
ontap9::> security certificate show -vserver <svm> -type server -common-name <cert-name>
만료일과 해당 항목이 있는지 확인하십시오.
3단계: 데이터 LIF에서 TLS를 통한 NFS 활성화
서버 인증서가 설치되면 대상 LIF에서 TLS를 통한 NFS를 활성화하십시오.
ontap9::> vserver nfs tls interface enable -vserver <svm> -lif <lif> -certificate-name <cert-name>
LIF가 TLS를 지원하는지 확인하십시오.
ontap9::> vserver nfs tls interface show -vserver <svm>
예상 출력:
Vserver: <svm> Logical Interface: <lif> IP Address: <lif-ip> TLS Status: enabled TLS Certificate Name: <cert-name> Enforce Host Authentication: false
TLS Status: enabled`ONTAP이 이 LIF에 대해 포트 2049에서 TLS를 협상할 것임을 확인합니다. `xprtsec=tls 또는 `xprtsec=mtls`을 사용하는 클라이언트는 이제 TLS로 보호된 연결을 수신하게 됩니다. TLS를 요청하지 않는 클라이언트는 7단계에서 강제 적용이 추가되지 않는 한 평문으로 연결됩니다.
4단계: Linux 클라이언트에 CA 인증서 설치
Linux 클라이언트는 ONTAP 서버 인증서에 서명한 CA를 신뢰해야 합니다. 그렇지 않으면 `tlshd`서버 인증서를 신뢰할 수 없기 때문에 TLS 핸드셰이크를 거부합니다.
ONTAP CA를 사용한 경우(1단계)
ONTAP에서 CA 인증서를 내보냅니다.
ontap9::> security certificate show -vserver <svm> -common-name <ca-name> -type root-ca -fields cert
출력에서 인증서 PEM을 복사하여 파일(예: nfs-ca.crt)에 저장합니다. 이 파일을 Linux 클라이언트로 전송합니다.
외부 CA를 사용한 경우
외부 CA 인프라에서 CA 인증서 PEM 파일을 가져와 파일(예: nfs-ca.crt)로 저장합니다. 이 파일을 Linux 클라이언트로 전송합니다.
CA 인증서를 시스템 트러스트 저장소에 설치합니다
sudo cp nfs-ca.crt /etc/pki/ca-trust/source/anchors/nfs-tls-ca.crt sudo update-ca-trust
sudo cp nfs-ca.crt /usr/local/share/ca-certificates/nfs-tls-ca.crt sudo update-ca-certificates
tlshd가 이 CA를 신뢰 저장소로 사용하도록 구성하십시오.
편집 /etc/tlshd.conf:
[debug] loglevel=1 tls=1 nl=0 [authenticate] [authenticate.client] x509.truststore=/etc/pki/ca-trust/source/anchors/nfs-tls-ca.crt
CA 인증서를 배치한 위치와 일치하도록 x509.truststore 경로를 조정하십시오.
구성을 적용하려면 tlshd를 다시 시작하십시오.
sudo systemctl restart tlshd
tlshd가 정상적으로 시작되었는지 확인하십시오:
journalctl -u tlshd -n 20 --no-pager
출력 결과에 오류 줄이 없어야 합니다.
5단계: 클라이언트에서 LIF FQDN 확인
`tlshd`마운트 명령에 사용된 호스트 이름과 서버 인증서의 유효성을 검사합니다. 마운트하기 전에 클라이언트에서 `<lif-fqdn>`이(가) `<lif-ip>`로 확인되는지 확인하십시오.
getent hosts <lif-fqdn>
호스트 이름이 DNS를 통해 확인되지 않으면 고정 항목을 추가하십시오.
echo <lif-ip> <lif-fqdn> | sudo tee -a /etc/hosts
6단계: TLS를 통한 NFS로 마운트
커널 TLS 모듈이 로드되지 않은 경우 로드합니다.
sudo modprobe tls
마운트 지점을 생성하고 마운트합니다.
sudo mkdir -p <mountpoint> sudo mount -t nfs \ -o vers=4.1,xprtsec=tls \ <lif-fqdn>:<export-path> <mountpoint>
7단계: TLS 연결 확인
클라이언트 측
마운트가 활성화되어 있고 다음 내용이 표시되는지 확인하십시오. xprtsec=tls
mount | grep nfs
예상 출력(마운트 정보가 포함된 줄):
<lif-fqdn>:<export-path> on <mountpoint> type nfs4 (rw,...,xprtsec=tls,...)
성공적인 TLS 핸드셰이크가 완료되었는지 tlshd 확인합니다:
journalctl -u tlshd -n 10 --no-pager
다음 내용이 포함된 줄을 찾으세요:
Handshake with '<lif-fqdn>' (...) was successful
ONTAP 측
연결이 `TLS/nfs`로 표시되는지 확인하십시오(연결이 방금 설정된 경우 먼저 소량의 I/O를 생성하십시오).
ontap9::> network connections active show -vserver <svm>
예상 입력값:
<lif>:2049 <client-fqdn>:<port> TLS/nfs
TLS 핸드셰이크 오류가 발생하지 않았는지 확인하십시오.
ontap9::> event log show -severity error -message-name Nblade.TLSHandshakeFailed
마운트 시도 이후 새로운 항목이 없다는 것은 핸드셰이크가 성공했음을 의미합니다.
선택 사항: 특정 클라이언트에 대해 TLS를 필수로 설정(엑스포트 정책 시행)
기본적으로 NFS over TLS는 선택 사항입니다. TLS를 요청하지 않는 클라이언트는 TLS가 활성화된 LIF에서 평문으로 연결할 수 있습니다. 특정 엑스포트 규칙에 TLS를 적용하려면 `-allow-nfs-tls-only true`을 설정하십시오.
ontap9::> vserver export-policy rule modify -vserver <svm> -policyname <policy-name> -ruleindex <rule-index> -allow-nfs-tls-only true
이 설정을 적용하면 해당 규칙과 일치하는 NFS 클라이언트 중 TLS를 사용하지 않는 클라이언트는 엑스포트 규칙 평가 시점에서 거부됩니다. 기존 TLS 연결에는 영향을 미치지 않습니다.
확인:
ontap9::> vserver export-policy rule show -vserver <svm> -policyname <policy-name> -fields allow-nfs-tls-only
선택 사항: 상호 TLS(클라이언트 인증)
표준 NFS over TLS는 서버를 클라이언트에 인증합니다(서버 전용 TLS). 상호 TLS (`xprtsec=mtls`는 클라이언트가 ONTAP이 검증할 인증서를 추가로 제시해야 합니다. 이를 통해 양측에서 암호화 기반 호스트 인증이 제공됩니다.
|
|
클라이언트 OS 요구 사항. 상호 TLS를 사용하려면 ktls-utils 0.12 이상이 필요합니다. RHEL 9.7에 포함된 버전((ktls-utils 0.11)은 작동하지 않습니다. 구성에 관계없이 클라이언트 인증서를 전송하지 않습니다. RHEL 10.1((ktls-utils 1.2.1)은 검증되었습니다. 진행하기 전에 ktls-utils 버전을 확인하십시오.
|
|
|
마운트 옵션. `xprtsec=mtls`를 사용하고, `xprtsec=tls`는 사용하지 마세요. `xprtsec=tls`를 사용하면 커널이 인증 모드 `HANDSHAKE_AUTH_UNAUTH`를 `tlshd`에 전송하며, 이는 익명 핸드셰이크 경로를 따르고 클라이언트 인증서가 구성되어 있더라도 인증서를 제시하지 않습니다. |
1단계: 클라이언트 인증서용 CA 생성(ONTAP)
이 CA는 1단계에서 사용한 CA와 동일하거나 별도의 CA일 수 있습니다. 서버와 클라이언트의 인증서 체인을 분리하기 위해 프로덕션 환경에서는 별도의 CA를 사용하는 것이 좋습니다.
ontap9::> security certificate create -vserver <svm> -common-name "NFS-mTLS-CA" -type root-ca -expire-days 3652 -hash-function SHA256
일련번호를 `<mtls-ca-serial>`로 기록하십시오.
2단계: CA를 클라이언트 CA 트러스트 앵커(ONTAP)로 설치합니다.
CA 인증서를 내보냅니다.
ontap9::> security certificate show -vserver <svm> -common-name "NFS-mTLS-CA" -type root-ca -fields cert
다음과 같은 유형으로 설치하세요 client-ca:
ontap9::> security certificate install -vserver <svm> -type client-ca
요청 시 CA 인증서 PEM을 붙여넣습니다. 확인:
ontap9::> security certificate show -vserver <svm> -type client-ca
3단계: LIF(ONTAP)에서 enforce-host-auth를 활성화합니다.
ontap9::> vserver nfs tls interface modify -vserver <svm> -lif <lif> -enforce-host-auth true
확인:
ontap9::> vserver nfs tls interface show -vserver <svm> -instance
확인: Enforce Host Authentication: true.
4단계: 클라이언트 키 및 CSR 생성 (Linux 클라이언트)
sudo mkdir -p /etc/nfs sudo openssl genrsa -out /etc/nfs/client.key 2048 sudo chmod 600 /etc/nfs/client.key sudo openssl req -new \ -key /etc/nfs/client.key \ -subj "/CN=<client-fqdn>/C=US" \ -addext "subjectAltName=DNS:<client-fqdn>,IP:<client-ip>" \ -out /tmp/client.csr cat /tmp/client.csr
5단계: ONTAP CA로 클라이언트 CSR에 서명합니다.
ONTAP 클러스터에서:
ontap9::> security certificate sign -vserver <svm> -ca "NFS-mTLS-CA" -ca-serial <mtls-ca-serial> -expire-days 365 -hash-function SHA256
프롬프트가 나타나면 `/tmp/client.csr`의 내용을 붙여넣으세요. 출력에서 서명된 인증서 PEM을 복사하세요.
6단계: 클라이언트 인증서 체인 파일 생성 (Linux 클라이언트)
서명된 인증서를 /tmp/client-signed.crt`에 저장하십시오. 또한 CA 인증서 PEM (`nfs-mtls-ca.crt)을 얻으십시오. 이들을 연결하여 체인 파일을 생성하십시오.
sudo bash -c "cat /tmp/client-signed.crt /path/to/nfs-mtls-ca.crt \ > /etc/nfs/client-chain.crt" sudo chmod 600 /etc/nfs/client-chain.crt
|
|
체인 파일이 필요한 이유는 무엇인가요? tlshd 1.2.1 버전은 gnutls_pcert_list_import_x509_raw GnuTLS가 find_x509_client_cert 콜백 중에 발급자를 올바르게 확인하기 위해 전체 인증서 체인(리프 인증서 다음에 CA가 오는 형식)을 사용하고 필요로 합니다. 리프 인증서만 포함된 파일을 사용하면 GnuTLS 어설션 오류가 발생합니다.
|
7단계: 클라이언트 인증서로 /etc/tlshd.conf 업데이트(Linux 클라이언트)
[debug] loglevel=1 tls=1 nl=0 [authenticate] [authenticate.client] x509.truststore=/etc/pki/ca-trust/source/anchors/nfs-tls-ca.crt x509.certificate=/etc/nfs/client-chain.crt x509.private_key=/etc/nfs/client.key
tlshd를 재시작합니다:
sudo systemctl restart tlshd
8단계: xprtsec=mtls로 마운트
sudo mount -t nfs \ -o vers=4.1,xprtsec=mtls \ <lif-fqdn>:<export-path> <mountpoint>
9단계: 상호 TLS 확인
클라이언트:
mount | grep nfs # Confirm: xprtsec=mtls in mount options journalctl -u tlshd -n 5 --no-pager # Confirm: "Handshake with '<lif-fqdn>' (...) was successful"
ONTAP:
ontap9::> network connections active show -vserver <svm> # Confirm: <lif>:2049 <client-fqdn>:<port> TLS/nfs ontap9::> event log show -severity error -message-name Nblade.TLSHandshakeFailed # No new entries = success
중요한 기본 설정
-
-enforce-host-auth = false--TLS를 통한 NFS는 기본적으로 호스트 기반 사용자 인증을 강제하지 않습니다. 이는 완화된 보안 정책입니다. 이 설정을true으로 지정하면 인증서 ID가 LIF의 호스트 ID와 일치하지 않는 TLS 연결을 거부합니다. -
-skip-san-validation = false--SAN 검사는 기본적으로 수행됩니다. 이 값을 `true`로 설정하면 인증서와 LIF ID 간의 바인딩이 완화됩니다. 이 매개변수는 쓰기 전용입니다. 이후 `show`또는 `GET`에 값을 표시하지 않으므로 관리자는 활성화 또는 수정 시점에 SAN 유효성 검사가 건너뛰어졌는지 여부를 사후에 확인할 수 없습니다. -
-allow-nfs-tls-only = false-- 내보내기 정책 규칙은 기본적으로 TLS를 요구하지 않습니다. LIF에서 TLS를 통한 NFS를 활성화한다고 해서 일반 텍스트 NFS 액세스가 자동으로 차단되는 것은 아닙니다. TLS만 사용하도록 엄격하게 설정하려면 규칙별로 선택적으로 활성화하고 해당 클라이언트에 서비스를 제공하는 모든 데이터 LIF에서 TLS가 먼저 활성화되어 있는지 확인해야 합니다. 그렇지 않으면 액세스가 거부됩니다.`vserver export-policy rule create` 및 `vserver export-policy rule modify` 명령에 새로운 필드인 `-allow-nfs-tls-only`이 추가되었으며, 이 필드는 일치하는 클라이언트를 NFS-over-TLS 연결로만 제한합니다.
REST 엔드포인트
내장된 Swagger 문서를 통해 REST API를 대화형으로 탐색할 수 있습니다. 브라우저에서 https://<cluster-mgmt-ip>/api/docs`로 이동하기만 하면 됩니다. NFS over TLS 엔드포인트는 LIF 구성의 경우 `/api/protocols/nfs/tls/interfaces 경로 아래에 있으며, 내보내기 정책 규칙 필드의 경우 /api/protocols/nfs/export-policies/{policy.id}/rules 아래에 있습니다.