Proxmox VE 매뉴얼 : 14. 사용자 관리

Proxmox VE 매뉴얼을 Google Translate로 기계번역하고, 살짝 교정했습니다.
https://pve.proxmox.com/pve-docs/pve-admin-guide.html
version 8.1.4, Wed Mar 6 18:21:39 CET 2024

Proxmox VE는 Linux PAM, 통합 Proxmox VE 인증 서버, LDAP, Microsoft Active Directory 및 OpenID Connect와 같은 여러 인증 소스를 지원합니다.

모든 개체(VM, 스토리지, 노드 등)에 대해 역할 기반 사용자 및 권한 관리를 사용하여 세분화된 액세스를 정의할 수 있습니다.

14.1. 사용자

Proxmox VE는 /etc/pve/user.cfg에 사용자 속성을 저장합니다. 비밀번호는 여기에 저장되지 않습니다. 대신 사용자는 아래 설명된 인증 영역과 연결됩니다. 따라서 사용자는 내부적으로 @ 형식의 사용자 이름과 영역으로 식별되는 경우가 많습니다.

이 파일의 각 사용자 항목에는 다음 정보가 포함됩니다.

• 이름
• 성
• 이메일 주소
• 그룹 멤버십
• 선택적 만료일
• 이 사용자에 대한 의견이나 메모
• 이 사용자의 활성화 또는 비활성화 여부
• 선택적 2단계 인증 키

주의: 사용자를 비활성화하거나 삭제하는 경우 또는 설정된 만료 날짜가 과거인 경우 해당 사용자는 새 세션에 로그인하거나 새 작업을 시작할 수 없습니다. 이 사용자가 이미 시작한 모든 작업(예: 터미널 세션)은 그러한 이벤트로 인해 자동으로 종료되지 않습니다.

14.1.1. 시스템 관리자

시스템의 root 사용자는 항상 Linux PAM 영역을 통해 로그인할 수 있으며 무제한 관리자입니다. 이 사용자는 삭제할 수 없지만 속성은 계속 변경할 수 있습니다. 시스템 메일은 이 사용자에게 할당된 이메일 주소로 전송됩니다.

14.2. 그룹

각 사용자는 여러 그룹의 구성원이 될 수 있습니다. 그룹은 액세스 권한을 구성하는 데 선호되는 방법입니다. 항상 개별 사용자 대신 그룹에 권한을 부여해야 합니다. 그렇게 하면 훨씬 더 유지 관리하기 쉬운 액세스 제어 목록을 얻을 수 있습니다.

14.3. API 토큰

API 토큰을 사용하면 다른 시스템, 소프트웨어 또는 API 클라이언트에서 REST API의 대부분 부분에 대한 상태 비저장 액세스를 허용합니다. 토큰은 개별 사용자를 위해 생성될 수 있으며 별도의 권한과 만료 날짜를 부여하여 액세스 범위와 기간을 제한할 수 있습니다. API 토큰이 손상되면 사용자 자체를 비활성화하지 않고도 취소할 수 있습니다.

API 토큰은 두 가지 기본 유형으로 제공됩니다.

• 분리된 권한: 토큰에는 ACL을 통해 명시적인 액세스 권한을 부여해야 합니다. 유효 권한은 사용자 권한과 토큰 권한을 교차하여 계산됩니다.
• 전체 권한: 토큰의 권한은 연결된 사용자의 권한과 동일합니다.

주의: 토큰 값은 토큰 생성 시 한 번만 표시/반환됩니다. 나중에 API를 통해 다시 검색할 수 없습니다!

API 토큰을 사용하려면 API 요청 시 HTTP 헤더 인증을 PVEAPIToken=USER@REALM!TOKENID=UUID 형식의 표시된 값으로 설정하거나 API 클라이언트 설명서를 참조하세요.

14.4. 리소스 풀

리소스 풀은 가상 머신, 컨테이너, 스토리지 디바이스의 집합입니다. 이는 특정 사용자가 특정 리소스 집합에 대한 액세스를 제어해야 하는 경우 권한 처리에 유용합니다. 이를 통해 리소스별로 관리할 필요 없이 요소 집합에 단일 권한을 적용할 수 있기 때문입니다. 리소스 풀은 종종 그룹과 함께 사용되므로 그룹 구성원은 일련의 컴퓨터 및 저장소에 대한 권한을 갖습니다.

14.5. 인증 영역

Proxmox VE 사용자는 일부 외부 영역(realm)에 존재하는 사용자의 대응물일 뿐이므로 해당 영역은 /etc/pve/domains.cfg에서 구성되어야 합니다. 다음 영역(인증 방법)을 사용할 수 있습니다.

Linux PAM 표준 인증

Linux PAM은 시스템 전체 사용자 인증을 위한 프레임워크입니다. 이러한 사용자는 adduser와 같은 명령을 사용하여 호스트 시스템에 생성됩니다. Proxmox VE 호스트 시스템에 PAM 사용자가 있는 경우 해당 항목을 Proxmox VE에 추가하여 해당 사용자가 시스템 사용자 이름과 비밀번호를 통해 로그인할 수 있도록 할 수 있습니다.

Proxmox VE 인증 서버

이것은 해시된 비밀번호를 /etc/pve/priv/shadow.cfg에 저장하는 Unix와 유사한 비밀번호 저장소입니다. 비밀번호는 SHA-256 해싱 알고리즘을 사용하여 해시됩니다. 이는 사용자가 Proxmox VE 외부에 액세스할 필요가 없는 소규모(또는 중간 규모) 설치에 가장 편리한 영역입니다. 이 경우 사용자는 Proxmox VE에 의해 완전히 관리되며 GUI를 통해 자신의 비밀번호를 변경할 수 있습니다.

LDAP

LDAP(Lightweight Directory Access Protocol)는 디렉토리 서비스를 사용하여 인증하기 위한 개방형 교차 플랫폼 프로토콜입니다. OpenLDAP는 LDAP 프로토콜의 널리 사용되는 오픈 소스 구현입니다.

