OpenStack ID와 외부 사용자 관리 서비스 통합
Active Directory 또는 Red Hat Identity Management를 외부 인증 백엔드로 사용
OpenStack Documentation Team
rhos-docs@redhat.com
초록
보다 포괄적 수용을 위한 오픈 소스 용어 교체
Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오. :leveloffset: +0
Red Hat 문서에 관한 피드백 제공
문서 개선을 위한 의견을 보내 주십시오. Red Hat이 어떻게 이를 개선하는지 알려주십시오.
DDF(직접 문서 피드백) 기능 사용
특정 문장, 단락 또는 코드 블록에 대한 직접 주석은 피드백 추가 DDF 기능을 사용하십시오.
- 다중 페이지 HTML 형식으로 설명서를 봅니다.
- 문서 오른쪽 상단에 Feedback (피드백) 버튼이 표시되는지 확인합니다.
- 주석 처리하려는 텍스트 부분을 강조 표시합니다.
- 피드백 추가를 클릭합니다.
- 주석을 사용하여 Add Feedback (피드백 추가) 필드를 작성합니다.
- 선택 사항: 설명서 팀이 문제에 대한 자세한 내용을 문의할 수 있도록 이메일 주소를 추가하십시오.
- Submit(제출)을 클릭합니다.
1장. OpenStack Identity(keystone)와 Active Directory 통합
OpenStack ID(keystone)를 Microsoft AD DS(Active Directory Domain Service)와 통합할 수 있습니다. ID 서비스는 특정 AD DS(Active Directory Domain Services) 사용자를 인증하지만 ID 서비스 데이터베이스에는 권한 부여 설정 및 중요한 서비스 계정이 포함됩니다. 결과적으로 ID 서비스는 사용자 계정 인증을 위해 AD DS에 대한 읽기 전용 액세스 권한을 가지며 인증된 계정에 할당된 권한을 계속 관리합니다.
ID 서비스를 AD DS와 통합하면 AD DS 사용자가 RHOSP(Red Hat OpenStack Platform)에 인증하여 리소스에 액세스할 수 있습니다. ID 서비스 및 이미지 서비스와 같은 RHOSP 서비스 계정과 권한 부여 관리는 ID 서비스 데이터베이스에 계속 유지됩니다. 권한 및 역할은 ID 서비스 관리 툴을 사용하여 AD DS 계정에 할당됩니다.
OpenStack Identity를 Active Directory와 통합하는 프로세스에는 다음 단계가 포함됩니다.
- Active Directory 자격 증명 구성 및 LDAPS 인증서 내보내기
- OpenStack에 LDAPS 인증서 설치 및 구성
- 하나 이상의 LDAP 백엔드를 사용하도록 director 설정
- Active Directory 백엔드에 액세스하도록 컨트롤러 노드 구성
- OpenStack 프로젝트에 대한 Active Directory 사용자 또는 그룹 액세스 구성
- 도메인 및 사용자 목록이 올바르게 생성되었는지 확인합니다.
- 선택 사항: 관리자가 아닌 사용자에 대한 자격 증명 파일을 만듭니다.
1.1. Active Directory 인증 정보 구성
OpenStack ID와 통합하도록 AD DS(Active Directory Domain Service)를 구성하려면 ID 서비스에서 사용할 LDAP 계정을 설정하고, Red Hat OpenStack Platform 배포에 사용할 사용자 그룹을 만들고, Red Hat OpenStack Platform 배포에 사용할 LDAPS 인증서 공개 키를 내보냅니다.
사전 요구 사항
- Active Directory 도메인 서비스가 구성되고 작동됨.
- Red Hat OpenStack Platform은 구성 및 운영됩니다.
- DNS 이름 확인은 완전히 작동하며 모든 호스트가 적절하게 등록됩니다.
- AD DS 인증 트래픽은 포트 636을 사용하여 LDAPS로 암호화됩니다.
- 권장 사항: 고가용성 또는 로드 밸런싱 솔루션으로 AD DS를 구현하여 단일 장애 지점을 방지합니다.
절차
Active Directory 서버에서 다음 단계를 수행합니다.
LDAP 조회 계정을 생성합니다. 이 계정은 ID 서비스에서 AD DS LDAP 서비스를 쿼리하는 데 사용됩니다.
PS C:\> New-ADUser -SamAccountName svc-ldap -Name "svc-ldap" -GivenName LDAP -Surname Lookups -UserPrincipalName svc-ldap@lab.local -Enabled $false -PasswordNeverExpires $true -Path 'OU=labUsers,DC=lab,DC=local'
이 계정의 암호를 설정한 다음 활성화합니다. AD 도메인의 복잡성 요구 사항을 준수하는 암호를 지정하라는 메시지가 표시됩니다.
PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount
grp-openstack
이라는 RHOSP 사용자의 그룹을 생성합니다. 이 그룹의 멤버만 OpenStack ID에 할당된 권한을 가질 수 있습니다.PS C:\> NEW-ADGroup -name "grp-openstack" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"
프로젝트 그룹을 생성합니다.
PS C:\> NEW-ADGroup -name "grp-openstack-demo" -groupscope Global -path "OU=labUsers,DC=lab,DC=local" PS C:\> NEW-ADGroup -name "grp-openstack-admin" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"
svc-ldap
사용자를grp-openstack
그룹에 추가합니다.PS C:\> ADD-ADGroupMember "grp-openstack" -members "svc-ldap"
-
AD 도메인 컨트롤러에서
인증서 MMC
를 사용하여 LDAPS 인증서의 공개 키(개인 키 아님)를 DER 인코딩x509
.cer 파일로 내보냅니다. 이 파일을 RHOSP 관리자에게 전송합니다. AD DS 도메인의 NetBIOS 이름을 검색합니다.
PS C:\> Get-ADDomain | select NetBIOSName NetBIOSName ----------- LAB
이 값을 RHOSP 관리자에게 전송합니다.
1.2. Active Directory LDAPS 인증서 설치
OpenStack Identity(keystone)는 LDAPS 쿼리를 사용하여 사용자 계정의 유효성을 검사합니다. 이 트래픽을 암호화하기 위해 keystone은 keystone.conf
에서 정의한 인증서 파일을 사용합니다. LDAPS 인증서를 구성하려면 Active Directory에서 수신한 공개 키를 .crt
형식으로 변환하고 keystone에서 참조할 수 있는 위치로 인증서를 복사합니다.
LDAP 인증에 여러 도메인을 사용하는 경우 Unable to retrieve authorized project(인증된 프로젝트를
검색할 수 없음) 또는 Peer의 Certificate 발행자가 인식되지 않는
다양한 오류가 표시될 수 있습니다. 이는 Keystone이 특정 도메인에 대해 잘못된 인증서를 사용하는 경우 발생할 수 있습니다. 이 문제를 해결하려면 모든 LDAPS 공개 키를 단일 .crt
번들로 병합하고 이 파일을 사용하도록 모든 keystone 도메인을 구성합니다.
사전 요구 사항
- Active Directory 자격 증명이 구성됩니다.
- LDAPS 인증서는 Active Directory에서 내보냅니다.
절차
OpenStack ID를 실행하는 노드에 LDAPS 공개 키를 복사하고
.cer를.
crt
로 변환합니다. 이 예에서는addc.lab.local.cer :이라는 소스 인증서 파일을 사용합니다.
# openssl x509 -inform der -in addc.lab.local.cer -out addc.lab.local.crt # cp addc.lab.local.crt /etc/pki/ca-trust/source/anchors
선택 사항:
ldapsearch
와 같은 진단 명령을 실행해야 하는 경우 RHEL 인증서 저장소에 인증서를 추가해야 합니다..cer를.
pem
으로 변환합니다. 이 예에서는addc.lab.local.cer :이라는 소스 인증서 파일을 사용합니다.
# openssl x509 -inform der -in addc.lab.local.cer -out addc.lab.local.pem
컨트롤러 노드에
.pem
을 설치합니다. 예를 들어 Red Hat Enterprise Linux에서는 다음과 같습니다.# cp addc.lab.local.pem /etc/pki/ca-trust/source/anchors/ # update-ca-trust
1.3. 도메인별 LDAP 백엔드를 사용하도록 director 구성
하나 이상의 LDAP 백엔드를 사용하도록 director를 구성하려면 heat 템플릿에서 KeystoneLDAPDomainEnable
플래그를 true
로 설정하고 각 LDAP 백엔드에 대한 정보로 환경 파일을 설정합니다. 그런 다음 director는 각 keystone 도메인에 별도의 LDAP 백엔드를 사용합니다.
도메인 구성 파일의 기본 디렉토리는 /etc/keystone/domains/
로 설정됩니다. 필수 경로를 keystone::domain_config_directory
hiera 키로 설정하고 환경 파일 내에 ExtraConfig
매개변수로 추가하여 이 경로를 재정의할 수 있습니다.
절차
-
배포에 사용할 heat 템플릿에서
KeystoneLDAPDomainEnable
플래그를true
로 설정합니다. 이렇게 하면identity
구성 그룹 내의 keystone에domain_specific_drivers_enabled
옵션이 구성됩니다. -
tripleo-heat-templates
에서KeystoneLDAPBackendConfigs
매개변수를 설정하여 LDAP 백엔드 구성 사양을 추가합니다. 그런 다음 필요한 LDAP 옵션을 지정할 수 있습니다. keystone_domain_specific_ldap_backend.yaml
환경 파일의 사본을 생성합니다.$ cp /usr/share/openstack-tripleo-heat-templates/environments/services/keystone_domain_specific_ldap_backend.yaml /home/stack/templates/
/home/stack/templates/keystone_domain_specific_ldap_backend.yaml
환경 파일을 편집하고 배포에 맞게 값을 설정합니다. 예를 들어 이 매개변수는testdomain
이라는 keystone 도메인에 대한 LDAP 구성을 생성합니다.parameter_defaults: KeystoneLDAPDomainEnable: true KeystoneLDAPBackendConfigs: testdomain: url: ldaps://192.0.2.250 user: cn=openstack,ou=Users,dc=director,dc=example,dc=com password: RedactedComplexPassword suffix: dc=director,dc=example,dc=com user_tree_dn: ou=Users,dc=director,dc=example,dc=com user_filter: "(memberOf=cn=OSuser,ou=Groups,dc=director,dc=example,dc=com)" user_objectclass: person user_id_attribute: cn
참고keystone_domain_specific_ldap_backend.yaml
환경 파일에는 더 이상 사용되지 않는 다음과 같은 쓰기 매개변수가 포함되어 있습니다.-
user_allow_create
-
user_allow_update
-
user_allow_delete
이러한 매개 변수의 값은 배포에 영향을 미치지 않으며 안전하게 제거할 수 있습니다.
-
선택 사항: 환경 파일에 더 많은 도메인을 추가합니다. 예를 들면 다음과 같습니다.
KeystoneLDAPBackendConfigs: domain1: url: ldaps://domain1.example.com user: cn=openstack,ou=Users,dc=director,dc=example,dc=com password: RedactedComplexPassword ... domain2: url: ldaps://domain2.example.com user: cn=openstack,ou=Users,dc=director,dc=example,dc=com password: RedactedComplexPassword ...
그러면 domain
1 및 domain
2
라는 두 개의 도메인이 생성됩니다. 각 도메인은 자체 구성과 다른 LDAP 도메인을 갖게 됩니다.
1.4. OpenStack ID 도메인에 대한 admin 사용자 액세스 권한 부여
admin
사용자가 OpenStack ID(keystone) 도메인에 액세스하고 Domain
(도메인) 탭을 보려면 도메인 및 admin
사용자의 ID를 가져온 다음 도메인의 사용자에게 admin
역할을 할당합니다.
이 권한은 OpenStack admin 계정에 외부 서비스 도메인에 대한 권한을 부여하지 않습니다. 이 경우 domain 이라는 용어는 keystone 도메인의 OpenStack 사용을 나타냅니다.
절차
이 절차에서는 LAB
도메인을 사용합니다. 도메인 이름을 구성 중인 도메인의 실제 이름으로 바꿉니다.
LAB
도메인의 ID를 가져옵니다.$ openstack domain show LAB +---------+----------------------------------+ | Field | Value | +---------+----------------------------------+ | enabled | True | | id | 6800b0496429431ab1c4efbb3fe810d4 | | name | LAB | +---------+----------------------------------+
기본
도메인에서admin
사용자의 ID를 가져옵니다.$ openstack user list --domain default | grep admin | 3d75388d351846c6a880e53b2508172a | admin |
admin
역할의 ID를 가져옵니다.$ openstack role list
출력은 통합 중인 외부 서비스에 따라 달라집니다.
Active Directory 도메인 서비스(AD DS):
+----------------------------------+-----------------+ | ID | Name | +----------------------------------+-----------------+ | 01d92614cd224a589bdf3b171afc5488 | admin | | 034e4620ed3d45969dfe8992af001514 | member | | 0aa377a807df4149b0a8c69b9560b106 | ResellerAdmin | | 9369f2bf754443f199c6d6b96479b1fa | heat_stack_user | | cfea5760d9c948e7b362abc1d06e557f | reader | | d5cb454559e44b47aaa8821df4e11af1 | swiftoperator | | ef3d3f510a474d6c860b4098ad658a29 | service | +----------------------------------+-----------------+
Red Hat IdM(Identity Manager):
+----------------------------------+---------------+ | ID | Name | +----------------------------------+---------------+ | 544d48aaffde48f1b3c31a52c35f01f9 | SwiftOperator | | 6d005d783bf0436e882c55c62457d33d | ResellerAdmin | | 785c70b150ee4c778fe4de088070b4cf | admin | | 9fe2ff9ee4384b1894a90878d3e92bab | _member_ | +----------------------------------+---------------+
도메인 및 admin ID를 사용하여
admin
사용자를 keystoneLAB
도메인의admin
역할에 추가하는 명령을 구성합니다.# openstack role add --domain 6800b0496429431ab1c4efbb3fe810d4 --user 3d75388d351846c6a880e53b2508172a 785c70b150ee4c778fe4de088070b4cf
1.5. Red Hat OpenStack Platform 프로젝트에 대한 외부 그룹 액세스 권한 부여
인증된 여러 사용자에게 RHOSP(Red Hat OpenStack Platform) 리소스에 대한 액세스 권한을 부여하려면 OpenStack 관리자가 프로젝트의 역할에 수동으로 각 사용자를 할당하지 않고 외부 사용자 관리 서비스에서 특정 그룹에 권한을 부여하여 RHOSP 프로젝트에 대한 액세스 권한을 부여할 수 있습니다. 결과적으로 이러한 그룹의 모든 구성원이 사전에 결정된 프로젝트에 액세스할 수 있습니다.
사전 요구 사항
외부 서비스 관리자가 다음 단계를 완료했는지 확인합니다.
-
grp-openstack-admin
이라는 그룹 만들기. -
grp-openstack-demo
라는 그룹 만들기. - 필요에 따라 이러한 그룹 중 하나에 RHOSP 사용자를 추가합니다.
-
사용자를 the
grp-openstack
그룹에 추가합니다.
-
-
OpenStack ID 도메인을 생성합니다. 이 절차에서는
LAB
도메인을 사용합니다. -
RHOSP 프로젝트를 생성하거나 선택합니다. 이 절차에서는
openstack project create --domain default --description "Demo Project" demo 명령으로
라는 프로젝트를 사용합니다.생성된
demo
절차
OpenStack ID 도메인에서 사용자 그룹 목록을 검색합니다.
# openstack group list --domain LAB
명령 출력은 통합 중인 외부 사용자 관리 서비스에 따라 다릅니다.
Active Directory 도메인 서비스(AD DS):
+------------------------------------------------------------------+---------------------+ | ID | Name | +------------------------------------------------------------------+---------------------+ | 185277be62ae17e498a69f98a59b66934fb1d6b7f745f14f5f68953a665b8851 | grp-openstack | | a8d17f19f464c4548c18b97e4aa331820f9d3be52654aa8094e698a9182cbb88 | grp-openstack-admin | | d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8 | grp-openstack-demo | +------------------------------------------------------------------+---------------------+
Red Hat IdM(Identity Manager):
+------------------------------------------------------------------+---------------------+ | ID | Name | +------------------------------------------------------------------+---------------------+ | 185277be62ae17e498a69f98a59b66934fb1d6b7f745f14f5f68953a665b8851 | grp-openstack | | a8d17f19f464c4548c18b97e4aa331820f9d3be52654aa8094e698a9182cbb88 | grp-openstack-admin | | d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8 | grp-openstack-demo | +------------------------------------------------------------------+---------------------+
역할 목록을 검색합니다.
# openstack role list
명령 출력은 통합 중인 외부 사용자 관리 서비스에 따라 다릅니다.
Active Directory 도메인 서비스(AD DS):
+----------------------------------+-----------------+ | ID | Name | +----------------------------------+-----------------+ | 01d92614cd224a589bdf3b171afc5488 | admin | | 034e4620ed3d45969dfe8992af001514 | member | | 0aa377a807df4149b0a8c69b9560b106 | ResellerAdmin | | 9369f2bf754443f199c6d6b96479b1fa | heat_stack_user | | cfea5760d9c948e7b362abc1d06e557f | reader | | d5cb454559e44b47aaa8821df4e11af1 | swiftoperator | | ef3d3f510a474d6c860b4098ad658a29 | service | +----------------------------------+-----------------+
Red Hat IdM(Identity Manager):
+----------------------------------+---------------+ | ID | Name | +----------------------------------+---------------+ | 0969957bce5e4f678ca6cef00e1abf8a | ResellerAdmin | | 1fcb3c9b50aa46ee8196aaaecc2b76b7 | admin | | 9fe2ff9ee4384b1894a90878d3e92bab | _member_ | | d3570730eb4b4780a7fed97eba197e1b | SwiftOperator | +----------------------------------+---------------+
이러한 역할 중 하나 이상에 추가하여 사용자 그룹에 RHOSP 프로젝트에 대한 액세스 권한을 부여합니다. 예를 들어, 통합 중인 외부 서비스에 따라 해당
그룹을
demo
프로젝트의 일반 사용자가 되도록 하려면 다음을 수행한 외부 서비스에 따라멤버
또는_member_
역할에 그룹을 추가해야 합니다.Active Directory 도메인 서비스(AD DS):
# openstack role add --project demo --group d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8 member
Red Hat IdM(Identity Manager):
$ openstack role add --project demo --group d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8 _member_
결과
사용자 이름과 암호를 입력하고 Domain
필드에 LAB
을 입력하여 대시보드에 로그인할 수
있습니다.
사용자에게 오류가 발생하면 오류: 컨테이너 목록을 검색할 수 없으며 컨테이너를 관리할 수 있어야 하는 경우
SwiftOperator
역할에 추가해야 합니다.
1.6. Red Hat OpenStack Platform 프로젝트에 대한 외부 사용자에게 액세스 권한 부여
OpenStack 리소스에 대한 the grp-openstack
그룹에서 인증된 특정 사용자에게 부여하려면 해당 사용자에게 RHOSP(Red Hat OpenStack Platform) 프로젝트에 대한 직접 액세스 권한을 부여할 수 있습니다. 그룹에 대한 액세스 권한을 부여하지 않고 개별 사용자에게 액세스 권한을 부여하려는 경우 이 프로세스를 사용합니다.
사전 요구 사항
외부 서비스 관리자가 다음 단계를 완료했는지 확인합니다.
-
grp-openstack
그룹에 RHOSP 사용자를 추가합니다. -
OpenStack ID 도메인 생성. 이 절차에서는
LAB
도메인을 사용합니다.
-
-
RHOSP 프로젝트를 생성하거나 선택합니다. 이 절차에서는
openstack project create --domain default --description "Demo Project" demo 명령으로
라는 프로젝트를 사용합니다.생성된
demo
절차
OpenStack ID 도메인에서 사용자 목록을 검색합니다.
# openstack user list --domain LAB +------------------------------------------------------------------+----------------+ | ID | Name | +------------------------------------------------------------------+----------------+ | 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e | user1 | | 12c062faddc5f8b065434d9ff6fce03eb9259537c93b411224588686e9a38bf1 | user2 | | afaf48031eb54c3e44e4cb0353f5b612084033ff70f63c22873d181fdae2e73c | user3 | | e47fc21dcf0d9716d2663766023e2d8dc15a6d9b01453854a898cabb2396826e | user4 | +------------------------------------------------------------------+----------------+
역할 목록을 검색합니다.
# openstack role list
명령 출력은 통합 중인 외부 사용자 관리 서비스에 따라 다릅니다.
Active Directory 도메인 서비스(AD DS):
+----------------------------------+-----------------+ | ID | Name | +----------------------------------+-----------------+ | 01d92614cd224a589bdf3b171afc5488 | admin | | 034e4620ed3d45969dfe8992af001514 | member | | 0aa377a807df4149b0a8c69b9560b106 | ResellerAdmin | | 9369f2bf754443f199c6d6b96479b1fa | heat_stack_user | | cfea5760d9c948e7b362abc1d06e557f | reader | | d5cb454559e44b47aaa8821df4e11af1 | swiftoperator | | ef3d3f510a474d6c860b4098ad658a29 | service | +----------------------------------+-----------------+
Red Hat IdM(Identity Manager):
+----------------------------------+---------------+ | ID | Name | +----------------------------------+---------------+ | 0969957bce5e4f678ca6cef00e1abf8a | ResellerAdmin | | 1fcb3c9b50aa46ee8196aaaecc2b76b7 | admin | | 9fe2ff9ee4384b1894a90878d3e92bab | _member_ | | d3570730eb4b4780a7fed97eba197e1b | SwiftOperator | +----------------------------------+---------------+
이러한 역할 중 하나 이상에 추가하여 RHOSP 프로젝트에 대한 액세스 권한을 부여합니다. 예를 들어,
user1
이demo
프로젝트의 일반 사용자가 되도록 하려면 통합 중인 외부 서비스에 따라member
또는_member_
역할에 추가합니다.Active Directory 도메인 서비스(AD DS):
# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e member
Red Hat IdM(Identity Manager):
# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e _member_
user1
이demo
프로젝트의 관리 사용자가 되도록 하려면 사용자를admin
역할에 추가합니다.# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e admin
결과
user1
사용자는 외부 사용자 이름 및 암호를 입력하고 Domain
(도메인) 필드에 LAB
을 입력하여 대시보드에 로그인할 수 있습니다.
사용자에게 오류가 발생하면 오류: 컨테이너 목록을 검색할 수 없으며 컨테이너를 관리할 수 있어야 하는 경우
SwiftOperator
역할에 추가해야 합니다.
1.7. OpenStack ID 도메인 및 사용자 목록 보기
openstack domain list
명령을 사용하여 사용 가능한 항목을 나열합니다. ID 서비스에서 여러 도메인을 구성하면 대시보드 로그인 페이지에서 새 Domain (도메인) 필드가 활성화됩니다. 사용자는 로그인 자격 증명과 일치하는 도메인을 입력해야 합니다.
통합을 완료한 후 Default
도메인 또는 새로 생성된 keystone 도메인에서 새 프로젝트를 생성할지 여부를 결정해야 합니다. 워크플로와 사용자 계정을 관리하는 방법을 고려해야 합니다. 가능한 경우 Default
도메인을 내부 도메인으로 사용하여 서비스 계정 및 admin
프로젝트를 관리하고 외부 사용자를 별도의 도메인에 유지합니다.
이 예에서 외부 계정은 LAB
도메인을 지정해야 합니다. admin
과 같은 기본 제공 keystone 계정은 Default
를 도메인으로 지정해야 합니다.
절차
도메인 목록을 표시합니다.
# openstack domain list +----------------------------------+---------+---------+----------------------------------------------------------------------+ | ID | Name | Enabled | Description | +----------------------------------+---------+---------+----------------------------------------------------------------------+ | 6800b0496429431ab1c4efbb3fe810d4 | LAB | True | | | default | Default | True | Owns users and projects available on Identity API v2. | +----------------------------------+---------+---------+----------------------------------------------------------------------+
특정 도메인의 사용자 목록을 표시합니다. 이 명령은
--domain LAB
을 지정하고grp-openstack
그룹의 멤버인 LAB 도메인에 사용자를 반환합니다.# openstack user list --domain LAB
기본 제공 keystone 계정을 표시하려면
--domain Default
를 추가할 수도 있습니다.# openstack user list --domain Default
1.8. 관리자가 아닌 사용자의 자격 증명 파일 생성
OpenStack ID에 대한 사용자 및 도메인을 구성한 후 관리자 이외의 사용자에 대한 자격 증명 파일을 만들어야 할 수 있습니다.
절차
관리자가 아닌 사용자의 자격 증명(RC) 파일을 만듭니다. 이 예에서는 파일에서
user1
사용자를 사용합니다.$ cat overcloudrc-v3-user1 # Clear any old environment that may conflict. for key in $( set | awk '{FS="="} /^OS_/ {print $1}' ); do unset $key ; done export OS_USERNAME=user1 export NOVA_VERSION=1.1 export OS_PROJECT_NAME=demo export OS_PASSWORD=RedactedComplexPassword export OS_NO_CACHE=True export COMPUTE_API_VERSION=1.1 export no_proxy=,10.0.0.5,192.168.2.11 export OS_CLOUDNAME=overcloud export OS_AUTH_URL=https://10.0.0.5:5000/v3 export OS_AUTH_TYPE=password export PYTHONWARNINGS="ignore:Certificate has no, ignore:A true SSLContext object is not available" export OS_IDENTITY_API_VERSION=3 export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=LAB
1.9. 외부 사용자 관리 서비스로 OpenStack Identity 통합 테스트
OpenStack Identity(keystone)가 AD DS(Active Directory Domain Service)와 성공적으로 통합되었는지 테스트하려면 대시보드 기능에 대한 사용자 액세스를 테스트합니다.
사전 요구 사항
- AD(Active Directory) 또는 Red Hat IdM(Identity Manager)과 같은 외부 사용자 관리 서비스와 통합
절차
-
외부 사용자 관리 서비스에서 test 사용자를 생성하고 사용자를
grp-openstack
그룹에 추가합니다. -
Red Hat OpenStack Platform에서
demo
프로젝트의_member_
역할에 사용자를 추가합니다. - AD 테스트 사용자의 자격 증명을 사용하여 대시보드에 로그인합니다.
- 각 탭을 클릭하여 오류 메시지 없이 성공적으로 표시되는지 확인합니다.
- 대시보드를 사용하여 테스트 인스턴스를 구축합니다.
이러한 단계에 문제가 발생하면 admin
계정으로 대시보드에 로그인하고 해당 사용자로 후속 단계를 수행합니다. 테스트에 성공하면 OpenStack이 여전히 예상대로 작동 중이며 OpenStack ID와 Active Directory의 통합 설정에 문제가 있음을 나타냅니다.
1.10. Active Directory 통합 문제 해결
OpenStack ID와 Active Directory 통합을 사용할 때 오류가 발생하면 LDAP 연결을 테스트하거나 인증서 신뢰 구성을 테스트해야 할 수 있습니다. LDAPS 포트에 액세스할 수도 있습니다.
오류 유형 및 위치에 따라 이 절차의 관련 단계만 수행합니다.
절차
ldapsearch
명령을 사용하여 Active Directory 도메인 컨트롤러에 대한 테스트 쿼리를 원격으로 수행하여 LDAP 연결을 테스트합니다. 여기에서 성공적인 결과는 네트워크 연결이 작동 중이며 AD DS 서비스가 작동 중임을 나타냅니다. 이 예제에서는 포트636
의addc.lab.local
서버에 대해 테스트 쿼리를 수행합니다.# ldapsearch -Z -x -H ldaps://addc.lab.local:636 -D "svc-ldap@lab.local" -W -b "OU=labUsers,DC=lab,DC=local" -s sub "(cn=*)" cn
참고-
ldapsearch
는openldap-clients
패키지의 일부입니다.# dnf install openldap-clients
를 사용하여 설치할 수 있습니다. - 이 명령은 호스트 운영 체제에서 필요한 인증서를 찾아야 합니다.
-
Peer의 Certificate 발행자가 인식되지 않는 오류가 표시되면
ldapsearch
명령을 테스트하는 동안TLS_CACERTDIR
경로가 올바르게 설정되었는지 확인합니다. 예를 들면 다음과 같습니다.TLS_CACERTDIR /etc/openldap/certs
임시 해결 방법으로 인증서 유효성 검사를 비활성화하는 것이 좋습니다.
중요이 설정을 영구적으로 구성해서는 안 됩니다.
/etc/openldap/ldap.conf
에서 다음을허용하도록
TLS_REERT
매개변수를 설정합니다.TLS_REQCERT allow
이 값을 설정한 후
ldapsearch
쿼리가 작동하는 경우 인증서 신뢰가 올바르게 구성되었는지 검토해야 할 수 있습니다.nc
명령을 사용하여 LDAPS 포트636
에 원격으로 액세스할 수 있는지 확인합니다. 이 예제에서는 프로브가addc.lab.local
서버에 대해 수행됩니다.ctrl-c
를 눌러 프롬프트를 종료합니다.# nc -v addc.lab.local 636 Ncat: Version 6.40 ( http://nmap.org/ncat ) Ncat: Connected to 192.168.200.10:636. ^C
연결을 설정하지 못한 경우 방화벽 구성 문제가 표시될 수 있습니다.
2장. OpenStack Identity(keystone)와 Red Hat IdM(Identity Manager) 통합
OpenStack Identity(keystone)를 Red Hat IdM(Identity Manager)과 통합할 때 OpenStack ID는 특정 Red Hat IdM(Identity Management) 사용자를 인증하지만 ID 서비스 데이터베이스에 인증 설정 및 중요한 서비스 계정을 유지합니다. 결과적으로 ID 서비스에는 사용자 계정 인증을 위해 IdM에 대한 읽기 전용 액세스 권한이 있으며 인증된 계정에 할당된 권한에 대한 관리가 유지됩니다. tripleo-ipa
또는 novajoin
을 사용하여 노드를 IdM에 등록할 수도 있습니다.
이 통합에 대한 구성 파일은 Puppet에서 관리합니다. 따라서 다음에 openstack overcloud deploy
명령을 실행할 때 추가하는 사용자 정의 구성을 덮어쓸 수 있습니다. director를 사용하여 구성 파일을 수동으로 편집하지 않고 LDAP 인증을 설정할 수 있습니다.
IdM 통합을 계획하고 구성하기 전에 다음 주요 용어를 검토하십시오.
- 인증 - 암호를 사용하여 사용자가 요청하는 대상인지 확인하는 프로세스입니다.
- 권한 부여 - 인증된 사용자에게 액세스하려는 시스템에 대한 적절한 권한이 있는지 검증.
- domain - ID 서비스에 구성된 추가 백엔드를 나타냅니다. 예를 들어 외부 IdM 환경에서 사용자를 인증하도록 ID 서비스를 구성할 수 있습니다. 결과적으로 생성된 사용자 컬렉션은 도메인으로 간주할 수 있습니다 .
OpenStack ID를 IdM과 통합하는 프로세스에는 다음 단계가 포함됩니다.
- novajoin을 사용하여 IdM에 언더클라우드 및 오버클라우드 등록
- Ansible을 사용하여 언더클라우드 및 오버클라우드에 TLS-e 구현
- IdM 서버 자격 증명을 설정하고 LDAPS 인증서를 내보냅니다.
- OpenStack에 LDAPS 인증서 설치 및 구성
- 하나 이상의 LDAP 백엔드를 사용하도록 director 설정
- IdM 백엔드에 액세스하도록 컨트롤러 노드 구성
- OpenStack 프로젝트에 대한 IdM 사용자 또는 그룹 액세스 권한 구성
- 도메인 및 사용자 목록이 올바르게 생성되었는지 확인합니다.
- 선택 사항: 관리자가 아닌 사용자에 대한 인증 정보 파일 만들기
2.1. Red Hat IdM(Identity Manager) 통합 계획
Red Hat IdM(Identity Manager)과 OpenStack Identity 통합을 계획할 때 두 서비스가 모두 구성 및 작동하는지 확인하고 사용자 관리 및 방화벽 설정에 대한 통합의 영향을 검토합니다.
- 사전 요구 사항
- Red Hat Identity Management가 구성 및 작동합니다.
- Red Hat OpenStack Platform은 구성 및 운영됩니다.
- DNS 이름 확인은 완전히 작동하며 모든 호스트가 적절하게 등록됩니다.
- 권한 및 역할
- 이러한 통합을 통해 IdM 사용자는 OpenStack에 인증하고 리소스에 액세스할 수 있습니다. OpenStack 서비스 계정(예: keystone 및 glance)과 권한 관리(권한 및 역할)는 ID 서비스 데이터베이스에 유지됩니다. 권한 및 역할은 ID 서비스 관리 툴을 사용하여 IdM 계정에 할당됩니다.
- 고가용성 옵션
- 이 구성은 단일 IdM 서버의 가용성에 종속됩니다. ID 서비스가 IdM 서버에 인증할 수 없는 경우 프로젝트 사용자는 영향을 받습니다. 다른 IdM 서버를 쿼리하도록 keystone을 구성하거나, 사용할 수 없게 되거나 로드 밸런서를 사용할 수 있습니다. 이 구성이 클라이언트에 장애 조치가 구현되었으므로 SSSD와 함께 IdM을 사용할 때는 로드 밸런서를 사용하지 마십시오.
- 가동 정지 요구 사항
- IdM 백엔드를 추가하려면 ID 서비스를 다시 시작해야 합니다.
- 사용자가 IdM에 계정이 생성될 때까지 대시보드에 액세스할 수 없습니다. 다운타임을 줄이려면 이 변경 전에 IdM 계정을 미리 작성하는 것이 좋습니다.
- 방화벽 구성
IdM과 OpenStack 간의 통신은 다음으로 구성됩니다.
- 사용자 인증
- 2시간마다 컨트롤러에서 CRD(인증서 폐기 목록) IdM 검색
- 만료 시 새 인증서 요청
초기 요청이 실패해도 주기적인 certmonger 작업은 새 인증서를 계속 요청합니다.
방화벽이 IdM과 OpenStack 간의 트래픽을 필터링하는 경우 다음 포트를 통해 액세스를 허용해야 합니다.
소스 | 대상 | 유형 | 포트 |
---|---|---|---|
OpenStack Controller 노드 | Red Hat Identity Management | LDAPS | TCP 636 |
2.2. OpenStack에 대한 IdM(Identity Management) 서버 권장 사항
Red Hat은 IdM 서버 및 OpenStack 환경을 통합하는 데 도움이 되는 다음 정보를 제공합니다.
IdM 설치를 위해 Red Hat Enterprise Linux 준비에 대한 자세한 내용은 Identity Management 설치를 참조하십시오.
ipa-server-install
명령을 실행하여 IdM을 설치 및 구성합니다. 명령 매개변수를 사용하여 대화형 프롬프트를 건너뛸 수 있습니다. IdM 서버가 Red Hat OpenStack Platform 환경과 통합할 수 있도록 다음 권장 사항을 사용하십시오.
표 2.1. 매개변수 권장 사항
옵션 | 권장 사항 |
---|---|
| 제공하는 값을 기록해 둡니다. IdM을 사용하도록 Red Hat OpenStack Platform을 구성할 때 이 암호가 필요합니다. |
| 제공하는 값을 기록해 둡니다. 언더클라우드 및 오버클라우드 노드에는 이 IP 주소에 대한 네트워크 액세스가 필요합니다. |
| IdM 서버에 통합 DNS 서비스를 설치하려면 이 옵션을 사용합니다. 언더클라우드 및 오버클라우드 노드는 도메인 이름 확인을 위해 IdM 서버를 사용합니다. |
|
|
| IdM 서버 IP 주소에 대한 역방향 레코드 및 영역을 확인하려면 이 옵션을 사용합니다. 역방향 레코드 또는 영역을 확인할 수 없는 경우 IdM은 역방향 영역을 생성합니다. 이를 통해 IdM 배포가 간소화됩니다. |
| 이러한 옵션 중 하나 또는 둘 다를 사용하여 NTP 소스를 구성할 수 있습니다. IdM 서버와 OpenStack 환경 모두 올바르고 동기화된 시간이 있어야 합니다. |
Red Hat OpenStack Platform 노드와의 통신을 활성화하려면 IdM에 필요한 방화벽 포트를 열어야 합니다. 자세한 내용은 IdM에 필요한 포트 열기를 참조하십시오.
2.3. Ansible을 사용하여 TLS-e 구현
새로운 tripleo-ipa
방법을 사용하여 TLS(TLS)라고 하는 오버클라우드 끝점에서 SSL/TLS를 활성화할 수 있습니다. 필요한 인증서 수로 인해 Red Hat OpenStack Platform은 Red Hat IdM(Identity Management)과 통합됩니다. tripleo-ipa
를 사용하여 TLS-e를 구성하는 경우 IdM은 인증 기관입니다.
사전 요구 사항
언더클라우드의 모든 구성 단계(예: stack 사용자 생성)가 완료되었는지 확인합니다. 자세한 내용은 Director 설치 및 사용을 참조하십시오.
절차
다음 절차에 따라 Red Hat OpenStack Platform의 새 설치 또는 TLS-e로 구성하려는 기존 배포에서 TLS-e를 구현합니다. 사전 프로비저닝된 노드에 TLS-e를 사용하여 Red Hat OpenStack Platform을 배포하는 경우 이 방법을 사용해야 합니다.
기존 환경에 TLS-e를 구현하는 경우 openstack undercloud install
, openstack overcloud deploy
와 같은 명령을 실행해야 합니다. 이러한 절차는 idempotent이며 업데이트된 템플릿 및 구성 파일과 일치하도록 기존 배포 구성만 조정합니다.
/etc/resolv.conf
파일을 구성합니다./etc/resolv.conf
의 언더클라우드에 적절한 검색 도메인과 이름 서버를 설정합니다. 예를 들어 배포 도메인이example.com
이고 FreeIPA 서버의 도메인이bigcorp.com
인 경우 /etc/resolv.conf에 다음 행을 추가합니다.search example.com bigcorp.com nameserver $IDM_SERVER_IP_ADDR
필요한 소프트웨어를 설치합니다.
sudo dnf install -y python3-ipalib python3-ipaclient krb5-devel
환경에 고유한 값을 사용하여 환경 변수를 내보냅니다.
export IPA_DOMAIN=bigcorp.com export IPA_REALM=BIGCORP.COM export IPA_ADMIN_USER=$IPA_USER export IPA_ADMIN_PASSWORD=$IPA_PASSWORD export IPA_SERVER_HOSTNAME=ipa.bigcorp.com export UNDERCLOUD_FQDN=undercloud.example.com export USER=stack export CLOUD_DOMAIN=example.com
참고IdM 사용자 자격 증명은 새 호스트 및 서비스를 추가할 수 있는 관리자여야 합니다.
언더클라우드에서
undercloud-ipa-install.yaml
ansible 플레이북을 실행합니다.ansible-playbook \ --ssh-extra-args "-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" \ /usr/share/ansible/tripleo-playbooks/undercloud-ipa-install.yaml
undercloud.conf에 다음 매개 변수를 추가합니다.
undercloud_nameservers = $IDM_SERVER_IP_ADDR overcloud_domain_name = example.com
언더클라우드를 배포합니다.
openstack undercloud install
검증
다음 단계를 완료하여 언더클라우드가 올바르게 등록되었는지 확인합니다.
IdM에 호스트를 나열합니다.
$ kinit admin $ ipa host-find
언더클라우드에
/etc/novajoin/krb5.keytab
이 있는지 확인합니다.ls /etc/novajoin/krb5.keytab
novajoin
디렉터리 이름은 레거시 명명 목적으로만 사용됩니다.
오버클라우드에서 TLS-e 구성
TLS-e(TLS-e)를 사용하여 오버클라우드를 배포하면 Undercloud 및 Overcloud의 IP 주소가 IdM에 자동으로 등록됩니다.
자동 IP 주소 등록을 비활성화하려면 IDMModifyDNS
heat 매개변수를 false로 설정합니다.
parameter_defaults: .... IdMModifyDNS: false
오버클라우드를 배포하기 전에 다음과 유사한 내용을 사용하여 YAML 파일
tls-parameters.yaml
을 생성합니다. 선택한 값은 환경에 따라 다릅니다.parameter_defaults: DnsSearchDomains: ["example.com"] DnsServers: ["192.168.1.13"] CloudDomain: example.com CloudName: overcloud.example.com CloudNameInternal: overcloud.internalapi.example.com CloudNameStorage: overcloud.storage.example.com CloudNameStorageManagement: overcloud.storagemgmt.example.com CloudNameCtlplane: overcloud.ctlplane.example.com IdMServer: freeipa-0.redhat.local IdMDomain: redhat.local IdMInstallClientPackages: False resource_registry: OS::TripleO::Services::IpaClient: /usr/share/openstack-tripleo-heat-templates/deployment/ipa/ipaservices-baremetal-ansible.yaml
-
DnsServers
매개 변수에는 IdM 서버의 IP 주소를 반영하는 값이 있어야 합니다. -
IdM 서버의 도메인이 클라우드 도메인과 다른 경우
DnsSearchDomains
매개변수에 포함합니다. 예를 들면 다음과 같습니다.DnsSearchDomains: ["example.com", "bigcorp.com"]
-
사전 프로비저닝된 노드가 있는 경우 오버클라우드 노드에 필요한 패키지를 설치하려면
IDMInstallClientPackages
매개변수 값을true
로 설정합니다. -
복제된 IdM 환경을 사용할 때
IdmServer
매개변수에 대해 여러 쉼표로 구분된 값을 설정할 수 있습니다. IdM 복제본에 대한 자세한 내용은 IdM 복제본 설치를 참조하십시오. -
OS::TripleO::Services::IpaClient
매개변수의 표시된 값은enable-internal-tls.yaml
파일의 기본 설정을 재정의합니다.tls-parameters.yaml
파일이openstack overcloud deploy
명령에서enable-internal-tls.yaml
을 따르는지 확인해야 합니다. -
cinder가 active-active로 구성된 DCN(분산 계산 노드) 아키텍처를 실행하는 경우
EnableEtcdInternalTLS
매개변수를true
로 추가하고 설정해야 합니다.
-
Overcloud를 배포합니다. 배포 명령에 tls-parameters.yaml을 포함해야 합니다.
DEFAULT_TEMPLATES=/usr/share/openstack-tripleo-heat-templates/ CUSTOM_TEMPLATES=/home/stack/templates openstack overcloud deploy \ -e ${DEFAULT_TEMPLATES}/environments/ssl/tls-everywhere-endpoints-dns.yaml \ -e ${DEFAULT_TEMPLATES}/environments/services/haproxy-public-tls-certmonger.yaml \ -e ${DEFAULT_TEMPLATES}/environments/ssl/enable-internal-tls.yaml \ -e ${CUSTOM_TEMPLATES}/tls-parameters.yaml \ ...
끝점 목록에 대한 keystone을 쿼리하여 각 끝점이 HTTPS를 사용하고 있는지 확인합니다.
openstack endpoint list
2.4. novajoin을 사용하여 Red Hat IdM(Identity Manager)에 노드 등록
novajoin은 배포 프로세스의 일부로 Red Hat IdM(Identity Manager)에 노드를 등록하는 데 사용하는 기본 도구입니다. Red Hat은 TLS-e를 사용하여 언더클라우드 및 오버클라우드를 설정하기 위해 기본 novajoin
솔루션을 통해 새로운 ansible 기반 tripleo-ipa
솔루션을 권장합니다. 자세한 내용은 Ansible을 사용하여 TLS-e 구현에서 참조하십시오.
나머지 IdM 통합을 진행하기 전에 등록 프로세스를 수행해야 합니다. 등록 과정에는 다음 단계가 포함됩니다.
- 언더클라우드 노드를 CA(인증 기관)에 추가
- IdM에 언더클라우드 노드 추가
- 선택 사항: IdM 서버를 오버클라우드의 DNS 서버로 설정
- 환경 파일 준비 및 오버클라우드 배포
- IdM 및 RHOSP에서 오버클라우드 등록 테스트
- 선택 사항: IdM에서 novajoin의 DNS 항목 추가
novajoin에 IdM 등록은 현재 언더클라우드 및 오버클라우드 노드에서만 사용할 수 있습니다. 오버클라우드 인스턴스에 대한 novajoin 통합은 이후 릴리스에서 지원될 것으로 예상됩니다.
2.4.1. 인증 기관에 언더클라우드 노드 추가
오버클라우드를 배포하기 전에 언더클라우드 노드에 python3-novajoin 패키지를 설치하고
스크립트를 실행하여 언더클라우드를 CA(인증 기관)에 추가합니다.
novajoin
-ipa-setup
절차
언더클라우드 노드에서
python3-novajoin
패키지를 설치합니다.$ sudo dnf install python3-novajoin
언더클라우드 노드에서
novajoin-ipa-setup
스크립트를 실행하고 배포에 맞게 값을 조정합니다.$ sudo /usr/libexec/novajoin-ipa-setup \ --principal admin \ --password <IdM admin password> \ --server <IdM server hostname> \ --realm <realm> \ --domain <overcloud cloud domain> \ --hostname <undercloud hostname> \ --precreate
결과 OTP(One-Time Password)를 사용하여 Undercloud를 등록합니다.
2.4.2. Red Hat IdM(Identity Manager)에 언더클라우드 노드 추가
언더클라우드 노드를 CA(인증 기관)에 추가한 후 IdM을 사용하여 언더클라우드를 등록하고 novajoin을 구성합니다. undercloud.conf
파일의 [DEFAULT]
섹션에 다음 설정을 구성합니다.
절차
novajoin
서비스를 활성화합니다.[DEFAULT] enable_novajoin = true
IdM을 사용하여 언더클라우드 노드를 등록할 수 있도록 1회성 암호(OTP)를 설정합니다.
ipa_otp = <otp>
neutron의 DHCP 서버에서 제공할 오버클라우드의 도메인 이름을 설정합니다.
overcloud_domain_name = <domain>
언더클라우드의 호스트 이름을 설정합니다.
undercloud_hostname = <undercloud FQDN>
IdM을 언더클라우드의 이름 서버로 설정합니다.
undercloud_nameservers = <IdM IP>
더 큰 환경의 경우 novajoin 연결 시간 제한 값을 검토하십시오.
undercloud.conf
파일에서undercloud-timeout.yaml이라는 새 파일에 참조를 추가합니다.
hieradata_override = /home/stack/undercloud-timeout.yaml
undercloud-timeout.yaml
에 다음 옵션을 추가합니다. 시간 제한 값을 초 단위로 지정할 수 있습니다(예:5)
:nova::api::vendordata_dynamic_connect_timeout: <timeout value> nova::api::vendordata_dynamic_read_timeout: <timeout value>
선택 사항: 로컬 openSSL 인증 기관에서 director의 공용 끝점에 대한 SSL 인증서를 생성
하려면 generate_service_certificate
매개변수를true
로 설정합니다.generate_service_certificate = true
-
undercloud.conf
파일을 저장합니다. 언더클라우드 배포 명령을 실행하여 기존 언더클라우드에 변경 사항을 적용합니다.
$ openstack undercloud install
검증
다음 단계를 완료하여 언더클라우드가 올바르게 등록되었는지 확인합니다.
IdM에 호스트를 나열합니다.
$ kinit admin $ ipa host-find
언더클라우드에
/etc/novajoin/krb5.keytab
이 있는지 확인합니다.ls /etc/novajoin/krb5.keytab
2.4.3. 오버클라우드의 DNS 서버로 Red Hat IdM(Identity Manager) 설정
IdM 환경에 대한 자동 감지 및 등록이 용이하려면 DNS 서버로 IdM을 설정합니다. 이 절차는 선택 사항이지만 권장되는 절차입니다.
절차
언더클라우드에 연결합니다.
$ source ~/stackrc
IdM을 DNS 이름 서버로 사용하도록 컨트롤 플레인 서브넷을 구성합니다.
$ openstack subnet set ctlplane-subnet --dns-nameserver <idm_server_address>
IdM 서버를 사용하도록 환경 파일에서
DnsServers
매개변수를 설정합니다.parameter_defaults: DnsServers: ["<idm_server_address>"]
일반적으로 이 매개변수는 사용자 지정
network-environment.yaml
파일에 정의됩니다.
2.4.4. novajoin 등록을 사용하여 환경 파일 준비 및 오버클라우드 배포
IdM 통합을 사용하여 오버클라우드를 배포하려면 환경 파일을 생성하고 편집하여 오버클라우드에서 정의한 도메인을 기반으로 사용자 지정 도메인 매개변수
을 사용하도록 오버클라우드를 구성합니다. 그런 다음 모든 환경 파일과 배포에 필요한 추가 환경 파일을 사용하여 오버클라우드를 배포합니다.
CloudDomain
및 CloudName
절차
/usr/share/openstack-tripleo-heat-templates/environments/predictable-placement/custom-domain.yaml
환경 파일의 사본을 생성합니다.$ cp /usr/share/openstack-tripleo-heat-templates/environments/predictable-placement/custom-domain.yaml \ /home/stack/templates/custom-domain.yaml
/home/stack/templates/custom-domain.yaml
환경 파일을 편집하고 배포에 맞게CloudDomain
및CloudName*
값을 설정합니다.parameter_defaults: CloudDomain: lab.local CloudName: overcloud.lab.local CloudNameInternal: overcloud.internalapi.lab.local CloudNameStorage: overcloud.storage.lab.local CloudNameStorageManagement: overcloud.storagemgmt.lab.local CloudNameCtlplane: overcloud.ctlplane.lab.local
사용자 환경에 적합한 TLS 구현을 선택합니다.
enable-tls.yaml
환경 파일을 사용하여 사용자 정의 인증서로 외부 끝점을 보호합니다.-
/usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-tls.yaml
을/home/stack/templates
로 복사합니다. -
사용자 정의 인증서 및 키를 포함하도록
/home/stack/enable-tls.yaml
환경 파일을 수정합니다. 배포에 다음 환경 파일을 포함하여 내부 및 외부 끝점을 보호합니다.
- enable-internal-tls.yaml
- tls-every-endpoints-dns.yaml
- custom-domain.yaml
enable-tls.yaml
openstack overcloud deploy \ --templates \ -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-everywhere-endpoints-dns.yaml \ -e /home/stack/templates/custom-domain.yaml \ -e /home/stack/templates/enable-tls.yaml
-
haproxy-public-tls-certmonger.yaml
환경 파일을 사용하여 IdM에서 발급한 인증서로 외부 엔드포인트를 보호합니다. 이 구현을 위해 novajoin에서 사용하는 VIP 끝점의 DNS 항목을 생성해야 합니다.novajoin에서 사용하는 VIP 끝점의 DNS 항목을 생성해야 합니다.
'/home/stack/templates의 사용자 지정 network-environment.yaml 파일에 있는
오버클라우드 네트워크를 식별합니다.parameter_defaults: ControlPlaneDefaultRoute: 192.168.24.1 ExternalAllocationPools: - end: 10.0.0.149 start: 10.0.0.101 InternalApiAllocationPools: - end: 172.17.1.149 start: 172.17.1.10 StorageAllocationPools: - end: 172.17.3.149 start: 172.17.3.10 StorageMgmtAllocationPools: - end: 172.17.4.149 start: 172.17.4.10
heat 템플릿에 각 오버클라우드 네트워크의 가상 IP 주소 목록을 생성합니다(예:
/home/stack/public_vib.yaml
).parameter_defaults: ControlFixedIPs: [{'ip_address':'192.168.24.101'}] PublicVirtualFixedIPs: [{'ip_address':'10.0.0.101'}] InternalApiVirtualFixedIPs: [{'ip_address':'172.17.1.101'}] StorageVirtualFixedIPs: [{'ip_address':'172.17.3.101'}] StorageMgmtVirtualFixedIPs: [{'ip_address':'172.17.4.101'}] RedisVirtualFixedIPs: [{'ip_address':'172.17.1.102'}]
필요에 따라 각 VIP 및 영역에 대한 DNS 항목을 IdM에 추가합니다.
ipa dnsrecord-add lab.local overcloud --a-rec 10.0.0.101 ipa dnszone-add ctlplane.lab.local ipa dnsrecord-add ctlplane.lab.local overcloud --a-rec 192.168.24.101 ipa dnszone-add internalapi.lab.local ipa dnsrecord-add internalapi.lab.local overcloud --a-rec 172.17.1.101 ipa dnszone-add storage.lab.local ipa dnsrecord-add storage.lab.local overcloud --a-rec 172.17.3.101 ipa dnszone-add storagemgmt.lab.local ipa dnsrecord-add storagemgmt.lab.local overcloud --a-rec 172.17.4.101
배포에 다음 환경 파일을 포함하여 내부 및 외부 끝점을 보호합니다.
- enable-internal-tls.yaml
- tls-everywhere-endpoints-dns.yaml
- haproxy-public-tls-certmonger.yaml
- custom-domain.yaml
public_vib.yaml
openstack overcloud deploy \ --templates \ -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-everywhere-endpoints-dns.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services/haproxy-public-tls-certmonger.yaml \ -e /home/stack/templates/custom-domain.yaml \ -e /home/stack/templates/public-vip.yaml
novajoin을 사용하여 기존 배포에서 TLS-e(TLS-e)를 구현할 수 없습니다.
추가 리소스
2.4.5. Red Hat IdM(Identity Manager)에서 오버클라우드 등록 테스트
novajoin을 사용하여 IdM에 언더클라우드 및 오버클라우드 등록을 완료한 후 IdM에서 오버클라우드 노드를 검색하고 호스트 항목에 Keytab:True
가 포함되어 있는지 확인하여 등록에 성공했는지 테스트할 수 있습니다. 또한 오버클라우드 노드에 로그인하여 sssd
명령에서 IdM 사용자를 쿼리할 수 있는지 확인할 수 있습니다.
IdM에서 오버클라우드 노드를 찾고 host 항목에
Keytab:True
:$ ipa host-show overcloud-node-01 Host name: overcloud-node-01.lab.local Principal name: host/overcloud-node-01.lab.local@LAB.LOCAL Principal alias: host/overcloud-node-01.lab.local@LAB.LOCAL SSH public key fingerprint: <snip> Password: False Keytab: True Managed by: overcloud-node-01.lab.local
Overcloud 노드에 로그인하고
sssd
가 IdM 사용자를 쿼리할 수 있는지 확인합니다. 예를 들어 이름이susan
인 IdM 사용자를 쿼리하려면 다음을 수행합니다.$ getent passwd susan uid=1108400007(susan) gid=1108400007(bob) groups=1108400007(susan)
2.5. Red Hat IdM(Identity Manager) 서버 인증 정보 구성
OpenStack ID와 통합되도록 Red Hat IdM(Identity Manager)을 구성하려면 ID 서비스에서 사용할 LDAP 계정을 설정하고, Red Hat OpenStack 사용자의 사용자 그룹을 만들고 조회 계정의 암호를 설정합니다.
사전 요구 사항
- Red Hat IdM(Identity Manager)이 구성되어 작동하며.
- RHOSP(Red Hat OpenStack Platform)가 구성 및 작동합니다.
- DNS 이름 확인은 완전히 작동하며 모든 호스트가 적절하게 등록됩니다.
- IdM 인증 트래픽은 포트 636을 사용하여 LDAPS로 암호화됩니다.
- 권장 사항: 고가용성 또는 로드 밸런싱 솔루션으로 IdM을 구현하여 단일 장애 지점을 방지합니다.
절차
IdM 서버에서 이 절차를 수행합니다.
OpenStack ID 서비스에서 IdM LDAP 서비스를 쿼리하는 데 사용할 LDAP 조회 계정을 생성합니다.
# kinit admin # ipa user-add First name: OpenStack Last name: LDAP User [radministrator]: svc-ldap
참고생성된 후 이 계정의 암호 만료 설정을 검토합니다.
grp-openstack
이라는 RHOSP 사용자의 그룹을 생성합니다. 이 그룹의 멤버만 OpenStack ID에 할당된 권한을 가질 수 있습니다.# ipa group-add --desc="OpenStack Users" grp-openstack
svc-ldap
계정 암호를 설정하고grp-openstack
그룹에 추가합니다.# ipa passwd svc-ldap # ipa group-add-member --users=svc-ldap grp-openstack
svc-ldap
사용자로 로그인하고 메시지가 표시되면 암호를 변경합니다.# kinit svc-ldap
2.6. Red Hat IdM(Identity Manager) LDAPS 인증서 설치
OpenStack Identity(keystone)는 LDAPS 쿼리를 사용하여 사용자 계정의 유효성을 검사합니다. 이 트래픽을 암호화하기 위해 keystone은 keystone.conf
에서 정의한 인증서 파일을 사용합니다. LDAPS 인증서를 설치하려면 Red Hat IdM(Identity Manager) 서버에서 keystone이 해당 인증서를 참조할 수 있는 위치로 복사하고 인증서를 .crt에서.
pem
형식으로 변환합니다.
LDAP 인증에 여러 도메인을 사용하는 경우 Unable to retrieve authorized project(인증된 프로젝트를
검색할 수 없음) 또는 Peer의 Certificate 발행자가 인식되지 않는
다양한 오류가 표시될 수 있습니다. 이는 Keystone이 특정 도메인에 대해 잘못된 인증서를 사용하는 경우 발생할 수 있습니다. 이 문제를 해결하려면 모든 LDAPS 공개 키를 단일 .crt
번들로 병합하고 이 파일을 사용하도록 모든 keystone 도메인을 구성합니다.
사전 요구 사항
- IdM 서버 자격 증명이 구성되어 있습니다.
절차
IdM 환경에서 LDAPS 인증서를 찾습니다. 이 파일은
/etc/openldap/ldap.conf를 사용하여 찾을 수 있습니다.
TLS_CACERT /etc/ipa/ca.crt
keystone 서비스를 실행하는 컨트롤러 노드에 파일을 복사합니다. 예를 들어
scp
명령은ca.crt
파일을node.lab.local에 복사합니다.
# scp /etc/ipa/ca.crt root@node.lab.local:/root/
ca.crt
파일을 인증서 디렉터리에 복사합니다. keystone 서비스가 인증서에 액세스하는 데 사용할 위치입니다.# cp ca.crt /etc/pki/ca-trust/source/anchors
선택 사항:
ldapsearch
와 같은 진단 명령을 실행해야 하는 경우 RHEL 인증서 저장소에 인증서를 추가해야 합니다.3. 컨트롤러 노드에서
.crt를.
pem
형식으로 변환합니다.# openssl x509 -in ca.crt -out ca.pem -outform PEM
컨트롤러 노드에
.pem
을 설치합니다. 예를 들어 Red Hat Enterprise Linux에서는 다음과 같습니다.# cp ca.pem /etc/pki/ca-trust/source/anchors/ # update-ca-trust
2.7. 도메인별 LDAP 백엔드를 사용하도록 director 구성
하나 이상의 LDAP 백엔드를 사용하도록 director를 구성하려면 heat 템플릿에서 KeystoneLDAPDomainEnable
플래그를 true
로 설정하고 각 LDAP 백엔드에 대한 정보로 환경 파일을 설정합니다. 그런 다음 director는 각 keystone 도메인에 별도의 LDAP 백엔드를 사용합니다.
도메인 구성 파일의 기본 디렉토리는 /etc/keystone/domains/
로 설정됩니다. 필수 경로를 keystone::domain_config_directory
hiera 키로 설정하고 환경 파일 내에 ExtraConfig
매개변수로 추가하여 이 경로를 재정의할 수 있습니다.
절차
-
배포에 사용할 heat 템플릿에서
KeystoneLDAPDomainEnable
플래그를true
로 설정합니다. 이렇게 하면identity
구성 그룹 내의 keystone에domain_specific_drivers_enabled
옵션이 구성됩니다. -
tripleo-heat-templates
에서KeystoneLDAPBackendConfigs
매개변수를 설정하여 LDAP 백엔드 구성 사양을 추가합니다. 그런 다음 필요한 LDAP 옵션을 지정할 수 있습니다. keystone_domain_specific_ldap_backend.yaml
환경 파일의 사본을 생성합니다.$ cp /usr/share/openstack-tripleo-heat-templates/environments/services/keystone_domain_specific_ldap_backend.yaml /home/stack/templates/
/home/stack/templates/keystone_domain_specific_ldap_backend.yaml
환경 파일을 편집하고 배포에 맞게 값을 설정합니다. 예를 들어 이 매개변수는testdomain
이라는 keystone 도메인에 대한 LDAP 구성을 생성합니다.parameter_defaults: KeystoneLDAPDomainEnable: true KeystoneLDAPBackendConfigs: testdomain: url: ldaps://192.0.2.250 user: cn=openstack,ou=Users,dc=director,dc=example,dc=com password: RedactedComplexPassword suffix: dc=director,dc=example,dc=com user_tree_dn: ou=Users,dc=director,dc=example,dc=com user_filter: "(memberOf=cn=OSuser,ou=Groups,dc=director,dc=example,dc=com)" user_objectclass: person user_id_attribute: cn
참고keystone_domain_specific_ldap_backend.yaml
환경 파일에는 더 이상 사용되지 않는 다음과 같은 쓰기 매개변수가 포함되어 있습니다.-
user_allow_create
-
user_allow_update
-
user_allow_delete
이러한 매개 변수의 값은 배포에 영향을 미치지 않으며 안전하게 제거할 수 있습니다.
-
선택 사항: 환경 파일에 더 많은 도메인을 추가합니다. 예를 들면 다음과 같습니다.
KeystoneLDAPBackendConfigs: domain1: url: ldaps://domain1.example.com user: cn=openstack,ou=Users,dc=director,dc=example,dc=com password: RedactedComplexPassword ... domain2: url: ldaps://domain2.example.com user: cn=openstack,ou=Users,dc=director,dc=example,dc=com password: RedactedComplexPassword ...
그러면 domain
1 및 domain
2
라는 두 개의 도메인이 생성됩니다. 각 도메인은 자체 구성과 다른 LDAP 도메인을 갖게 됩니다.
2.8. OpenStack ID 도메인에 대한 admin 사용자 액세스 권한 부여
admin
사용자가 OpenStack ID(keystone) 도메인에 액세스하고 Domain
(도메인) 탭을 보려면 도메인 및 admin
사용자의 ID를 가져온 다음 도메인의 사용자에게 admin
역할을 할당합니다.
이 권한은 OpenStack admin 계정에 외부 서비스 도메인에 대한 권한을 부여하지 않습니다. 이 경우 domain 이라는 용어는 keystone 도메인의 OpenStack 사용을 나타냅니다.
절차
이 절차에서는 LAB
도메인을 사용합니다. 도메인 이름을 구성 중인 도메인의 실제 이름으로 바꿉니다.
LAB
도메인의 ID를 가져옵니다.$ openstack domain show LAB +---------+----------------------------------+ | Field | Value | +---------+----------------------------------+ | enabled | True | | id | 6800b0496429431ab1c4efbb3fe810d4 | | name | LAB | +---------+----------------------------------+
기본
도메인에서admin
사용자의 ID를 가져옵니다.$ openstack user list --domain default | grep admin | 3d75388d351846c6a880e53b2508172a | admin |
admin
역할의 ID를 가져옵니다.$ openstack role list
출력은 통합 중인 외부 서비스에 따라 달라집니다.
Active Directory 도메인 서비스(AD DS):
+----------------------------------+-----------------+ | ID | Name | +----------------------------------+-----------------+ | 01d92614cd224a589bdf3b171afc5488 | admin | | 034e4620ed3d45969dfe8992af001514 | member | | 0aa377a807df4149b0a8c69b9560b106 | ResellerAdmin | | 9369f2bf754443f199c6d6b96479b1fa | heat_stack_user | | cfea5760d9c948e7b362abc1d06e557f | reader | | d5cb454559e44b47aaa8821df4e11af1 | swiftoperator | | ef3d3f510a474d6c860b4098ad658a29 | service | +----------------------------------+-----------------+
Red Hat IdM(Identity Manager):
+----------------------------------+---------------+ | ID | Name | +----------------------------------+---------------+ | 544d48aaffde48f1b3c31a52c35f01f9 | SwiftOperator | | 6d005d783bf0436e882c55c62457d33d | ResellerAdmin | | 785c70b150ee4c778fe4de088070b4cf | admin | | 9fe2ff9ee4384b1894a90878d3e92bab | _member_ | +----------------------------------+---------------+
도메인 및 admin ID를 사용하여
admin
사용자를 keystoneLAB
도메인의admin
역할에 추가하는 명령을 구성합니다.# openstack role add --domain 6800b0496429431ab1c4efbb3fe810d4 --user 3d75388d351846c6a880e53b2508172a 785c70b150ee4c778fe4de088070b4cf
2.9. Red Hat OpenStack Platform 프로젝트에 대한 외부 그룹 액세스 권한 부여
인증된 여러 사용자에게 RHOSP(Red Hat OpenStack Platform) 리소스에 대한 액세스 권한을 부여하려면 OpenStack 관리자가 프로젝트의 역할에 수동으로 각 사용자를 할당하지 않고 외부 사용자 관리 서비스에서 특정 그룹에 권한을 부여하여 RHOSP 프로젝트에 대한 액세스 권한을 부여할 수 있습니다. 결과적으로 이러한 그룹의 모든 구성원이 사전에 결정된 프로젝트에 액세스할 수 있습니다.
사전 요구 사항
외부 서비스 관리자가 다음 단계를 완료했는지 확인합니다.
-
grp-openstack-admin
이라는 그룹 만들기. -
grp-openstack-demo
라는 그룹 만들기. - 필요에 따라 이러한 그룹 중 하나에 RHOSP 사용자를 추가합니다.
-
사용자를 the
grp-openstack
그룹에 추가합니다.
-
-
OpenStack ID 도메인을 생성합니다. 이 절차에서는
LAB
도메인을 사용합니다. -
RHOSP 프로젝트를 생성하거나 선택합니다. 이 절차에서는
openstack project create --domain default --description "Demo Project" demo 명령으로
라는 프로젝트를 사용합니다.생성된
demo
절차
OpenStack ID 도메인에서 사용자 그룹 목록을 검색합니다.
# openstack group list --domain LAB
명령 출력은 통합 중인 외부 사용자 관리 서비스에 따라 다릅니다.
Active Directory 도메인 서비스(AD DS):
+------------------------------------------------------------------+---------------------+ | ID | Name | +------------------------------------------------------------------+---------------------+ | 185277be62ae17e498a69f98a59b66934fb1d6b7f745f14f5f68953a665b8851 | grp-openstack | | a8d17f19f464c4548c18b97e4aa331820f9d3be52654aa8094e698a9182cbb88 | grp-openstack-admin | | d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8 | grp-openstack-demo | +------------------------------------------------------------------+---------------------+
Red Hat IdM(Identity Manager):
+------------------------------------------------------------------+---------------------+ | ID | Name | +------------------------------------------------------------------+---------------------+ | 185277be62ae17e498a69f98a59b66934fb1d6b7f745f14f5f68953a665b8851 | grp-openstack | | a8d17f19f464c4548c18b97e4aa331820f9d3be52654aa8094e698a9182cbb88 | grp-openstack-admin | | d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8 | grp-openstack-demo | +------------------------------------------------------------------+---------------------+
역할 목록을 검색합니다.
# openstack role list
명령 출력은 통합 중인 외부 사용자 관리 서비스에 따라 다릅니다.
Active Directory 도메인 서비스(AD DS):
+----------------------------------+-----------------+ | ID | Name | +----------------------------------+-----------------+ | 01d92614cd224a589bdf3b171afc5488 | admin | | 034e4620ed3d45969dfe8992af001514 | member | | 0aa377a807df4149b0a8c69b9560b106 | ResellerAdmin | | 9369f2bf754443f199c6d6b96479b1fa | heat_stack_user | | cfea5760d9c948e7b362abc1d06e557f | reader | | d5cb454559e44b47aaa8821df4e11af1 | swiftoperator | | ef3d3f510a474d6c860b4098ad658a29 | service | +----------------------------------+-----------------+
Red Hat IdM(Identity Manager):
+----------------------------------+---------------+ | ID | Name | +----------------------------------+---------------+ | 0969957bce5e4f678ca6cef00e1abf8a | ResellerAdmin | | 1fcb3c9b50aa46ee8196aaaecc2b76b7 | admin | | 9fe2ff9ee4384b1894a90878d3e92bab | _member_ | | d3570730eb4b4780a7fed97eba197e1b | SwiftOperator | +----------------------------------+---------------+
이러한 역할 중 하나 이상에 추가하여 사용자 그룹에 RHOSP 프로젝트에 대한 액세스 권한을 부여합니다. 예를 들어, 통합 중인 외부 서비스에 따라 해당
그룹을
demo
프로젝트의 일반 사용자가 되도록 하려면 다음을 수행한 외부 서비스에 따라멤버
또는_member_
역할에 그룹을 추가해야 합니다.Active Directory 도메인 서비스(AD DS):
# openstack role add --project demo --group d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8 member
Red Hat IdM(Identity Manager):
$ openstack role add --project demo --group d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8 _member_
결과
사용자 이름과 암호를 입력하고 Domain
필드에 LAB
을 입력하여 대시보드에 로그인할 수
있습니다.
사용자에게 오류가 발생하면 오류: 컨테이너 목록을 검색할 수 없으며 컨테이너를 관리할 수 있어야 하는 경우
SwiftOperator
역할에 추가해야 합니다.
2.10. Red Hat OpenStack Platform 프로젝트에 대한 외부 사용자에게 액세스 권한 부여
OpenStack 리소스에 대한 the grp-openstack
그룹에서 인증된 특정 사용자에게 부여하려면 해당 사용자에게 RHOSP(Red Hat OpenStack Platform) 프로젝트에 대한 직접 액세스 권한을 부여할 수 있습니다. 그룹에 대한 액세스 권한을 부여하지 않고 개별 사용자에게 액세스 권한을 부여하려는 경우 이 프로세스를 사용합니다.
사전 요구 사항
외부 서비스 관리자가 다음 단계를 완료했는지 확인합니다.
-
grp-openstack
그룹에 RHOSP 사용자를 추가합니다. -
OpenStack ID 도메인 생성. 이 절차에서는
LAB
도메인을 사용합니다.
-
-
RHOSP 프로젝트를 생성하거나 선택합니다. 이 절차에서는
openstack project create --domain default --description "Demo Project" demo 명령으로
라는 프로젝트를 사용합니다.생성된
demo
절차
OpenStack ID 도메인에서 사용자 목록을 검색합니다.
# openstack user list --domain LAB +------------------------------------------------------------------+----------------+ | ID | Name | +------------------------------------------------------------------+----------------+ | 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e | user1 | | 12c062faddc5f8b065434d9ff6fce03eb9259537c93b411224588686e9a38bf1 | user2 | | afaf48031eb54c3e44e4cb0353f5b612084033ff70f63c22873d181fdae2e73c | user3 | | e47fc21dcf0d9716d2663766023e2d8dc15a6d9b01453854a898cabb2396826e | user4 | +------------------------------------------------------------------+----------------+
역할 목록을 검색합니다.
# openstack role list
명령 출력은 통합 중인 외부 사용자 관리 서비스에 따라 다릅니다.
Active Directory 도메인 서비스(AD DS):
+----------------------------------+-----------------+ | ID | Name | +----------------------------------+-----------------+ | 01d92614cd224a589bdf3b171afc5488 | admin | | 034e4620ed3d45969dfe8992af001514 | member | | 0aa377a807df4149b0a8c69b9560b106 | ResellerAdmin | | 9369f2bf754443f199c6d6b96479b1fa | heat_stack_user | | cfea5760d9c948e7b362abc1d06e557f | reader | | d5cb454559e44b47aaa8821df4e11af1 | swiftoperator | | ef3d3f510a474d6c860b4098ad658a29 | service | +----------------------------------+-----------------+
Red Hat IdM(Identity Manager):
+----------------------------------+---------------+ | ID | Name | +----------------------------------+---------------+ | 0969957bce5e4f678ca6cef00e1abf8a | ResellerAdmin | | 1fcb3c9b50aa46ee8196aaaecc2b76b7 | admin | | 9fe2ff9ee4384b1894a90878d3e92bab | _member_ | | d3570730eb4b4780a7fed97eba197e1b | SwiftOperator | +----------------------------------+---------------+
이러한 역할 중 하나 이상에 추가하여 RHOSP 프로젝트에 대한 액세스 권한을 부여합니다. 예를 들어,
user1
이demo
프로젝트의 일반 사용자가 되도록 하려면 통합 중인 외부 서비스에 따라member
또는_member_
역할에 추가합니다.Active Directory 도메인 서비스(AD DS):
# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e member
Red Hat IdM(Identity Manager):
# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e _member_
user1
이demo
프로젝트의 관리 사용자가 되도록 하려면 사용자를admin
역할에 추가합니다.# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e admin
결과
user1
사용자는 외부 사용자 이름 및 암호를 입력하고 Domain
(도메인) 필드에 LAB
을 입력하여 대시보드에 로그인할 수 있습니다.
사용자에게 오류가 발생하면 오류: 컨테이너 목록을 검색할 수 없으며 컨테이너를 관리할 수 있어야 하는 경우
SwiftOperator
역할에 추가해야 합니다.
2.11. OpenStack ID 도메인 및 사용자 목록 보기
openstack domain list
명령을 사용하여 사용 가능한 항목을 나열합니다. ID 서비스에서 여러 도메인을 구성하면 대시보드 로그인 페이지에서 새 Domain (도메인) 필드가 활성화됩니다. 사용자는 로그인 자격 증명과 일치하는 도메인을 입력해야 합니다.
통합을 완료한 후 Default
도메인 또는 새로 생성된 keystone 도메인에서 새 프로젝트를 생성할지 여부를 결정해야 합니다. 워크플로와 사용자 계정을 관리하는 방법을 고려해야 합니다. 가능한 경우 Default
도메인을 내부 도메인으로 사용하여 서비스 계정 및 admin
프로젝트를 관리하고 외부 사용자를 별도의 도메인에 유지합니다.
이 예에서 외부 계정은 LAB
도메인을 지정해야 합니다. admin
과 같은 기본 제공 keystone 계정은 Default
를 도메인으로 지정해야 합니다.
절차
도메인 목록을 표시합니다.
# openstack domain list +----------------------------------+---------+---------+----------------------------------------------------------------------+ | ID | Name | Enabled | Description | +----------------------------------+---------+---------+----------------------------------------------------------------------+ | 6800b0496429431ab1c4efbb3fe810d4 | LAB | True | | | default | Default | True | Owns users and projects available on Identity API v2. | +----------------------------------+---------+---------+----------------------------------------------------------------------+
특정 도메인의 사용자 목록을 표시합니다. 이 명령은
--domain LAB
을 지정하고grp-openstack
그룹의 멤버인 LAB 도메인에 사용자를 반환합니다.# openstack user list --domain LAB
기본 제공 keystone 계정을 표시하려면
--domain Default
를 추가할 수도 있습니다.# openstack user list --domain Default
2.12. 관리자가 아닌 사용자의 자격 증명 파일 생성
OpenStack ID에 대한 사용자 및 도메인을 구성한 후 관리자 이외의 사용자에 대한 자격 증명 파일을 만들어야 할 수 있습니다.
절차
관리자가 아닌 사용자의 자격 증명(RC) 파일을 만듭니다. 이 예에서는 파일에서
user1
사용자를 사용합니다.$ cat overcloudrc-v3-user1 # Clear any old environment that may conflict. for key in $( set | awk '{FS="="} /^OS_/ {print $1}' ); do unset $key ; done export OS_USERNAME=user1 export NOVA_VERSION=1.1 export OS_PROJECT_NAME=demo export OS_PASSWORD=RedactedComplexPassword export OS_NO_CACHE=True export COMPUTE_API_VERSION=1.1 export no_proxy=,10.0.0.5,192.168.2.11 export OS_CLOUDNAME=overcloud export OS_AUTH_URL=https://10.0.0.5:5000/v3 export OS_AUTH_TYPE=password export PYTHONWARNINGS="ignore:Certificate has no, ignore:A true SSLContext object is not available" export OS_IDENTITY_API_VERSION=3 export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=LAB
2.13. 외부 사용자 관리 서비스로 OpenStack Identity 통합 테스트
OpenStack Identity(keystone)가 AD DS(Active Directory Domain Service)와 성공적으로 통합되었는지 테스트하려면 대시보드 기능에 대한 사용자 액세스를 테스트합니다.
사전 요구 사항
- AD(Active Directory) 또는 Red Hat IdM(Identity Manager)과 같은 외부 사용자 관리 서비스와 통합
절차
-
외부 사용자 관리 서비스에서 test 사용자를 생성하고 사용자를
grp-openstack
그룹에 추가합니다. -
Red Hat OpenStack Platform에서
demo
프로젝트의_member_
역할에 사용자를 추가합니다. - AD 테스트 사용자의 자격 증명을 사용하여 대시보드에 로그인합니다.
- 각 탭을 클릭하여 오류 메시지 없이 성공적으로 표시되는지 확인합니다.
- 대시보드를 사용하여 테스트 인스턴스를 구축합니다.
이러한 단계에 문제가 발생하면 admin
계정으로 대시보드에 로그인하고 해당 사용자로 후속 단계를 수행합니다. 테스트에 성공하면 OpenStack이 여전히 예상대로 작동 중이며 OpenStack ID와 Active Directory의 통합 설정에 문제가 있음을 나타냅니다.
2.14. Red Hat IdM(Identity Manager) 통합 문제 해결
Red Hat IdM(Identity Manager)과 OpenStack Identity 통합을 사용할 때 오류가 발생하면 LDAP 연결을 테스트하거나 인증서 신뢰 구성을 테스트해야 할 수 있습니다. LDAPS 포트에 액세스할 수도 있습니다.
오류 유형 및 위치에 따라 이 절차의 관련 단계만 수행합니다.
절차
IdM 서버에 대한 테스트 쿼리를 원격으로 수행하도록
ldapsearch
명령을 사용하여 LDAP 연결을 테스트합니다. 여기에서 성공적인 결과는 네트워크 연결이 작동 중이며 IdM 서비스가 작동 중임을 나타냅니다. 이 예제에서는 포트636
의 서버idm.lab.local
에 대해 테스트 쿼리가 수행됩니다.# ldapsearch -D "cn=directory manager" -H ldaps://idm.lab.local:636 -b "dc=lab,dc=local" -s sub "(objectclass=*)" -w RedactedComplexPassword
참고ldapsearch
는openldap-clients
패키지의 일부입니다.# dnf install openldap-clients를 사용하여 설치할 수 있습니다
.nc
명령을 사용하여 LDAPS 포트636
에 원격으로 액세스할 수 있는지 확인합니다. 이 예제에서는 서버idm.lab.local
에 대해 프로브를 수행합니다.ctrl-c
를 눌러 프롬프트를 종료합니다.# nc -v idm.lab.local 636 Ncat: Version 6.40 ( http://nmap.org/ncat ) Ncat: Connected to 192.168.200.10:636. ^C
연결을 설정하지 못하면 방화벽 구성 문제를 나타낼 수 있습니다.