Microsoft Active Directory(AD)

Microsoft AD(Active Directory)는 Windows 도메인 네트워크용 디렉터리 서비스이며 Proxmox VE에 대한 인증 영역으로 지원됩니다. 인증 프로토콜로 LDAP를 지원합니다.

OpenID Connect

OpenID Connect는 OATH 2.0 프로토콜 위에 ID 계층으로 구현됩니다. 이를 통해 클라이언트는 외부 인증 서버에서 수행되는 인증을 기반으로 사용자의 신원을 확인할 수 있습니다.

14.5.1. Linux PAM 표준 인증

Linux PAM은 호스트 시스템 사용자에 해당하므로 사용자가 로그인할 수 있는 각 노드에는 시스템 사용자가 있어야 합니다. 사용자는 일반적인 시스템 비밀번호로 인증합니다. 이 영역은 기본적으로 추가되며 제거할 수 없습니다. 구성 가능성 측면에서 관리자는 영역의 로그인에 2단계 인증을 요구하고 해당 영역을 기본 인증 영역으로 설정하도록 선택할 수 있습니다.

14.5.2. Proxmox VE 인증 서버

Proxmox VE 인증 서버 영역은 Unix와 유사한 간단한 비밀번호 저장소입니다. 영역은 기본적으로 생성되며 Linux PAM과 마찬가지로 사용 가능한 유일한 구성 항목은 영역 사용자에게 2단계 인증을 요구하고 로그인을 위한 기본 영역으로 설정하는 기능입니다.

다른 Proxmox VE 영역 유형과 달리 사용자는 다른 시스템에 대해 인증하는 대신 Proxmox VE를 통해 완전히 생성되고 인증됩니다. 따라서 생성 시 이러한 유형의 사용자에 대한 비밀번호를 설정해야 합니다.

14.5.3. LDAP

사용자 인증을 위해 외부 LDAP 서버(예: OpenLDAP)를 사용할 수도 있습니다. 이 영역 유형에서는 User Attribute Name(user_attr) 필드에 지정된 사용자 이름 속성을 사용하여 Base Domain Name(base_dn)에서 사용자를 검색합니다.

서버 및 선택적 대체 서버를 구성할 수 있으며 SSL을 통해 연결을 암호화할 수 있습니다. 또한 디렉터리 및 그룹에 대해 필터를 구성할 수 있습니다. 필터를 사용하면 영역 범위를 더 제한할 수 있습니다.

예를 들어 사용자가 다음 LDIF 데이터 세트를 통해 표현되는 경우:

# user1 of People at ldap-test.com
dn: uid=user1,ou=People,dc=ldap-test,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: user1
cn: Test User 1
sn: Testers
description: This is the first test user.

Base Domain Name은 ou=People,dc=ldap-test,dc=com이고 사용자 속성은 uid입니다.

Proxmox VE가 사용자를 쿼리하고 인증하기 전에 LDAP 서버에 인증(바인딩)해야 하는 경우 /etc/pve/domains.cfg의 bind_dn 속성을 통해 바인딩 도메인 이름을 구성할 수 있습니다. 그런 다음 해당 암호를 /etc/pve/priv/ldap/.pw(예: /etc/pve/priv/ldap/my-ldap.pw)에 저장해야 합니다. 이 파일에는 원시 비밀번호가 포함된 한 줄이 포함되어야 합니다.

인증서를 확인하려면 capath를 설정해야 합니다. 이를 LDAP 서버의 CA 인증서로 직접 설정하거나 신뢰할 수 있는 모든 CA 인증서(/etc/ssl/certs)가 포함된 시스템 경로로 설정할 수 있습니다. 또한 웹 인터페이스를 통해서도 수행할 수 있는 verify 옵션을 설정해야 합니다.

LDAP 서버 영역의 기본 구성 옵션은 다음과 같습니다.

• Realm(realm): Proxmox VE 사용자를 위한 영역 식별자입니다.
• Base Domain Name(base_dn): 사용자가 검색되는 디렉터리
• User Attribute Name(user_attr): 사용자가 로그인하는 데 사용할 사용자 이름이 포함된 LDAP 속성
• Server(server1): LDAP 디렉터리를 호스팅하는 서버
• Fallback Server(server2): 기본 서버에 연결할 수 없는 경우 선택적 대체 서버 주소
• Port(port): LDAP 서버가 청취하는 포트

참고: 특정 사용자가 LDAP 서버를 사용하여 인증할 수 있도록 하려면 해당 사용자를 Proxmox VE 서버에서 해당 영역의 사용자로 추가해야 합니다. 이는 동기화를 통해 자동으로 수행될 수 있습니다.

14.5.4. Microsoft Active Directory(AD)

Microsoft AD를 영역으로 설정하려면 서버 주소와 인증 도메인을 지정해야 합니다. Active Directory는 선택적 대체 서버, 포트, SSL 암호화 등 LDAP와 동일한 속성을 대부분 지원합니다. 또한 구성 후 동기화 작업을 통해 사용자를 Proxmox VE에 자동으로 추가할 수 있습니다.

LDAP와 마찬가지로 Proxmox VE가 AD 서버에 바인딩하기 전에 인증해야 하는 경우 바인딩 사용자(bind_dn) 속성을 구성해야 합니다. 이 속성은 일반적으로 Microsoft AD에 기본적으로 필요합니다.

Microsoft Active Directory의 기본 구성 설정은 다음과 같습니다.

• Realm(reakn): Proxmox VE 사용자를 위한 영역 식별자입니다.
• Domain(domain) : 서버의 AD 도메인
• Server(server1): 서버의 FQDN 또는 IP 주소
• Fallback Server(server2): 기본 서버에 연결할 수 없는 경우 선택적 대체 서버 주소
• Port(port): Microsoft AD 서버가 수신 대기하는 포트

참고: Microsoft AD는 일반적으로 대소문자를 구분하지 않고 사용자 이름과 같은 값을 확인합니다. Proxmox VE가 동일한 작업을 수행하도록 하려면 웹 UI에서 영역을 편집하거나 CLI(영역 ID로 ID 변경)를 사용하여 기본 case-sensitive 옵션을 비활성화할 수 있습니다. pveum realm modify ID –case-sensitive 0

14.5.5. LDAP 기반 영역 동기화

Proxmox VE에 수동으로 추가할 필요 없이 LDAP 기반 영역(LDAP 및 Microsoft Active Directory)에 대한 사용자 및 그룹을 자동으로 동기화할 수 있습니다. 웹 인터페이스 Authentication 패널의 추가/편집 창에서 또는  pveum realm add/modify 명령을 통해 동기화 옵션에 액세스할 수 있습니다. 그런 다음 GUI의 인증 패널에서 또는 다음 명령을 사용하여 동기화 작업을 수행할 수 있습니다.

pveum realm sync <realm>

사용자 및 그룹은 클러스터 전체 구성 파일 /etc/pve/user.cfg에 동기화됩니다.

속성에 대한 속성

동기화 응답에 사용자 속성이 포함된 경우 user.cfg의 일치하는 사용자 속성으로 동기화됩니다. 예: firstname 또는 lastname.

속성 이름이 Proxmox VE 속성과 일치하지 않는 경우 sync_attributes 옵션을 사용하여 구성에서 사용자 정의 필드-필드 맵을 설정할 수 있습니다.

아무것도 사라진 경우 이러한 속성을 처리하는 방법은 동기화 옵션을 통해 제어할 수 있습니다. 아래를 참조하세요.

동기화 구성

LDAP 기반 영역 동기화를 위한 구성 옵션은 추가/편집 창의 동기화 옵션 탭에서 찾을 수 있습니다.

구성 옵션은 다음과 같습니다.

• Bind User (bind_dn): 사용자 및 그룹을 쿼리하는 데 사용되는 LDAP 계정을 의미합니다. 이 계정은 원하는 모든 항목에 액세스해야 합니다. 설정되면 바인딩을 통해 검색이 수행됩니다. 그렇지 않은 경우 검색은 익명으로 수행됩니다. 사용자는 완전한 LDAP 형식의 고유 이름(DN)이어야 합니다(예: cn=admin,dc=example,dc=com).
• Groupname attr. (group_name_attr): 사용자의 그룹을 나타냅니다. user.cfg의 일반적인 문자 제한을 준수하는 항목만 동기화됩니다. 이름 충돌을 피하기 위해 그룹은 이름에 -$realm을 첨부하여 동기화됩니다. 동기화가 수동으로 생성된 그룹을 덮어쓰지 않는지 확인하세요.
• User classes (user_classes): 사용자와 연관된 객체 클래스입니다.
• Group classes (group_classes): 그룹과 연관된 객체 클래스입니다.
• E-Mail attribute: LDAP 기반 서버가 사용자 이메일 주소를 지정하는 경우 여기에서 관련 속성을 설정하여 해당 주소를 동기화에 포함할 수도 있습니다. 명령줄에서는 –sync_attributes 매개변수를 통해 이를 달성할 수 있습니다.
• User Filter (filter): 특정 사용자를 대상으로 하는 추가 필터 옵션입니다.
• Group Filter (group_filter): 특정 그룹을 대상으로 하는 추가 필터 옵션입니다.

참고: 필터를 사용하면 추가 일치 기준 세트를 생성하여 동기화 범위를 좁힐 수 있습니다. 사용 가능한 LDAP 필터 유형 및 사용법에 대한 정보는 ldap.com에서 확인할 수 있습니다.

동기화 옵션

이전 섹션에서 지정한 옵션 외에도 동기화 작업 동작을 설명하는 추가 옵션을 구성할 수도 있습니다.

이러한 옵션은 동기화 전에 매개변수로 설정되거나 영역 옵션 sync-defaults-options를 통해 기본값으로 설정됩니다.

동기화의 주요 옵션은 다음과 같습니다.

• Scope(scope): 동기화할 대상의 범위입니다. users, groups 또는 both일 수 있습니다.
• Enable new(enable-new): 설정된 경우 새로 동기화된 사용자가 활성화되고 로그인할 수 있습니다. 기본값은 true입니다.
• Remove Vanished(remove-vanished): 활성화되면 동기화 응답에서 반환되지 않을 때 제거되는지 여부를 결정하는 옵션 목록입니다. 옵션은 다음과 같습니다:
  • ACL(acl): 동기화 응답에서 반환되지 않은 사용자 및 그룹의 ACL을 제거합니다. 이것은 Entry와 함께 가장 자주 의미가 있습니다.
  • Entry(entry): 동기화 응답에 반환되지 않는 항목(예: 사용자 및 그룹)을 제거합니다.
  • Properties(properties): 동기화 응답의 사용자가 해당 속성을 포함하지 않은 항목의 속성을 제거합니다. 여기에는 동기화로 설정되지 않은 속성을 포함한 모든 속성이 포함됩니다. 토큰과 활성화 플래그는 예외이며 이 옵션이 활성화된 경우에도 유지됩니다.
  • Preview(dry-run): 구성에 데이터가 기록되지 않습니다. 이는 user.cfg에 동기화되는 사용자 및 그룹을 확인하려는 경우에 유용합니다.

예약된 문자

특정 문자는 예약되어 있으며(RFC2253 참조) 적절하게 이스케이프하지 않으면 DN의 속성 값에 쉽게 사용할 수 없습니다.

다음 문자는 이스케이프해야 합니다.

• 시작 또는 끝 부분에 공백( )
• 시작 부분의 숫자 기호(#)
• 반점 (,)
• 더하기 기호(+)
• 큰따옴표(“)
• 슬래시(/)
• 꺾쇠괄호(<>)
• 세미콜론(;)
• 등호(=)

DN에서 이러한 문자를 사용하려면 속성 값을 큰따옴표로 묶으십시오. 예를 들어 CN(Common Name) Example, Userr를 사용하여 사용자와 바인딩하려면 CN=”Example, User”,OU=people,DC=example,DC=com을 바인딩_dn 값으로 사용합니다.

이는 base_dn, bin_dn 및 group_dn 속성에 적용됩니다.

참고: 콜론과 슬래시가 있는 사용자는 사용자 이름에 예약된 문자이므로 동기화할 수 없습니다.

14.5.6. OpenID 연결 Connect

기본 OpenID Connect 구성 옵션은 다음과 같습니다.

• Issuer URL (issuer-url): 인증 서버의 URL입니다. Proxmox는 OpenID Connect Discovery 프로토콜을 사용하여 추가 세부 정보를 자동으로 구성합니다. 암호화되지 않은 http:// URL을 사용할 수 있지만 암호화된 https:// 연결을 사용하는 것이 좋습니다.
• Realm (realm): Proxmox VE 사용자를 위한 영역 식별자입니다.
• Client ID (client-id): OpenID 클라이언트 ID입니다.
• Client Key (client-key): 선택적 OpenID 클라이언트 키입니다.
• Autocreate Users (autocreate): 사용자가 존재하지 않는 경우 자동으로 생성합니다. OpenID 서버에서 인증이 수행되는 동안 모든 사용자는 여전히 Proxmox VE 사용자 구성에 항목이 필요합니다. 수동으로 추가하거나 자동 생성 옵션을 사용하여 새 사용자를 자동으로 추가할 수 있습니다.
• Username Claim (username-claim): 고유한 사용자 이름(subject, username, email)을 생성하는 데 사용되는 OpenID 클레임입니다.

사용자 이름 매핑

OpenID Connect 사양은 주제라는 단일 고유 속성(OpenID 용어로 claim)을 정의합니다. 기본적으로 이 속성의 값을 사용하여 @ 및 영역 이름 ${subject}@${realm}을 추가하여 Proxmox VE 사용자 이름을 생성합니다.

불행히도 대부분의 OpenID 서버는 DGH76OKH34BNG3245SB와 같이 제목에 임의의 문자열을 사용하므로 일반적인 사용자 이름은 DGH76OKH34BNG3245SB@yourrealm과 같습니다. 고유하지만 인간이 이러한 임의의 문자열을 기억하기 어렵기 때문에 실제 사용자를 이와 연관시키는 것이 불가능합니다.

사용자 username-claim 설정을 사용하면 사용자 이름 매핑에 다른 속성을 사용할 수 있습니다. OpenID Connect 서버가 해당 속성을 제공하고 고유성을 보장하는 경우 이를 username으로 설정하는 것이 좋습니다.

또 다른 옵션은 사람이 읽을 수 있는 사용자 이름을 생성하는 email을 사용하는 것입니다. 다시 한번 말하지만, 서버가 이 속성의 고유성을 보장하는 경우에만 이 설정을 사용하십시오.

예

다음은 Google을 사용하여 OpenID 영역을 만드는 예입니다. –client-id 및 –client-key를 Google OpenID 설정의 값으로 바꿔야 합니다.

pveum realm add myrealm1 --type openid --issuer-url  https://accounts.google.com --client-id XXXX --client-key YYYY --username-claim email

위 명령은 –username-claim 이메일을 사용하므로 Proxmox VE 측의 사용자 이름은 example.user@google.com@myrealm1과 같습니다.

Keycloak(https://www.keycloak.org/)은 OpenID Connect를 지원하는 인기 있는 오픈 소스 ID 및 액세스 관리 도구입니다. 다음 예에서는 –issuer-url 및 –client-id를 사용자 정보로 바꿔야 합니다.

pveum realm add myrealm2 --type openid --issuer-url  https://your.server:8080/realms/your-realm --client-id XXX --username-claim username

–username-claim 사용자 이름을 사용하면 Proxmox VE 측에서 example.user@myrealm2와 같은 간단한 사용자 이름을 사용할 수 있습니다.

경고: 사용자가 Keycloak 서버에서 사용자 이름 설정을 직접 편집할 수 없도록 해야 합니다.

14.6. 2단계 인증

이중 인증을 사용하는 방법에는 두 가지가 있습니다.

TOTP(Time-based One-Time Password) 또는 YubiKey OTP를 통해 인증 영역에서 필요할 수 있습니다. 이 경우 두 번째 요소 없이는 로그인할 수 없으므로 새로 생성된 사용자는 즉시 키를 추가해야 합니다. TOTP의 경우 사용자가 먼저 로그인할 수 있다면 나중에 TOTP를 변경할 수도 있습니다.

또는 사용자는 영역에서 이를 시행하지 않더라도 나중에 2단계 인증을 선택하도록 선택할 수 있습니다.

14.6.1. 사용 가능한 두 번째 요소

스마트폰이나 보안 키를 분실하여 계정에 영구적으로 액세스할 수 없는 상황을 방지하기 위해 여러 개의 두 번째 요소를 설정할 수 있습니다.

영역 적용 TOTP 및 YubiKey OTP 외에도 다음과 같은 2단계 인증 방법을 사용할 수 있습니다.

• 사용자가 TOTP(시간 기반 일회용 비밀번호)를 구성했습니다. 공유 비밀과 현재 시간에서 파생된 짧은 코드로, 30초마다 변경됩니다.
• WebAuthn(웹 인증). 인증에 대한 일반적인 표준입니다. 이는 컴퓨터나 스마트폰의 하드웨어 키나 TPM(신뢰할 수 있는 플랫폼 모듈)과 같은 다양한 보안 장치로 구현됩니다.
• 일회용 복구 키. 인쇄하여 안전한 장소에 잠그거나 전자 금고에 디지털 방식으로 저장해야 하는 키 목록입니다. 각 키는 한 번만 사용할 수 있습니다. 이는 다른 두 번째 요소가 모두 손실되거나 손상된 경우에도 잠기지 않도록 하는 데 적합합니다.

WebAuthn이 지원되기 전에는 사용자가 U2F를 설정할 수 있었습니다. 기존 U2F 요소를 계속 사용할 수 있지만 서버에 WebAuthn이 구성된 후에는 WebAuthn으로 전환하는 것이 좋습니다.

14.6.2. 영역 강제 2단계 인증

인증 영역을 추가하거나 편집할 때 TFA 드롭다운 상자를 통해 사용 가능한 방법 중 하나를 선택하면 됩니다. 영역에 TFA가 활성화되면 이는 필수 사항이 되며 구성된 TFA가 있는 사용자만 로그인할 수 있습니다.

현재 다음 두 가지 방법을 사용할 수 있습니다.

Time-based OATH(TOTP)

이는 현재 시간이 사용자가 구성한 키로 해시되는 표준 HMAC-SHA1 알고리즘을 사용합니다. 시간 단계 및 비밀번호 길이 매개변수를 구성할 수 있습니다.

사용자는 여러 키를 공백으로 구분하여 구성할 수 있으며 키는 Base32(RFC3548) 또는 16진수 표기법으로 지정할 수 있습니다.

Proxmox VE는 Base32 표기법으로 임의의 키를 인쇄하는 키 생성 도구(oathkeygen)를 제공합니다. 이 도구는 oathtool 명령줄 도구나 Android Google Authenticator, FreeOTP 및 OTP 또는 이와 유사한 다양한 OTP 도구와 함께 직접 사용할 수 있습니다. 응용 프로그램.

YubiKey OTP

YubiKey를 통해 인증하려면 Yubico API ID, API KEY 및 유효성 검사 서버 URL을 구성해야 하며 사용자는 YubiKey를 사용할 수 있어야 합니다. YubiKey에서 키 ID를 얻으려면 USB를 통해 YubiKey를 연결한 후 YubiKey를 한 번 트리거하고 입력된 비밀번호의 처음 12자를 사용자의 키 ID 필드에 복사하면 됩니다.

YubiCloud를 사용하거나 자체 검증 서버를 호스팅하는 방법은 YubiKey OTP 문서를 참조하세요.

14.6.3. 2단계 인증의 제한 및 잠금

두 번째 요소는 비밀번호가 유출되거나 추측되는 경우 사용자를 보호하기 위한 것입니다. 그러나 일부 요소는 여전히 무차별 대입에 의해 깨질 수 있습니다. 이러한 이유로 2단계 로그인 시도가 너무 많이 실패하면 사용자가 잠깁니다.

TOTP의 경우 8회 실패하면 사용자의 TOTP 요소가 비활성화됩니다. 복구 키로 로그인하면 잠금이 해제됩니다. TOTP가 사용 가능한 유일한 요소인 경우 관리자 개입이 필요하며 사용자에게 즉시 비밀번호를 변경하도록 요구하는 것이 좋습니다.

FIDO2/Webauthn 및 복구 키는 무차별 대입 공격에 덜 취약하므로 한도는 더 높지만(100회 시도) 초과 시 한 시간 동안 두 번째 요소가 모두 차단됩니다.

관리자는 UI 또는 명령줄의 사용자 목록을 통해 언제든지 사용자의 2단계 인증을 잠금 해제할 수 있습니다.

 pveum user tfa unlock joe@pve

14.6.4. 사용자 구성 TOTP 인증

사용자는 사용자 목록의 TFA 버튼을 통해 로그인 시 두 번째 요소로 TOTP 또는 WebAuthn을 활성화하도록 선택할 수 있습니다(영역에서 YubiKey OTP를 시행하지 않는 한).

사용자는 언제든지 일회용 Recovery Keys를 추가하고 사용할 수 있습니다.

TFA 창을 열면 TOTP 인증을 설정하는 대화 상자가 사용자에게 표시됩니다. 비밀 필드에는 Randomize 버튼을 통해 무작위로 생성할 수 있는 키가 포함되어 있습니다. 키가 속한 항목에 대한 정보를 TOTP 앱에 제공하기 위해 선택적 발급자 이름을 추가할 수 있습니다. 대부분의 TOTP 앱에는 해당 OTP 값과 함께 발급자 이름이 표시됩니다. 사용자 이름은 TOTP 앱의 QR 코드에도 포함되어 있습니다.

키를 생성하면 QR 코드가 표시되며 FreeOTP 등 대부분의 OTP 앱에서 사용할 수 있습니다. 그런 다음 사용자는 확인 코드 필드에 현재 OTP 값을 입력하고 적용 버튼을 눌러 현재 사용자 비밀번호(루트로 로그인하지 않은 경우)와 TOTP 키를 올바르게 사용할 수 있는지 확인해야 합니다.

14.6.5. TOTP

서버 설정이 필요하지 않습니다. 스마트폰에 TOTP 앱(예: FreeOTP)을 설치하고 Proxmox Backup Server 웹 인터페이스를 사용하여 TOTP 요소를 추가하기만 하면 됩니다.

14.6.6. WebAuthn

WebAuthn이 작동하려면 다음 두 가지가 필요합니다.

• 신뢰할 수 있는 HTTPS 인증서(예: Let’s Encrypt 사용) 신뢰할 수 없는 인증서에서도 작동할 수 있지만 일부 브라우저는 신뢰할 수 없는 경우 WebAuthn 작업을 경고하거나 거부할 수 있습니다.
• WebAuthn 구성을 설정합니다(Proxmox VE 웹 인터페이스의 Datacenter → Option → WebAuthn Settings 참조). 이는 대부분의 설정에서 자동으로 채워질 수 있습니다.

이러한 요구 사항을 모두 충족한 후에는 Datacenter → Permissions → Two Factor 아래의 Two Factor 패널에서 WebAuthn 구성을 추가할 수 있습니다.

14.6.7. 복구 키

복구 키 코드는 준비할 필요가 없습니다. Datacenter → Permissions → Two Factor계 아래의 Two Factor 패널에서 복구 키 세트를 생성하면 됩니다.

참고: 언제든지 사용자당 하나의 일회용 복구 키 세트만 있을 수 있습니다.

14.6.8. 서버 측 Webauthn 구성

사용자가 WebAuthn 인증을 사용할 수 있도록 하려면 유효한 SSL 인증서가 있는 유효한 도메인을 사용해야 합니다. 그렇지 않으면 일부 브라우저에서 경고를 표시하거나 인증을 거부할 수 있습니다.

참고: WebAuthn 구성을 변경하면 기존의 모든 WebAuthn 등록을 사용할 수 없게 될 수 있습니다!

이는 /etc/pve/datacenter.cfg를 통해 수행됩니다. 예를 들어:

webauthn: rp=mypve.example.com,origin=https://mypve.example.com:8006,id=mypve.example.com

14.6.9. 서버측 U2F 구성

참고: 대신 WebAuthn을 사용하는 것이 좋습니다.

사용자가 U2F 인증을 사용할 수 있도록 하려면 유효한 SSL 인증서가 있는 유효한 도메인을 사용해야 할 수 있습니다. 그렇지 않으면 일부 브라우저에서는 경고를 인쇄하거나 U2F 사용을 완전히 거부할 수 있습니다. 처음에는 AppId [52]를 구성해야 합니다.

참고: AppId를 변경하면 기존의 모든 U2F 등록을 사용할 수 없게 됩니다!

이는 /etc/pve/datacenter.cfg를 통해 수행됩니다. 예를 들어:

u2f: appid=https://mypve.example.com:8006

단일 노드의 경우 AppId는 위에 표시된 것처럼 https:// 및 포트를 포함하여 브라우저에서 사용되는 것과 똑같은 웹 인터페이스의 주소일 수 있습니다. 일부 브라우저는 AppId 일치 시 다른 브라우저보다 더 엄격할 수 있습니다.

여러 노드를 사용하는 경우 appid.json [53] 파일을 제공하는 별도의 https 서버를 갖는 것이 가장 좋습니다. 대부분의 브라우저와 호환되는 것으로 보입니다. 모든 노드가 동일한 최상위 도메인의 하위 도메인을 사용하는 경우 TLD를 AppId로 사용하면 충분할 수 있습니다. 그러나 일부 브라우저에서는 이를 허용하지 않을 수도 있다는 점에 유의해야 합니다.

참고: 잘못된 AppId는 일반적으로 오류를 생성하지만, 특히 Chromium의 하위 도메인을 통해 액세스되는 노드에 대해 최상위 도메인 AppId를 사용할 때 오류가 발생하지 않는 상황이 발생했습니다. 이러한 이유로 나중에 AppId를 변경하면 기존 U2F 등록을 사용할 수 없게 되므로 여러 브라우저로 구성을 테스트하는 것이 좋습니다.

14.6.10. U2F를 사용자로 활성화하기

U2F 인증을 활성화하려면 TFA 창의 U2F 탭을 열고 현재 비밀번호를 입력한 후(루트로 로그인하지 않은 경우) 등록 버튼을 누릅니다. 서버가 올바르게 설정되고 브라우저가 서버가 제공한 AppId를 수락하면 사용자에게 U2F 장치의 버튼을 누르라는 메시지가 나타납니다. (YubiKey인 경우 버튼 표시등이 대략적으로 꾸준히 켜지고 꺼져야 합니다. 초당 두 번).

Firefox 사용자는 U2F 토큰을 사용하기 전에 about:config를 통해 security.webauth.u2f를 활성화해야 할 수도 있습니다.

14.7. 권한 관리

사용자가 작업(예: VM 구성의 일부 나열, 수정 또는 삭제)을 수행하려면 사용자에게 적절한 권한이 있어야 합니다.

Proxmox VE는 역할 및 경로 기반 권한 관리 시스템을 사용합니다. 권한 테이블의 항목을 사용하면 사용자, 그룹 또는 토큰이 개체나 경로에 액세스할 때 특정 역할을 맡을 수 있습니다. 이는 이러한 액세스 규칙이 허용된 작업 집합을 포함하는 역할과 함께 (경로, 사용자, 역할), (경로, 그룹, 역할) 또는 (경로, 토큰, 역할)의 세 가지로 표시될 수 있음을 의미합니다. 이러한 작업의 대상을 나타내는 경로입니다.

14.7.1. 역할

역할은 단순히 권한의 목록입니다. Proxmox VE에는 대부분의 요구 사항을 충족하는 사전 정의된 역할이 많이 있습니다.

• Administrator: has full privileges
• NoAccess: has no privileges (used to forbid access)
• PVEAdmin: can do most tasks, but has no rights to modify system settings (Sys.PowerMgmt, Sys.Modify, Realm.Allocate) or permissions (Permissions.Modify)
• PVEAuditor: has read only access
• PVEDatastoreAdmin: create and allocate backup space and templates
• PVEDatastoreUser: allocate backup space and view storage
• PVEMappingAdmin: manage resource mappings
• PVEMappingUser: view and use resource mappings
• PVEPoolAdmin: allocate pools
• PVEPoolUser: view pools
• PVESDNAdmin: manage SDN configuration
• PVESDNUser: access to bridges/vnets
• PVESysAdmin: audit, system console and system logs
• PVETemplateUser: view and clone templates
• PVEUserAdmin: manage users
• PVEVMAdmin: fully administer VMs
• PVEVMUser: view, backup, configure CD-ROM, VM console, VM power management

GUI에서 사전 정의된 역할의 전체 집합을 볼 수 있습니다.

GUI 또는 명령줄을 통해 새 역할을 추가할 수 있습니다.

GUI에서 Datacenter의  _Permissions → Roles 탭으로 이동하여 Create 버튼을 클릭합니다. 여기에서 역할 이름을 설정하고 권한 드롭다운 메뉴에서 원하는 Privileges 권한을 선택할 수 있습니다.

명령줄을 통해 역할을 추가하려면 pveum CLI 도구를 사용할 수 있습니다. 예를 들면 다음과 같습니다.

pveum role add VM_Power-only --privs "VM.PowerMgmt VM.Console"
pveum role add Sys_Power-only --privs "Sys.PowerMgmt Sys.Console"

참고: PVE로 시작하는 역할은 항상 기본 제공되며 사용자 지정 역할에서는 이 예약된 접두사를 사용할 수 없습니다.

14.7.2. 권한

특권은 특정 작업을 수행할 수 있는 권한입니다. 관리를 단순화하기 위해 권한 목록을 역할별로 그룹화한 다음 권한 테이블에서 사용할 수 있습니다. 역할에 속하지 않으면 권한을 사용자 및 경로에 직접 할당할 수 없습니다.

현재 다음과 같은 권한을 지원합니다.

노드/시스템 관련 권한

• Group.Allocate: create/modify/remove groups
• Mapping.Audit: view resource mappings
• Mapping.Modify: manage resource mappings
• Mapping.Use: use resource mappings
• Permissions.Modify: modify access permissions
• Pool.Allocate: create/modify/remove a pool
• Pool.Audit: view a pool
• Realm.AllocateUser: assign user to a realm
• Realm.Allocate: create/modify/remove authentication realms
• SDN.Allocate: manage SDN configuration
• SDN.Audit: view SDN configuration
• Sys.Audit: view node status/config, Corosync cluster config, and HA config
• Sys.Console: console access to node
• Sys.Incoming: allow incoming data streams from other clusters (experimental)
• Sys.Modify: create/modify/remove node network parameters
• Sys.PowerMgmt: node power management (start, stop, reset, shutdown, …)
• Sys.Syslog: view syslog
• User.Modify: create/modify/remove user access and details.

가상 머신 관련 권한

• SDN.Use: access SDN vnets and local network bridges
• VM.Allocate: create/remove VM on a server
• VM.Audit: view VM config
• VM.Backup: backup/restore VMs
• VM.Clone: clone/copy a VM
• VM.Config.CDROM: eject/change CD-ROM
• VM.Config.CPU: modify CPU settings
• VM.Config.Cloudinit: modify Cloud-init parameters
• VM.Config.Disk: add/modify/remove disks
• VM.Config.HWType: modify emulated hardware types
• VM.Config.Memory: modify memory settings
• VM.Config.Network: add/modify/remove network devices
• VM.Config.Options: modify any other VM configuration
• VM.Console: console access to VM
• VM.Migrate: migrate VM to alternate server on cluster
• VM.Monitor: access to VM monitor (kvm)
• VM.PowerMgmt: power management (start, stop, reset, shutdown, …)
• VM.Snapshot.Rollback: rollback VM to one of its snapshots
• VM.Snapshot: create/delete VM snapshots

스토리지 관련 권한

• Datastore.Allocate: create/modify/remove a datastore and delete volumes
• Datastore.AllocateSpace: allocate space on a datastore
• Datastore.AllocateTemplate: allocate/upload templates and ISO images
• Datastore.Audit: view/browse a datastore

경고: Permissions.Modify 및 Sys.Modify는 시스템의 위험하거나 민감한 구성 측면을 수정할 수 있으므로 주의해서 처리해야 합니다.

경고: 할당된 역할(및 해당 권한)이 ACL 트리를 따라 전파되는 방식을 이해하려면 아래 상속에 대한 섹션을 주의 깊게 읽으십시오.

14.7.3. 개체 및 경로

액세스 권한은 가상 머신, 스토리지 또는 리소스 풀과 같은 개체에 할당됩니다. 우리는 이러한 객체를 처리하기 위해 경로와 같은 파일 시스템을 사용합니다. 이러한 경로는 자연 트리를 형성하며 더 높은 수준의 권한(더 짧은 경로)은 선택적으로 이 계층 구조 내에서 아래로 전파될 수 있습니다.

경로를 템플릿화할 수 있습니다. API 호출에 템플릿 경로에 대한 권한이 필요한 경우 경로에는 API 호출 매개변수에 대한 참조가 포함될 수 있습니다. 이러한 참조는 중괄호 안에 지정됩니다. 일부 매개변수는 API 호출의 URI에서 암시적으로 가져옵니다. 예를 들어 /nodes/mynode/status를 호출할 때 권한 경로 /nodes/{node}에는 /nodes/mynode에 대한 권한이 필요한 반면, /access/acl에 대한 PUT 요청의 {path} 경로는 메서드의 경로 매개 변수를 참조합니다.

몇 가지 예는 다음과 같습니다:

• /nodes/{node}: Access to Proxmox VE server machines
• /vms: Covers all VMs
• /vms/{vmid}: Access to specific VMs
• /storage/{storeid}: Access to a specific storage
• /pool/{poolname}: Access to resources contained in a specific pool
• /access/groups: Group administration
• /access/realms/{realmid}: Administrative access to realms

상속

앞서 언급한 것처럼 개체 경로는 트리와 같은 파일 시스템을 형성하며 권한은 해당 트리 아래의 개체에 의해 상속될 수 있습니다(기본적으로 전파 플래그가 설정됨). 우리는 다음과 같은 상속 규칙을 사용합니다.

• 개별 사용자에 대한 권한은 항상 그룹 권한을 대체합니다.
• 그룹에 대한 권한은 사용자가 해당 그룹의 구성원인 경우 적용됩니다.
• 더 깊은 수준의 권한은 상위 수준에서 상속된 권한을 대체합니다.
• NoAccess는 지정된 경로의 다른 모든 역할을 취소합니다.

또한 권한 분리 토큰은 연결된 사용자에게 없는 특정 경로에 대한 권한을 가질 수 없습니다.

14.7.4. 풀

풀은 가상 머신 및 데이터 저장소 세트를 그룹화하는 데 사용할 수 있습니다. 그런 다음 모든 풀 구성원이 상속하는 풀(/pool/{poolid})에 대한 권한을 간단히 설정할 수 있습니다. 이는 액세스 제어를 단순화하는 좋은 방법입니다.

14.7.5. 어떤 권한이 필요합니까?

필요한 API 권한은 각 개별 메서드에 대해 문서화되어 있으며 https://pve.proxmox.com/pve-docs/api-viewer/에서 확인할 수 있습니다.

권한은 목록으로 지정되며 이는 논리 및 액세스 확인 기능의 트리로 해석될 수 있습니다.

• groups_param is set: The API call has a non-optional groups parameter and the caller must have any of the listed privileges on all of the listed groups.
• groups_param is not set: The user passed via the userid parameter must exist and be part of a group on which the caller has any of the listed privileges (via the /access/groups/ path).

• /storage/…: requires ‘Datastore.Allocate`
• /vms/…: requires ‘VM.Allocate`
• /pool/…: requires ‘Pool.Allocate`
  If the path is empty, Permissions.Modify on /access is required.
  If the user does not have the Permissions.Modify privilege, they can only delegate subsets of their own privileges on the given path (e.g., a user with PVEVMAdmin could assign PVEVMUser, but not PVEAdmin).

14.8. 명령줄 도구

대부분의 사용자는 단순히 GUI를 사용하여 사용자를 관리합니다. 그러나 pveum(“Proxmox VE User Manager”의 약자)이라는 완전한 기능을 갖춘 명령줄 도구도 있습니다. 모든 Proxmox VE 명령줄 도구는 API를 둘러싼 래퍼이므로 REST API를 통해 해당 기능에 액세스할 수도 있습니다.

다음은 몇 가지 간단한 사용 예입니다. 도움말을 표시하려면 다음을 입력하세요.

pveum

또는 (특정 명령에 대한 자세한 도움말을 표시하려면)

 pveum help user add

새 사용자를 생성합니다:

 pveum user add testuser@pve -comment "Just a test"

비밀번호를 설정하거나 변경합니다(일부 영역에서는 이를 지원하지 않음).

 pveum passwd testuser@pve

사용자 비활성화:

 pveum user modify testuser@pve -enable 0

새 그룹을 만듭니다.

 pveum group add testgroup

새 역할을 만듭니다.

 pveum role add PVE_Power-only -privs "VM.PowerMgmt VM.Console"

14.9. 실제 사례

14.9.1. 관리자 그룹

관리자는 루트 계정을 사용하지 않고 전체 관리자 권한을 가진 사용자 그룹을 생성하려고 할 수 있습니다.

이렇게 하려면 먼저 그룹을 정의합니다.

 pveum group add admin -comment "System Administrators"

그런 다음 역할을 할당합니다.

 pveum acl modify / -group admin -role Administrator

마지막으로 새 관리 그룹에 사용자를 추가할 수 있습니다.

 pveum user modify testuser@pve -group admin

14.9.2. 감사자
사용자 또는 그룹에 PVEAuditor 역할을 할당하여 사용자에게 읽기 전용 액세스 권한을 부여할 수 있습니다.

예 1: 사용자 joe@pve가 모든 것을 볼 수 있도록 허용

 pveum acl modify / -user joe@pve -role PVEAuditor

예 2: 사용자 joe@pve가 모든 가상 머신을 볼 수 있도록 허용

 pveum acl modify /vms -user joe@pve -role PVEAuditor

14.9.3. 사용자 관리 위임

사용자 관리를 joe@pve 사용자에게 위임하려면 다음을 사용하면 됩니다.

 pveum acl modify /access -user joe@pve -role PVEUserAdmin

사용자 joe@pve는 이제 사용자를 추가 및 제거하고 비밀번호와 같은 기타 사용자 속성을 변경할 수 있습니다. 이는 매우 강력한 역할이므로 선택한 영역 및 그룹으로 제한하고 싶을 가능성이 높습니다. 다음 예에서는 joe@pve가 그룹 고객의 구성원인 경우 pve 영역 내의 사용자를 수정할 수 있도록 허용합니다.

 pveum acl modify /access/realm/pve -user joe@pve -role PVEUserAdmin
 pveum acl modify /access/groups/customers -user joe@pve -role PVEUserAdmin

참고: 사용자는 다른 사용자를 추가할 수 있지만 해당 사용자가 고객 그룹의 구성원이고 영역 pve 내에 있는 경우에만 가능합니다.

14.9.4. 모니터링을 위한 제한된 API 토큰

API 토큰에 대한 권한은 항상 해당 사용자 권한의 하위 집합입니다. 즉, 지원 사용자가 수행할 권한이 없는 작업을 수행하는 데 API 토큰을 사용할 수 없다는 의미입니다. 이 섹션에서는 별도의 권한이 있는 API 토큰을 사용하여 토큰 소유자의 권한을 추가로 제한하는 방법을 보여줍니다.

사용자 joe@pve에게 모든 VM에서 PVEVMAdmin 역할을 부여합니다.

 pveum acl modify /vms -user joe@pve -role PVEVMAdmin

VM 정보 보기(예: 모니터링 목적)만 허용되는 별도의 권한이 있는 새 API 토큰을 추가합니다.

 pveum user token add joe@pve monitoring -privsep 1
 pveum acl modify /vms -token 'joe@pve!monitoring' -role PVEAuditor

사용자 및 토큰의 권한을 확인하십시오.

pveum user permissions joe@pve
pveum user token permissions joe@pve monitoring

14.9.5. 리소스 풀

기업은 일반적으로 여러 개의 작은 부서로 구성되며 각 부서에 리소스를 할당하고 관리 작업을 위임하는 것이 일반적입니다. 소프트웨어 개발 부서를 위한 풀을 설정한다고 가정해 보겠습니다. 먼저 그룹을 만듭니다.

 pveum group add developers -comment "Our software developers"

이제 해당 그룹의 구성원인 새 사용자를 만듭니다.

 pveum user add developer1@pve -group developers -password

참고: “-password” 매개변수는 비밀번호를 묻는 메시지를 표시합니다.
그런 다음 개발 부서에서 사용할 리소스 풀을 만듭니다.

 pveum pool add dev-pool --comment "IT development pool"

마지막으로 해당 풀에 권한을 할당할 수 있습니다.

 pveum acl modify /pool/dev-pool/ -group developers -role PVEAdmin

이제 우리 소프트웨어 개발자는 해당 풀에 할당된 리소스를 관리할 수 있습니다.