ID 서비스와의 통합
Active Directory, IdM 또는 일반 LDAP를 외부 인증 백엔드로 사용
초록
머리말 링크 복사링크가 클립보드에 복사되었습니다!
ID 서비스(코드 이름 keystone)는 Red Hat OpenStack Platform 8에 대한 인증 및 권한 부여를 제공합니다.
이 가이드에서는 ID 서비스를 Microsoft Active Directory Domain Service(AD DS) 및 Red Hat IdM(Identity Management)과 통합하는 방법을 설명합니다.
1장. Active Directory 통합 링크 복사링크가 클립보드에 복사되었습니다!
이 장에서는 ID 서비스(keystone)를 Active Directory 도메인 서비스와 통합하는 방법을 설명합니다. 이 사용 사례에서 ID 서비스는 특정 AD DS(Active Directory Domain Services) 사용자를 인증하는 동시에 ID 서비스 데이터베이스에서 권한 부여 설정 및 중요한 서비스 계정을 유지합니다. 결과적으로 ID 서비스에는 사용자 계정 인증을 위해 AD DS에 대한 읽기 전용 액세스 권한이 있으며 인증된 계정에 할당된 권한에 대한 관리를 유지합니다.
1.1. 주요 용어 링크 복사링크가 클립보드에 복사되었습니다!
- 인증 - 암호를 사용하여 사용자가 있다고 요청하는지 확인합니다.
- 권한 부여 - 인증된 사용자에게 액세스하려는 리소스에 대한 적절한 권한이 있는지 확인합니다.
- domain - 이 용어는 AD DS 도메인과 동일하지 않으며 대신 사용자, 그룹 및 프로젝트 파티셔닝을 위해 ID 서비스에 구성된 추가 네임스페이스를 나타냅니다. 이러한 별도의 도메인은 다른 LDAP 또는 AD DS 환경에서 사용자를 인증하도록 구성할 수 있습니다.
1.2. 가정 링크 복사링크가 클립보드에 복사되었습니다!
이 예제 배포에서는 다음과 같은 가정을 합니다.
- Active Directory 도메인 서비스가 구성 및 작동합니다.
- Red Hat OpenStack Platform은 구성 및 운영됩니다.
- DNS 이름 확인은 완전하며 모든 호스트가 적절하게 등록됩니다.
- AD DS 인증 트래픽은 포트 636을 사용하여 LDAPS로 암호화됩니다.
다중 도메인 대시보드 구성은 이 버전의 Red Hat OpenStack Platform에서 지원되지 않습니다. 결과적으로 이 가이드에서는 단일 도메인에 대한 대시보드 구성만 설명합니다.
1.3. 영향을 미치는 정책 링크 복사링크가 클립보드에 복사되었습니다!
이러한 단계를 통해 AD DS 사용자는 OpenStack에 인증하고 리소스에 액세스할 수 있습니다. OpenStack 서비스 계정(예: keystone 및 glance) 및 권한 관리(권한, 역할, 프로젝트)는 ID 서비스 데이터베이스에 남아 있습니다. 권한 및 역할은 ID 서비스 관리 도구를 사용하여 AD DS 계정에 할당됩니다.
1.3.1. 고가용성 옵션 링크 복사링크가 클립보드에 복사되었습니다!
이 구성은 단일 Active Directory 도메인 컨트롤러의 가용성에 따라 종속성을 생성합니다. 프로젝트 사용자는 ID 서비스를 AD 도메인 컨트롤러에 인증할 수 없는 경우 영향을 받습니다. 이 위험을 관리하는 데 여러 옵션을 사용할 수 있습니다. 예를 들어 개별 AD 도메인 컨트롤러가 아닌 DNS 별칭 또는 로드 밸런싱 어플라이언스를 쿼리하도록 ID 서비스를 구성할 수 있습니다. 다른 도메인 컨트롤러를 쿼리하도록 keystone을 구성할 수도 있습니다. 하나는 사용할 수 없게 됩니다. 자세한 내용은 1.13절. “고가용성 구성”를 참조하십시오.
1.4. 중단 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
- AD DS 백엔드를 추가하려면 ID 서비스를 다시 시작해야 합니다.
- keystone v3으로 전환하려면 모든 노드의 Compute 서비스를 다시 시작해야 합니다.
- AD DS에서 계정이 생성될 때까지 사용자가 대시보드에 액세스할 수 없습니다. 다운타임을 줄이려면 이러한 변경 전에 AD DS 계정을 미리 계획하는 것이 좋습니다.
1.5. 방화벽 구성 링크 복사링크가 클립보드에 복사되었습니다!
방화벽이 AD DS와 OpenStack 간의 트래픽을 필터링하는 경우 다음 포트를 통한 액세스를 허용해야 합니다.
| 소스 | 대상 | 유형 | 포트 |
|---|---|---|---|
| OpenStack Controller 노드 | Active Directory 도메인 컨트롤러 | LDAPS | TCP 636 |
1.6. Active Directory 도메인 서비스 구성 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션에서는 Active Directory 관리자가 수행해야 하는 작업에 대해 설명합니다.
| Task | 세부 정보 |
| 서비스 계정을 생성합니다. |
서비스 계정에 대한 이름 지정 규칙에 따라 이름이 지정될 수 있습니다(예: |
| 사용자 그룹을 생성합니다. |
사용자가 OpenStack에 액세스해야 하는 경우 해당 사용자가 이 그룹의 멤버여야 합니다. 사용자 그룹에 대한 이름 지정 규칙에 따라 이름이 지정될 수 있습니다(예: |
| 프로젝트 그룹을 생성합니다. |
각 OpenStack 프로젝트에는 해당 AD 그룹이 필요합니다. 예를 들어 |
| 서비스 계정을 구성합니다. |
서비스 계정 |
| LDAPS 공개 키를 내보냅니다. |
공개 키(개인 키가 아님)를 |
| 이 키를 OpenStack 관리자에게 보냅니다. | OpenStack 관리자는 이 키를 사용하여 OpenStack과 Active Directory 간의 LDAPS 통신을 암호화합니다. |
| AD DS 도메인의 NetBIOS 이름을 검색합니다. | OpenStack 관리자는 이 이름을 Keystone 도메인에 사용하므로 환경 간에 도메인 이름을 일관되게 지정할 수 있습니다. |
예를 들어 다음 절차에서는 Active Directory 도메인 컨트롤러에서 실행되는 PowerShell 명령을 보여줍니다.
1. 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'
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'
2. 이 계정의 암호를 설정한 다음 활성화합니다. AD 도메인의 복잡성 요구 사항을 준수하는 암호를 지정하라는 메시지가 표시됩니다.
PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount
PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount
3. grp-openstack 이라는 OpenStack 사용자를 위한 그룹을 만듭니다.
PS C:\> NEW-ADGroup -name "grp-openstack" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"
PS C:\> NEW-ADGroup -name "grp-openstack" -groupscope Global -path "OU=labUsers,DC=lab,DC=local"
4. 프로젝트 그룹을 생성합니다.
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"
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"
5. svc-ldap 사용자를 grp-openstack 그룹에 추가합니다.
PS C:\> ADD-ADGroupMember "grp-openstack" -members "svc-ldap"
PS C:\> ADD-ADGroupMember "grp-openstack" -members "svc-ldap"
6. AD 도메인 컨트롤러에서 인증서 MMC 를 사용하여 LDAPS 인증서의 공개 키(개인 키가 아님)를 DER 인코딩 x509 .cer 파일로 내보냅니다. 이 파일을 OpenStack 관리자에게 보냅니다.
7. AD DS 도메인의 NetBIOS 이름을 검색합니다.
PS C:\> Get-ADDomain | select NetBIOSName NetBIOSName ----------- LAB
PS C:\> Get-ADDomain | select NetBIOSName
NetBIOSName
-----------
LAB
이 값을 OpenStack 관리자에게 보냅니다.
1.7. LDAPS 인증서 구성 링크 복사링크가 클립보드에 복사되었습니다!
1. LDAPS 공개 키를 OpenStack Identity(keystone)를 실행하는 노드에 복사하고 .cer 를 .pem 으로 변환합니다. 이 예에서는 addc.lab.local.cer 라는 인증서 파일을 사용합니다.
openssl x509 -inform der -in addc.lab.local.cer -out addc.lab.local.pem
# openssl x509 -inform der -in addc.lab.local.cer -out addc.lab.local.pem
2. OpenStack 컨트롤러에 .pem을 설치합니다. 예를 들어 Red Hat Enterprise Linux에서는 다음과 같습니다.
cp addc.lab.local.pem /etc/pki/ca-trust/source/anchors/ update-ca-trust
# cp addc.lab.local.pem /etc/pki/ca-trust/source/anchors/
# update-ca-trust
3. .pem을 .crt로 변환하고 인증서 디렉터리에 복사합니다.
openssl x509 -outform der -in addc.lab.local.pem -out addc.lab.local.crt cp addc.lab.local.crt /etc/ssl/certs/
# openssl x509 -outform der -in addc.lab.local.pem -out addc.lab.local.crt
# cp addc.lab.local.crt /etc/ssl/certs/
1.8. ID 서비스 구성 링크 복사링크가 클립보드에 복사되었습니다!
이러한 단계는 AD DS와의 통합을 위해 ID 서비스를 준비합니다.
1.8.1. keystone v3에 대한 명령행 액세스 활성화 링크 복사링크가 클립보드에 복사되었습니다!
명령줄에서 ID 서비스 도메인을 관리하려면 keystone v3에 대한 액세스를 활성화해야 합니다.
keystone 서비스를 실행하는 컨트롤러에서 다음 절차를 수행합니다.
1. 기존 환경 변수 파일의 사본을 생성합니다. director 기반 배포에서는 overcloudrc:라고 합니다.
cp overcloudrc overcloudrc-v3
$ cp overcloudrc overcloudrc-v3
2. 새 overcloudrc-v3 파일을 편집합니다.
-
OS_AUTH_URL을 v2.0 에서 v3 로 변경합니다. 예를 들면 다음과 같습니다.
export OS_AUTH_URL=https://controllerIP:5000/v3/
export OS_AUTH_URL=https://controllerIP:5000/v3/
-
overcloudrc-v3하단에 다음 항목을 추가합니다.
export OS_IDENTITY_API_VERSION=3 export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=Default
export OS_IDENTITY_API_VERSION=3
export OS_PROJECT_DOMAIN_NAME=Default
export OS_USER_DOMAIN_NAME=Default
3. 파일을 가져와 현재 명령행 세션에 대해 다음 옵션을 활성화합니다.
source overcloudrc-v3
$ source overcloudrc-v3
1.8.2. 컨트롤러 구성 링크 복사링크가 클립보드에 복사되었습니다!
keystone 서비스를 실행하는 컨트롤러에서 다음 절차를 수행합니다. 여러 컨트롤러에서 HA 환경을 실행하는 경우 각 컨트롤러에서 다음 단계를 수행해야 합니다.
1. SELinux를 구성합니다.
setsebool -P authlogin_nsswitch_use_ldap=on
# setsebool -P authlogin_nsswitch_use_ldap=on
출력에는 이와 유사한 메시지가 포함될 수 있습니다. 무시될 수 있습니다.
Full path required for exclude: net:[4026532245].
Full path required for exclude: net:[4026532245].
2. 도메인 디렉터리를 생성합니다.
mkdir /etc/keystone/domains/ chown keystone /etc/keystone/domains/
# mkdir /etc/keystone/domains/
# chown keystone /etc/keystone/domains/
3. 여러 백엔드를 사용하도록 ID 서비스를 구성합니다.
yum install 할 수 있습니다.
crudini 를 사용하여 crudini를 설치해야
crudini --set /etc/keystone/keystone.conf identity domain_specific_drivers_enabled true crudini --set /etc/keystone/keystone.conf identity domain_config_dir /etc/keystone/domains crudini --set /etc/keystone/keystone.conf assignment driver sql
# crudini --set /etc/keystone/keystone.conf identity domain_specific_drivers_enabled true
# crudini --set /etc/keystone/keystone.conf identity domain_config_dir /etc/keystone/domains
# crudini --set /etc/keystone/keystone.conf assignment driver sql
Red Hat OpenStack Platform director를 사용하는 경우 /etc/keystone/keystone.conf 는 Puppet에서 관리합니다. 결과적으로 openstack overcloud deploy 프로세스를 실행할 때마다 추가한 사용자 정의 구성을 덮어쓸 수 있었습니다. 따라서 이 구성을 매번 수동으로 다시 추가해야 할 수 있습니다. 향후 director 릴리스에는 배포 후 스크립트를 사용하여 이러한 설정을 자동으로 다시 적용할 수 있는 Puppet 매개변수가 포함될 것으로 예상됩니다.
4. 추가 백엔드를 구성합니다.
이 예제에서 LAB 는 ID 서비스 도메인으로 사용할 NetBIOS 이름입니다.
a. AD DS 통합을 위한 keystone 도메인을 만듭니다.
이전에 검색한 NetBIOS 이름 값을 도메인 이름으로 사용합니다. 이 방법을 사용하면 로그인 프로세스 중에 사용자에게 일관된 도메인 이름을 표시할 수 있습니다. 예를 들어 NetBIOS 이름이 LAB 인 경우:
openstack domain create LAB
# openstack domain create LAB
이 명령을 사용할 수 없는 경우 # source overcloudrc-v3 를 실행하여 명령행 세션에 keystone v3을 활성화했는지 확인합니다.
b. 구성 파일을 생성합니다.
AD DS 백엔드를 추가하려면 /etc/keystone/domains/keystone.LAB.conf 라는 새 파일에 LDAP 설정을 입력합니다(여기서 LAB 는 이전에 검색한 NetBIOS 이름임). AD DS 배포에 맞게 아래의 샘플 설정을 편집해야 합니다.
각 설정에 대한 설명:
| 설정 | 설명 |
|---|---|
|
|
인증에 사용할 AD 도메인 컨트롤러입니다. LDAPS 포트 |
|
|
LDAP 쿼리에 사용할 AD 계정의 고유 이름입니다. 예를 들어 |
|
| 위에서 사용한 AD 계정의 일반 텍스트 암호입니다. |
|
|
AD 도메인 의 고유 이름입니다. |
|
| OpenStack 계정이 포함된 OU( 조직 단위 )입니다. |
|
|
LDAP 사용자의 유형을 정의합니다. AD의 경우 |
|
|
ID 서비스에 제공된 사용자를 필터링합니다. 결과적으로 grp-openstack 그룹의 멤버만 ID 서비스에 정의된 권한을 가질 수 있습니다. 이 값을 사용하려면 그룹의 전체 고유 이름: |
|
| 사용자 ID에 사용할 AD 값을 매핑합니다. |
|
| 이름에 사용할 AD 값을 매핑합니다. |
|
| 사용자 이메일 주소에 사용할 AD 값을 매핑합니다. |
|
| 이 값을 비워 둡니다. |
|
| 계정이 활성화되어 있는지 확인하는 AD 설정입니다. |
|
| 계정이 활성화되어 있는지 확인하기 위해 확인할 값을 정의합니다. 부울이 반환되지 않을 때 사용됩니다. |
|
| 계정이 활성화되어 있음을 나타내는 AD 값입니다. |
|
| ID 서비스에서 무시해야 하는 사용자 속성을 정의합니다. |
|
|
keystone에는 읽기 전용 액세스 권한만 필요하므로 이 값을 |
|
|
keystone에는 읽기 전용 액세스 권한만 필요하므로 이 값을 |
|
|
keystone에는 읽기 전용 액세스 권한만 필요하므로 이 값을 |
|
| 그룹에 사용할 AD 값을 매핑합니다. |
|
| 사용자 그룹이 포함된 OU( 조직 단위 )입니다. |
|
| ID 서비스에 제공된 그룹을 필터링합니다. |
|
| 그룹 ID에 사용할 AD 값을 매핑합니다. |
|
| 그룹 이름에 사용할 AD 값을 매핑합니다. |
|
|
keystone에는 읽기 전용 액세스 권한만 필요하므로 이 값을 |
|
|
keystone에는 읽기 전용 액세스 권한만 필요하므로 이 값을 |
|
|
keystone에는 읽기 전용 액세스 권한만 필요하므로 이 값을 |
|
| TLS를 사용할지 여부를 정의합니다. STARTTLS 대신 LDAPS로 암호화하는 경우 이 작업을 비활성화해야 합니다. |
|
| .crt 인증서 파일의 경로를 지정합니다. |
|
|
|
|
|
|
6. 구성 파일의 소유권을 keystone 사용자로 변경합니다.
chown keystone /etc/keystone/domains/keystone.LAB.conf
# chown keystone /etc/keystone/domains/keystone.LAB.conf
7. 로그인 페이지에서 LAB keystone 도메인을 사용하도록 대시보드를 구성합니다. /etc/openstack-dashboard/local_settings:에 다음 행을 추가합니다.
다중 도메인 대시보드 구성은 이 버전의 Red Hat OpenStack Platform에서 지원되지 않습니다. 결과적으로 이 가이드에서는 단일 도메인에 대한 대시보드 구성만 설명합니다.
OPENSTACK_API_VERSIONS = {
"identity": 3
}
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'LAB'
OPENSTACK_API_VERSIONS = {
"identity": 3
}
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'LAB'
Red Hat OpenStack Platform director를 사용하는 경우 /etc/openstack-dashboard/local_settings 는 Puppet에서 관리합니다. 결과적으로 openstack overcloud deploy 프로세스를 실행할 때마다 추가한 사용자 정의 구성을 덮어쓸 수 있었습니다. 따라서 이 구성을 매번 수동으로 다시 추가해야 할 수 있습니다. 향후 director 릴리스에는 배포 후 스크립트를 사용하여 이러한 설정을 자동으로 다시 적용할 수 있는 Puppet 매개변수가 포함될 것으로 예상됩니다.
8. httpd 서비스를 다시 시작하여 변경 사항을 적용합니다.
systemctl restart httpd.service
# systemctl restart httpd.service
9. 도메인에 대한 admin 사용자에게 액세스 권한을 부여합니다.
OpenStack admin 계정에 실제 AD DS 도메인에 대한 권한은 부여되지 않습니다. 이 경우 domain이라는 용어는 OpenStack의 keystone 도메인 사용을 나타냅니다.
a. LAB 도메인의 ID 를 가져옵니다.
b. admin 사용자의 ID 값을 가져옵니다.
openstack user list --domain default | grep admin
# openstack user list --domain default | grep admin
| 3d75388d351846c6a880e53b2508172a | admin |
c. admin 역할의 ID 값을 가져옵니다.
d. 반환된 도메인 및 관리자 ID를 사용하여 admin 사용자를 keystone LAB 도메인의 admin 역할에 추가하는 명령을 구성합니다.
openstack role add --domain 6800b0496429431ab1c4efbb3fe810d4 --user 3d75388d351846c6a880e53b2508172a 785c70b150ee4c778fe4de088070b4cf
# openstack role add --domain 6800b0496429431ab1c4efbb3fe810d4 --user 3d75388d351846c6a880e53b2508172a 785c70b150ee4c778fe4de088070b4cf
10. 명령에 NetBIOS 이름을 추가하여 AD DS 도메인의 사용자 목록을 확인합니다.
재부팅 또는 서비스를 다시 시작한 후 LDAP를 쿼리할 수 있는 시간이 걸릴 수 있습니다.
openstack user list --domain LAB
# openstack user list --domain LAB
11. 로컬 ID 서비스 데이터베이스에서 서비스 계정을 확인합니다.
openstack user list --domain default
# openstack user list --domain default
1.8.3. keystone v3을 사용하도록 Compute 구성 링크 복사링크가 클립보드에 복사되었습니다!
Compute는 기본적으로 keystone v2.0을 사용하므로 다중 도메인 기능을 사용하려면 keystone v3을 사용하도록 구성해야 합니다.
1. 각 컴퓨팅 노드 및 컨트롤러에서 keystone_authtoken 값을 조정합니다.
crudini --set /etc/nova/nova.conf keystone_authtoken auth_version v3
# crudini --set /etc/nova/nova.conf keystone_authtoken auth_version v3
2. 컨트롤러에서 이러한 서비스를 다시 시작하여 변경 사항을 적용합니다.
systemctl restart openstack-nova-api.service openstack-nova-cert.service openstack-nova-conductor.service openstack-nova-consoleauth.service openstack-nova-novncproxy.service openstack-nova-scheduler.service
# systemctl restart openstack-nova-api.service openstack-nova-cert.service openstack-nova-conductor.service openstack-nova-consoleauth.service openstack-nova-novncproxy.service openstack-nova-scheduler.service
3. 각 컴퓨팅 노드에서 이 서비스를 다시 시작하여 변경 사항을 적용합니다.
systemctl restart openstack-nova-compute.service
# systemctl restart openstack-nova-compute.service
1.8.4. keystone v3을 사용하도록 블록 스토리지를 구성 링크 복사링크가 클립보드에 복사되었습니다!
keystone v3에 인증하도록 Block Storage(cinder)도 구성해야 합니다.
In /etc/cinder/cinder.conf:
[keystone_authtoken] auth_uri = https://controllerIP:5000/v3 auth_version = v3
[keystone_authtoken] auth_uri = https://controllerIP:5000/v3 auth_version = v3Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
auth_uri-controllerIP를 컨트롤러의 IP 주소로 바꿉니다. 배포에 컨트롤러가 두 개 이상 있는 경우 컨트롤러 IP 대신 keystone 엔드포인트 VIP를 사용해야 합니다.
-
1.8.5. Active Directory 그룹 멤버가 프로젝트에 액세스하도록 허용 링크 복사링크가 클립보드에 복사되었습니다!
인증된 사용자가 OpenStack 리소스에 액세스할 수 있도록 하려면 특정 Active Directory 그룹이 프로젝트에 대한 액세스 권한을 부여할 수 있도록 권한을 부여하는 것이 좋습니다. 이렇게 하면 OpenStack 관리자가 각 사용자를 프로젝트의 역할에 할당할 필요가 없습니다. 대신 Active Directory 그룹에는 프로젝트에서 역할이 부여됩니다. 결과적으로 이러한 Active Directory 그룹의 멤버인 Active Directory 사용자는 사전 결정된 프로젝트에 액세스할 수 있습니다.
개별 Active Directory 사용자의 권한을 수동으로 관리하려면 다음 섹션을 참조하십시오. 개별 Active Directory 사용자가 프로젝트에 액세스하도록 허용
이 섹션에서는 Active Directory 관리자가 이미 다음 단계를 완료했다고 가정합니다.
-
Active Directory에서
grp-openstack-admin이라는 그룹을 만듭니다. -
Active Directory에서
grp-openstack-demo라는 그룹을 만듭니다. - 필요에 따라 위의 그룹 중 하나에 Active Directory 사용자를 추가합니다.
-
grp-openstack그룹에 Active Directory 사용자를 추가합니다.
이 단계에서는 AD 그룹에 역할을 할당합니다. 그러면 그룹 멤버가 OpenStack 리소스에 액세스할 수 있는 권한이 있습니다.
1. AD 그룹 목록을 검색합니다.
2. 역할 목록을 검색합니다.
3. 이러한 역할 중 하나에 추가하여 Active Directory 그룹에 프로젝트에 대한 액세스 권한을 부여합니다. 예를 들어 grp-openstack-demo 그룹의 사용자가 demo 프로젝트의 일반 사용자가 되려면 해당 그룹을 member 역할에 추가해야 합니다.
openstack role add --project demo --group d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8 _member_
# openstack role add --project demo --group d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8 _member_
결과적으로 grp-openstack-demo 의 멤버는 AD DS 사용자 이름과 암호를 입력하여 대시보드에 로그인할 수 있습니다.
사용자가 "오류: 컨테이너 목록을 검색할 수 없음" 오류가 발생하고 컨테이너를 관리할 수 있어야 하는 경우 SwiftOperator 역할에 추가해야 합니다.
1.8.6. Active Directory 사용자가 프로젝트에 액세스할 수 있도록 허용 링크 복사링크가 클립보드에 복사되었습니다!
grp-openstack AD 그룹의 멤버인 AD DS 사용자에게는 대시보드의 프로젝트에 로그인할 수 있는 권한이 부여될 수 있습니다.
1. AD 사용자 목록을 검색합니다.
2. 역할 목록을 검색합니다.
3. 이러한 역할 중 하나에 추가하여 프로젝트에 대한 액세스 권한을 사용자에게 부여합니다. 예를 들어 user1 을 demo 프로젝트의 일반 사용자가 되도록 하려면 member 역할에 추가합니다.
openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e _member_
# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e _member_
또는 user1 이 demo 프로젝트의 관리 사용자가 되도록 하려면 admin 역할에 추가합니다.
openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e admin
# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e admin
결과적으로 user1 은 AD DS 사용자 이름과 암호를 입력하여 대시보드에 로그인할 수 있습니다.
사용자가 "오류: 컨테이너 목록을 검색할 수 없음" 오류가 발생하고 컨테이너를 관리할 수 있어야 하는 경우 SwiftOperator 역할에 추가해야 합니다.
1.9. 도메인 탭에 대한 액세스 권한 부여 링크 복사링크가 클립보드에 복사되었습니다!
admin 사용자가 Domain 탭을 볼 수 있도록 하려면 기본 도메인에서 admin 역할을 할당해야 합니다.
admin사용자의 UUID를 찾습니다.openstack user list | grep admin
$ openstack user list | grep admin | a6a8adb6356f4a879f079485dad1321b | admin |Copy to Clipboard Copied! Toggle word wrap Toggle overflow 기본도메인의admin역할을admin사용자에게 추가합니다.openstack role add --domain default --user a6a8adb6356f4a879f079485dad1321b admin
$ openstack role add --domain default --user a6a8adb6356f4a879f079485dad1321b adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow 결과적으로
admin사용자는 이제Domain탭을 볼 수 있습니다.
1.10. 새 프로젝트 생성 링크 복사링크가 클립보드에 복사되었습니다!
이러한 통합 단계를 완료한 후에는 새 프로젝트를 만들 때 Default 도메인에서 생성할지 또는 방금 생성한 keystone 도메인에 만들지 여부를 결정해야 합니다. 이 결정은 워크플로우와 사용자 계정 관리 방법을 통해 얻을 수 있습니다. Default 도메인은 서비스 계정 및 admin 프로젝트를 관리하는 데 사용되는 내부 도메인으로 간주할 수 있습니다. 분리를 위해 AD 지원 사용자를 별도의 keystone 도메인에 보관할 수 있습니다.
1.11. 명령줄 변경 링크 복사링크가 클립보드에 복사되었습니다!
특정 명령의 경우 해당 도메인을 지정해야 할 수 있습니다. 예를 들어 이 명령에 --domain LAB 을 추가하면 LAB 도메인( grp-openstack 그룹의 멤버임)에서 사용자를 반환합니다.
openstack user list --domain LAB
# openstack user list --domain LAB
--domain Default 를 추가하면 내장된 keystone 계정을 반환합니다.
openstack user list --domain Default
# openstack user list --domain Default
1.12. AD DS 통합 테스트 링크 복사링크가 클립보드에 복사되었습니다!
이 절차에서는 대시보드 기능에 대한 사용자 액세스를 테스트하여 AD DS 통합을 확인합니다.
1. AD에서 테스트 사용자를 만들고 사용자를 grp-openstack AD DS 그룹에 추가합니다.
2. 사용자를 demo 테넌트의 _member_ 역할에 추가합니다.
3. AD 테스트 사용자의 자격 증명을 사용하여 대시보드에 로그인합니다.
4. 각 탭을 클릭하여 오류 메시지 없이 성공적으로 표시되는지 확인합니다.
5. 대시보드를 사용하여 테스트 인스턴스를 빌드합니다.
이러한 단계에 문제가 발생하면 기본 제공 관리자 계정으로 3-5 단계를 수행하십시오. 성공한 경우 OpenStack이 여전히 예상대로 작동하고 있으며 AD Cryostat ID 통합 설정 내의 모든 위치에 문제가 있음을 보여줍니다. 1.15절. “문제 해결”을 참조하십시오.
1.13. 고가용성 구성 링크 복사링크가 클립보드에 복사되었습니다!
keystone v3을 활성화하면 해당 도메인의 구성 파일에 여러 AD 도메인 컨트롤러를 나열하여 이 구성을 고가용성으로 설정할 수 있습니다.
1. 두 번째 서버를 url 항목에 추가합니다. 예를 들어 keystone.LAB.conf 파일의 url 설정을 업데이트하면 ID 서비스가 모든 쿼리 트래픽을 목록의 첫 번째 도메인 컨트롤러로 보냅니다. addc.lab.local:
url = ldaps://addc.lab.local,ldaps://addc2.lab.local
url = ldaps://addc.lab.local,ldaps://addc2.lab.local
addc.lab.local 에 대한 쿼리가 사용할 수 없기 때문에 실패하는 경우 Identity Service는 list: addc2.lab.local 의 다음 서버를 쿼리합니다. 이 구성은 라운드 로빈 방식으로 쿼리를 수행하지 않으므로 부하 분산 솔루션으로 간주할 수 없습니다.
2. /etc/openldap/ldap.conf 에 네트워크 시간 초과를 설정합니다.
NETWORK_TIMEOUT 2
NETWORK_TIMEOUT 2
또한 컨트롤러와 도메인 컨트롤러 간에 방화벽이 구성된 경우 컨트롤러에서 패킷을 자동으로 삭제하도록 도메인 컨트롤러를 구성해서는 안 됩니다. 이렇게 하면 python-keystoneclient 가 중단을 올바르게 감지하고 목록의 다음 도메인 컨트롤러로 요청을 리디렉션할 수 있습니다.
쿼리가 목록의 두 번째 LDAP 서버로 리디렉션되는 동안 연결 지연이 발생할 수 있습니다. 첫 번째 서버에 대한 연결이 두 번째 연결을 시도하기 전에 먼저 시간 초과해야하기 때문입니다.
1.14. 관리자가 아닌 사용자에 대한 RC 파일 생성 링크 복사링크가 클립보드에 복사되었습니다!
관리자가 아닌 사용자에 대한 RC 파일을 생성해야 할 수도 있습니다. 예를 들면 다음과 같습니다.
1.15. 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
1.15.1. LDAP 연결 테스트 링크 복사링크가 클립보드에 복사되었습니다!
ldapsearch 를 사용하여 Active Directory 도메인 컨트롤러에 대해 원격으로 테스트 쿼리를 수행합니다. 여기에서 성공적인 결과는 네트워크 연결이 작동하고 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 -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 패키지의 일부입니다. # yum install openldap-clients를 사용하여 설치할 수 있습니다.
1.15.2. 인증서 신뢰 구성 테스트 링크 복사링크가 클립보드에 복사되었습니다!
Peer의 인증서 발급자가 인식되지 않는 경우 ldapsearch 를 사용하여 테스트하는 동안 TLS_CACERTDIR 경로가 올바르게 설정되어 있는지 확인합니다. 예를 들면 다음과 같습니다.
- /etc/openldap/ldap.conf
TLS_CACERTDIR /etc/openldap/certs
TLS_CACERTDIR /etc/openldap/certs
임시 해결 방법으로 인증서 유효성 검사를 비활성화하는 것이 좋습니다.
이 설정은 영구적으로 구성되지 않아야 합니다.
- /etc/openldap/ldap.conf
TLS_REQCERT allow
TLS_REQCERT allow
이 값을 설정한 후 ldapsearch 쿼리가 작동하는 경우 인증서 신뢰가 올바르게 구성되었는지 검토해야 할 수 있습니다.
1.15.3. 포트 액세스 테스트 링크 복사링크가 클립보드에 복사되었습니다!
nc 를 사용하여 LDAPS 포트 636에 원격으로 액세스할 수 있는지 확인합니다. 이 예에서는 서버 addc.lab.local 에 대해 프로브가 수행됩니다. ctrl-c를 눌러 프롬프트를 종료합니다.
nc -v addc.lab.local 636
# nc -v addc.lab.local 636
Ncat: Version 6.40 ( http://nmap.org/ncat )
Ncat: Connected to 192.168.200.10:636.
^C
연결을 설정하지 않으면 방화벽 구성 문제가 표시될 수 있습니다.
2장. Identity Management 통합 링크 복사링크가 클립보드에 복사되었습니다!
이 장에서는 ID 서비스(keystone)를 Red Hat Identity Management와 통합하는 방법을 설명합니다.
이 사용 사례에서 ID 서비스는 특정 Red Hat IdM(Identity Management) 사용자를 인증하는 동시에 ID 서비스 데이터베이스에 권한 부여 설정 및 중요한 서비스 계정을 유지합니다.
결과적으로 ID 서비스에는 사용자 계정 인증을 위해 IdM에 대한 읽기 전용 액세스 권한을 부여하는 동시에 인증된 계정에 할당된 권한에 대한 관리를 유지합니다.
2.1. 주요 용어 링크 복사링크가 클립보드에 복사되었습니다!
- 인증 - 암호를 사용하여 사용자가 있다고 요청하는지 확인합니다.
- 권한 부여 - 인증된 사용자에게 액세스하려는 시스템에 대한 적절한 권한이 있는지 확인합니다.
- domain - ID 서비스에 구성된 추가 백엔드를 나타냅니다. 예를 들어 외부 IdM 환경에서 사용자를 인증하도록 ID 서비스를 구성할 수 있습니다. 생성된 사용자 컬렉션은 도메인으로 간주할 수 있습니다.
2.2. 가정 링크 복사링크가 클립보드에 복사되었습니다!
이 예제 배포에서는 다음과 같은 가정을 합니다.
- Red Hat Identity Management는 구성 및 운영됩니다.
- Red Hat OpenStack Platform은 구성 및 운영됩니다.
- DNS 이름 확인은 완전하며 모든 호스트가 적절하게 등록됩니다.
다중 도메인 대시보드 구성은 이 버전의 Red Hat OpenStack Platform에서 지원되지 않습니다. 결과적으로 이 가이드에서는 단일 도메인에 대한 대시보드 구성만 설명합니다.
2.3. 영향을 미치는 정책 링크 복사링크가 클립보드에 복사되었습니다!
이러한 단계를 통해 IdM 사용자는 OpenStack에 인증하고 리소스에 액세스할 수 있습니다. OpenStack 서비스 계정(예: keystone 및 glance) 및 권한 관리(권한 및 역할)는 ID 서비스 데이터베이스에 남아 있습니다. 권한 및 역할은 ID 서비스 관리 툴을 사용하여 IdM 계정에 할당됩니다.
2.3.1. 고가용성 옵션 링크 복사링크가 클립보드에 복사되었습니다!
이 구성에서는 단일 IdM 서버의 가용성에 종속됩니다. ID 서비스가 IdM 서버에 인증할 수 없는 경우 프로젝트 사용자가 영향을 받습니다. 예를 들어 이 위험을 관리하는 데 사용할 수 있는 여러 옵션이 있습니다. 예를 들어 개별 IdM 서버가 아닌 DNS 별칭 또는 로드 밸런싱 어플라이언스를 쿼리하도록 keystone을 구성할 수 있습니다. 다른 IdM 서버를 쿼리하도록 keystone을 구성할 수도 있습니다. 자세한 내용은 2.11절. “고가용성 구성”를 참조하십시오.
2.4. 중단 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
- IdM 백엔드를 추가하려면 ID 서비스를 다시 시작해야 합니다.
- keystone v3 으로 전환하려면 모든 노드의 Compute 서비스를 다시 시작해야 합니다.
- IdM에서 계정이 생성될 때까지 사용자가 대시보드에 액세스할 수 없습니다. 다운타임을 줄이려면 이러한 변경 전에 IdM 계정을 미리 미리 생성하는 것이 좋습니다.
2.5. 방화벽 구성 링크 복사링크가 클립보드에 복사되었습니다!
방화벽이 IdM과 OpenStack 간의 트래픽을 필터링하는 경우 다음 포트를 통한 액세스를 허용해야 합니다.
| 소스 | 대상 | 유형 | 포트 |
|---|---|---|---|
| OpenStack Controller 노드 | Red Hat Identity Management | LDAPS | TCP 636 |
2.6. IdM 서버 구성 링크 복사링크가 클립보드에 복사되었습니다!
IdM 서버에서 다음 명령을 실행합니다.
1. LDAP 조회 계정을 생성합니다. 이 계정은 ID 서비스에서 IdM LDAP 서비스를 쿼리하는 데 사용됩니다.
kinit admin ipa user-add
# kinit admin
# ipa user-add
First name: OpenStack
Last name: LDAP
User [radministrator]: svc-ldap
생성된 계정의 암호 만료 설정을 검토합니다.
2. grp-openstack 이라는 OpenStack 사용자를 위한 그룹을 만듭니다. 이 그룹의 멤버만 OpenStack ID에 할당된 권한을 가질 수 있습니다.
ipa group-add --desc="OpenStack Users" grp-openstack
# ipa group-add --desc="OpenStack Users" grp-openstack
3. svc-ldap 계정 암호를 설정하고 grp-openstack 그룹에 추가합니다.
ipa passwd svc-ldap ipa group-add-member --users=svc-ldap grp-openstack
# ipa passwd svc-ldap
# ipa group-add-member --users=svc-ldap grp-openstack
2.7. LDAPS 인증서 구성 링크 복사링크가 클립보드에 복사되었습니다!
1. IdM 환경에서 LDAPS 인증서를 찾습니다. 이 파일은 /etc/openldap/ldap.conf:
TLS_CACERT /etc/ipa/ca.crt
TLS_CACERT /etc/ipa/ca.crt
2. 파일을 OpenStack Identity(keystone)를 실행하는 노드에 복사합니다. 예를 들어 이 명령은 scp 를 사용하여 ca.crt를 node.lab.local 이라는 컨트롤러 노드에 복사합니다.
scp /etc/ipa/ca.crt root@node.lab.local:/root/
scp /etc/ipa/ca.crt root@node.lab.local:/root/
3. 컨트롤러 노드에서 .crt를 .pem으로 변환합니다.
openssl x509 -in ca.crt -out ca.pem -outform PEM
# openssl x509 -in ca.crt -out ca.pem -outform PEM
4. OpenStack 컨트롤러에 .pem을 설치합니다. 예를 들어 Red Hat Enterprise Linux에서는 다음과 같습니다.
cp ca.pem /etc/pki/ca-trust/source/anchors/ update-ca-trust
# cp ca.pem /etc/pki/ca-trust/source/anchors/
# update-ca-trust
5. .crt를 인증서 디렉터리에 복사합니다.
cp ca.crt /etc/ssl/certs/
# cp ca.crt /etc/ssl/certs/
2.8. ID 서비스 구성 링크 복사링크가 클립보드에 복사되었습니다!
이 단계에서는 IdM과의 통합을 위해 ID 서비스를 준비합니다.
2.8.1. keystone v3에 대한 명령행 액세스 활성화 링크 복사링크가 클립보드에 복사되었습니다!
명령줄에서 ID 서비스 도메인을 관리하려면 keystone v3에 대한 액세스를 활성화해야 합니다.
keystone 서비스를 실행하는 컨트롤러에서 다음 절차를 수행합니다.
1. 기존 환경 변수 파일의 사본을 생성합니다. director 기반 배포에서는 overcloudrc:라고 합니다.
cp overcloudrc overcloudrc-v3
$ cp overcloudrc overcloudrc-v3
2. 새 overcloudrc-v3 파일을 편집합니다.
-
OS_AUTH_URL을 v2.0 에서 v3 로 변경합니다. 예를 들면 다음과 같습니다.
export OS_AUTH_URL=https://controllerIP:5000/v3/
export OS_AUTH_URL=https://controllerIP:5000/v3/
-
overcloudrc-v3하단에 다음 항목을 추가합니다.
export OS_IDENTITY_API_VERSION=3 export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=Default
export OS_IDENTITY_API_VERSION=3
export OS_PROJECT_DOMAIN_NAME=Default
export OS_USER_DOMAIN_NAME=Default
3. 파일을 가져와 현재 명령행 세션에 대해 다음 옵션을 활성화합니다.
source overcloudrc-v3
$ source overcloudrc-v3
2.8.2. 컨트롤러 구성 링크 복사링크가 클립보드에 복사되었습니다!
keystone 서비스를 실행하는 컨트롤러에서 다음 절차를 수행합니다.
1. SELinux를 구성합니다.
setsebool -P authlogin_nsswitch_use_ldap=on
# setsebool -P authlogin_nsswitch_use_ldap=on
2. 도메인 디렉터리를 생성합니다.
mkdir /etc/keystone/domains/ chown keystone /etc/keystone/domains/
# mkdir /etc/keystone/domains/
# chown keystone /etc/keystone/domains/
3. 여러 백엔드를 사용하도록 ID 서비스를 구성합니다.
yum install 할 수 있습니다.
crudini 를 사용하여 crudini를 설치해야
crudini --set /etc/keystone/keystone.conf identity domain_specific_drivers_enabled true crudini --set /etc/keystone/keystone.conf identity domain_config_dir /etc/keystone/domains crudini --set /etc/keystone/keystone.conf assignment driver sql
# crudini --set /etc/keystone/keystone.conf identity domain_specific_drivers_enabled true
# crudini --set /etc/keystone/keystone.conf identity domain_config_dir /etc/keystone/domains
# crudini --set /etc/keystone/keystone.conf assignment driver sql
Red Hat OpenStack Platform director를 사용하는 경우 /etc/keystone/keystone.conf 는 Puppet에서 관리합니다. 결과적으로 openstack overcloud deploy 프로세스를 실행할 때마다 추가한 사용자 정의 구성을 덮어쓸 수 있었습니다. 따라서 이 구성을 매번 수동으로 다시 추가해야 할 수 있습니다. 향후 director 릴리스에는 배포 후 스크립트를 사용하여 이러한 설정을 자동으로 다시 적용할 수 있는 Puppet 매개변수가 포함될 것으로 예상됩니다.
4. 추가 백엔드를 구성합니다.
a. IdM 통합을 위한 keystone 도메인을 생성합니다. 새 keystone 도메인에 사용할 이름을 결정한 다음 도메인을 만들어야 합니다. 예를 들어 이 명령은 LAB 라는 keystone 도메인을 생성합니다.
openstack domain create LAB
# openstack domain create LAB
이 명령을 사용할 수 없는 경우 명령행 세션에 keystone v3 을 활성화했는지 확인합니다.
b. 구성 파일을 생성합니다.
IdM 백엔드를 추가하려면 /etc/keystone/domains/keystone.LAB.conf 라는 새 파일에 LDAP 설정을 입력합니다. 여기서 LAB 는 이전에 생성된 도메인 이름입니다. IdM 배포에 맞게 아래의 샘플 설정을 편집해야 합니다.
각 설정에 대한 설명:
| 설정 | 설명 |
|---|---|
|
|
인증에 사용할 IdM 서버입니다. LDAPS 포트 |
|
| LDAP 쿼리에 사용할 IdM의 계정입니다. |
|
| 위에서 사용한 IdM 계정의 일반 텍스트 암호입니다. |
|
| ID 서비스에 제공된 사용자를 필터링합니다. 결과적으로 grp-openstack 그룹의 멤버만 ID 서비스에 정의된 권한을 가질 수 있습니다. |
|
| IdM의 OpenStack 계정 경로입니다. |
|
|
LDAP 사용자의 유형을 정의합니다. IdM의 경우 |
|
| 사용자 ID에 사용할 IdM 값을 매핑합니다. |
|
| 이름에 사용할 IdM 값을 매핑합니다. |
|
| 사용자 이메일 주소에 사용할 IdM 값을 매핑합니다. |
|
| 이 값을 비워 둡니다. |
|
|
keystone에는 읽기 전용 액세스 권한만 필요하므로 이 값을 |
|
|
keystone에는 읽기 전용 액세스 권한만 필요하므로 이 값을 |
|
|
keystone에는 읽기 전용 액세스 권한만 필요하므로 이 값을 |
5. config 파일의 소유권을 keystone 사용자로 변경합니다.
chown keystone /etc/keystone/domains/keystone.LAB.conf
# chown keystone /etc/keystone/domains/keystone.LAB.conf
6. 도메인에 대한 admin 사용자에게 액세스 권한을 부여합니다.
이는 OpenStack 관리자 계정에 IdM의 권한을 부여하지 않습니다. 이 경우 domain이라는 용어는 OpenStack의 keystone 도메인 사용을 나타냅니다.
a. LAB 도메인의 ID 를 가져옵니다.
b. admin 사용자의 ID 값을 가져옵니다.
openstack user list --domain default | grep admin
# openstack user list --domain default | grep admin
| 3d75388d351846c6a880e53b2508172a | admin |
c. admin 역할의 ID 값을 가져옵니다.
d. 반환된 도메인 및 관리자 ID를 사용하여 admin 사용자를 keystone LAB 도메인의 admin 역할에 추가하는 명령을 구성합니다.
openstack role add --domain 6800b0496429431ab1c4efbb3fe810d4 --user 3d75388d351846c6a880e53b2508172a 785c70b150ee4c778fe4de088070b4cf
# openstack role add --domain 6800b0496429431ab1c4efbb3fe810d4 --user 3d75388d351846c6a880e53b2508172a 785c70b150ee4c778fe4de088070b4cf
7. 로그인 페이지에서 LAB keystone 도메인을 사용하도록 대시보드를 구성합니다. /etc/openstack-dashboard/local_settings:에 다음 행을 추가합니다.
다중 도메인 대시보드 구성은 이 버전의 Red Hat OpenStack Platform에서 지원되지 않습니다. 결과적으로 이 가이드에서는 단일 도메인에 대한 대시보드 구성만 설명합니다.
OPENSTACK_API_VERSIONS = {
"identity": 3
}
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'LAB'
OPENSTACK_API_VERSIONS = {
"identity": 3
}
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'LAB'
Red Hat OpenStack Platform director를 사용하는 경우 /etc/openstack-dashboard/local_settings 는 Puppet에서 관리합니다. 결과적으로 openstack overcloud deploy 프로세스를 실행할 때마다 추가한 사용자 정의 구성을 덮어쓸 수 있었습니다. 따라서 이 구성을 매번 수동으로 다시 추가해야 할 수 있습니다. 향후 director 릴리스에는 배포 후 스크립트를 사용하여 이러한 설정을 자동으로 다시 적용할 수 있는 Puppet 매개변수가 포함될 것으로 예상됩니다.
8. httpd 서비스를 다시 시작하여 변경 사항을 적용합니다.
systemctl restart httpd.service
# systemctl restart httpd.service
9. 명령에 keystone 도메인 이름을 추가하여 IdM 도메인의 사용자 목록을 확인합니다.
openstack user list --domain LAB
# openstack user list --domain LAB
10. 로컬 keystone 데이터베이스의 서비스 계정을 확인합니다.
openstack user list --domain default
# openstack user list --domain default
2.8.3. keystone v3을 사용하도록 Compute 구성 링크 복사링크가 클립보드에 복사되었습니다!
Compute는 기본적으로 keystone v2.0 을 사용하므로 다중 도메인 기능을 사용하려면 keystone v3 을 사용하도록 구성해야 합니다.
1. 각 컴퓨팅 노드 및 컨트롤러에서 keystone_authtoken 값을 조정합니다.
crudini --set /etc/nova/nova.conf keystone_authtoken auth_version v3
# crudini --set /etc/nova/nova.conf keystone_authtoken auth_version v3
2. 컨트롤러에서 이러한 서비스를 다시 시작하여 변경 사항을 적용합니다.
systemctl restart openstack-nova-api.service openstack-nova-cert.service openstack-nova-conductor.service openstack-nova-consoleauth.service openstack-nova-novncproxy.service openstack-nova-scheduler.service
# systemctl restart openstack-nova-api.service openstack-nova-cert.service openstack-nova-conductor.service openstack-nova-consoleauth.service openstack-nova-novncproxy.service openstack-nova-scheduler.service
3. 각 컴퓨팅 노드에서 이 서비스를 다시 시작하여 변경 사항을 적용합니다.
systemctl restart openstack-nova-compute.service
# systemctl restart openstack-nova-compute.service
2.8.4. keystone v3을 사용하도록 블록 스토리지를 구성 링크 복사링크가 클립보드에 복사되었습니다!
keystone v3에 인증하도록 Block Storage(cinder)도 구성해야 합니다.
In /etc/cinder/cinder.conf:
[keystone_authtoken] auth_uri = https://controllerIP:5000/v3 auth_version = v3
[keystone_authtoken] auth_uri = https://controllerIP:5000/v3 auth_version = v3Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
auth_uri-controllerIP를 컨트롤러의 IP 주소로 바꿉니다. 배포에 컨트롤러가 두 개 이상 있는 경우 컨트롤러 IP 대신 keystone 엔드포인트 VIP를 사용해야 합니다.
-
2.8.5. IdM 사용자가 프로젝트에 액세스 가능 링크 복사링크가 클립보드에 복사되었습니다!
grp-openstack IdM 그룹의 멤버인 IdM 사용자에게는 대시보드에서 프로젝트에 로그인할 수 있는 권한을 부여할 수 있습니다.
1. IdM 사용자 목록을 검색합니다.
2. 역할 목록을 검색합니다.
3. 이러한 역할 중 하나에 추가하여 프로젝트에 대한 액세스 권한을 사용자에게 부여합니다. 예를 들어 user1 을 demo 프로젝트의 일반 사용자가 되도록 하려면 _member_ 역할에 추가합니다.
openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e _member_
# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e _member_
또는 user1 이 demo 프로젝트의 관리 사용자가 되도록 하려면 admin 역할에 추가합니다.
openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e admin
# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e admin
결과적으로 user1 은 IdM 사용자 이름과 암호를 입력하여 대시보드에 로그인할 수 있습니다.
사용자가 "오류: 컨테이너 목록을 검색할 수 없음" 오류가 발생하고 컨테이너를 관리할 수 있어야 하는 경우 SwiftOperator 역할에 추가해야 합니다.
2.9. 도메인 탭에 대한 액세스 권한 부여 링크 복사링크가 클립보드에 복사되었습니다!
admin 사용자가 Domain 탭을 볼 수 있도록 하려면 기본 도메인에서 admin 역할을 할당해야 합니다.
admin사용자의 UUID를 찾습니다.openstack user list | grep admin
$ openstack user list | grep admin | a6a8adb6356f4a879f079485dad1321b | admin |Copy to Clipboard Copied! Toggle word wrap Toggle overflow 기본도메인의admin역할을admin사용자에게 추가합니다.openstack role add --domain default --user a6a8adb6356f4a879f079485dad1321b admin
$ openstack role add --domain default --user a6a8adb6356f4a879f079485dad1321b adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow 결과적으로
admin사용자는 이제Domain탭을 볼 수 있습니다.
2.10. 새 프로젝트 생성 링크 복사링크가 클립보드에 복사되었습니다!
이러한 통합 단계를 완료한 후에는 새 프로젝트를 만들 때 Default 도메인에서 생성할지 또는 방금 생성한 keystone 도메인에 만들지 여부를 결정해야 합니다. 이 결정은 워크플로우와 사용자 계정 관리 방법을 통해 얻을 수 있습니다. Default 도메인은 서비스 계정과 admin 프로젝트에 사용되는 내부 도메인으로 간주할 수 있으므로 AD 지원 사용자를 다른 keystone 도메인에 배치하는 것이 적합할 수 있습니다. IdM 사용자가 있는 것과 동일한 keystone 도메인일 필요는 없으며 분리 목적으로 여러 keystone 도메인이 있을 수 있습니다.
2.10.1. 명령줄 변경 링크 복사링크가 클립보드에 복사되었습니다!
특정 명령의 경우 해당 도메인을 지정해야 할 수 있습니다. 예를 들어 이 명령에 --domain LAB 을 추가하면 LAB 도메인( grp-openstack 그룹의 멤버임)에서 사용자를 반환합니다.
openstack user list --domain LAB
# openstack user list --domain LAB
--domain Default 를 추가하면 내장된 keystone 계정을 반환합니다.
openstack user list --domain Default
# openstack user list --domain Default
2.10.2. IdM 통합 테스트 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 대시보드 기능에 대한 사용자 액세스를 테스트하여 IdM 통합을 검증합니다.
1. IdM에서 테스트 사용자를 생성하고 grp-openstack IdM 그룹에 사용자를 추가합니다.
2. 사용자를 demo 테넌트의 _member_ 역할에 추가합니다.
3. IdM test 사용자의 자격 증명을 사용하여 대시보드에 로그인합니다.
4. 각 탭을 클릭하여 오류 메시지 없이 성공적으로 표시되는지 확인합니다.
5. 대시보드를 사용하여 테스트 인스턴스를 빌드합니다.
이러한 단계에 문제가 발생하면 기본 제공 관리자 계정으로 3-5 단계를 수행하십시오. 성공한 경우 OpenStack이 여전히 예상대로 작동하고 IdM Cryostat ID 통합 설정 내의 문제가 있음을 보여줍니다. 2.13절. “문제 해결”을 참조하십시오.
2.11. 고가용성 구성 링크 복사링크가 클립보드에 복사되었습니다!
keystone v3을 활성화하면 해당 도메인의 구성 파일에 여러 IdM 서버를 나열하여 이 구성을 고가용성으로 설정할 수 있습니다.
1. 두 번째 서버를 url 항목에 추가합니다. 예를 들어 keystone.LAB.conf 파일의 url 설정을 업데이트하면 ID 서비스에서 모든 쿼리 트래픽을 목록의 첫 번째 IdM 서버로 보냅니다. idm.lab.local:
url = ldaps://idm.lab.local,ldaps://idm2.lab.local
url = ldaps://idm.lab.local,ldaps://idm2.lab.local
사용할 수 없기 때문에 idm.lab.local 에 대한 쿼리가 실패하면 ID 서비스에서 목록의 다음 서버를 쿼리하려고 합니다. idm2.lab.local. 이 구성은 라운드 로빈 방식으로 쿼리를 수행하지 않으므로 부하 분산 솔루션으로 간주할 수 없습니다.
2. /etc/openldap/ldap.conf 에 네트워크 시간 초과를 설정합니다.
NETWORK_TIMEOUT 2
NETWORK_TIMEOUT 2
또한 컨트롤러와 IdM 서버 간에 방화벽이 구성된 경우 컨트롤러에서 패킷을 자동으로 삭제하도록 IdM 서버를 구성해서는 안 됩니다. 이렇게 하면 python-keystoneclient 가 중단을 올바르게 감지하고 목록의 다음 IdM 서버로 요청을 리디렉션할 수 있습니다.
쿼리가 목록의 두 번째 IdM 서버로 리디렉션되는 동안 연결 지연이 발생할 수 있습니다. 첫 번째 서버에 대한 연결이 두 번째 연결을 시도하기 전에 먼저 시간 초과해야하기 때문입니다.
2.12. 관리자가 아닌 사용자에 대한 RC 파일 생성 링크 복사링크가 클립보드에 복사되었습니다!
관리자가 아닌 사용자에 대한 RC 파일을 생성해야 할 수도 있습니다. 예를 들면 다음과 같습니다.
2.13. 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
2.13.1. LDAP 연결 테스트 링크 복사링크가 클립보드에 복사되었습니다!
ldapsearch 를 사용하여 IdM 서버에 대해 원격으로 테스트 쿼리를 수행합니다. 이 결과에서 네트워크 연결이 작동하고 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 -D "cn=directory manager" -H ldaps://idm.lab.local:636 -b "dc=lab,dc=local" -s sub "(objectclass=*)" -w RedactedComplexPassword
LDAPSearch 는 openldap-clients 패키지의 일부입니다. # yum install openldap-clients 를 사용하여 설치할 수 있습니다.
2.13.2. 포트 액세스 테스트 링크 복사링크가 클립보드에 복사되었습니다!
nc 를 사용하여 LDAPS 포트(636)에 원격으로 액세스할 수 있는지 확인합니다. 이 예에서는 서버 idm.lab.local 에 대해 프로브가 수행됩니다. ctrl-c를 눌러 프롬프트를 종료합니다.
nc -v idm.lab.local 636
# nc -v idm.lab.local 636
Ncat: Version 6.40 ( http://nmap.org/ncat )
Ncat: Connected to 192.168.200.10:636.
^C
연결을 설정하지 않으면 방화벽 구성 문제가 표시될 수 있습니다.
3장. 일반 LDAP 통합 링크 복사링크가 클립보드에 복사되었습니다!
이 장에서는 일반 LDAP 환경과 Identity 서비스(keystone)를 통합하는 방법을 설명합니다.
이 사용 사례에서 ID 서비스는 특정 LDAP 사용자를 인증하는 동시에 ID 서비스 데이터베이스에 권한 부여 설정 및 중요한 서비스 계정을 유지합니다. 결과적으로 ID 서비스는 사용자 계정 인증을 위해 LDAP에 대한 읽기 전용 액세스 권한을 가지며, 인증된 계정에 할당된 권한에 대한 관리를 유지합니다.
3.1. 주요 용어 링크 복사링크가 클립보드에 복사되었습니다!
- 인증 - 암호를 사용하여 사용자가 있다고 요청하는지 확인합니다.
- 권한 부여 - 인증된 사용자에게 액세스하려는 시스템에 대한 적절한 권한이 있는지 확인합니다.
- domain - ID 서비스에 구성된 추가 백엔드를 나타냅니다. 예를 들어 외부 LDAP 환경에서 사용자를 인증하도록 ID 서비스를 구성할 수 있습니다. 생성된 사용자 컬렉션은 도메인으로 간주할 수 있습니다.
3.2. 가정 링크 복사링크가 클립보드에 복사되었습니다!
이 예제 배포에서는 다음과 같은 가정을 합니다.
- LDAP 서버가 구성되어 작동 중입니다.
- Red Hat OpenStack Platform은 구성 및 운영됩니다.
- DNS 이름 확인은 완전하며 모든 호스트가 적절하게 등록됩니다.
다중 도메인 대시보드 구성은 이 버전의 Red Hat OpenStack Platform에서 지원되지 않습니다. 결과적으로 이 가이드에서는 단일 도메인에 대한 대시보드 구성만 설명합니다.
3.3. 영향을 미치는 정책 링크 복사링크가 클립보드에 복사되었습니다!
이러한 단계를 통해 LDAP 사용자는 OpenStack에 인증하고 리소스에 액세스할 수 있습니다. OpenStack 서비스 계정(예: keystone 및 glance) 및 권한 관리(권한 및 역할)는 ID 서비스 데이터베이스에 남아 있습니다. 권한 및 역할은 ID 서비스 관리 툴을 사용하여 LDAP 계정에 할당됩니다.
3.3.1. 고가용성 옵션 링크 복사링크가 클립보드에 복사되었습니다!
이 구성은 단일 LDAP 서버의 가용성에 따라 종속성을 생성합니다. ID 서비스가 LDAP 서버에 인증할 수 없는 경우 프로젝트 사용자에게 영향을 미칩니다. 예를 들어 이 위험을 관리하는 데 사용할 수 있는 여러 옵션이 있습니다. 예를 들어 개별 LDAP 서버가 아닌 DNS 별칭 또는 로드 밸런싱 어플라이언스를 쿼리하도록 keystone을 구성할 수 있습니다. 다른 LDAP 서버를 쿼리하도록 keystone을 구성할 수도 있습니다. 하나는 사용할 수 없게 됩니다. 자세한 내용은 3.11절. “고가용성 구성”를 참조하십시오.
3.4. 중단 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
- LDAP 백엔드를 추가하려면 ID 서비스를 다시 시작해야 합니다.
- keystone v3 으로 전환하려면 모든 노드의 Compute 서비스를 다시 시작해야 합니다.
- LDAP에서 계정이 생성될 때까지 사용자가 대시보드에 액세스할 수 없습니다. 다운타임을 줄이려면 이러한 변경 전에 LDAP 계정을 미리 미리 생성하는 것이 좋습니다.
3.5. 방화벽 구성 링크 복사링크가 클립보드에 복사되었습니다!
방화벽이 LDAP와 OpenStack 간의 트래픽을 필터링하는 경우 다음 포트를 통한 액세스를 허용해야 합니다.
| 소스 | 대상 | 유형 | 포트 |
|---|---|---|---|
| OpenStack Controller 노드 | LDAP 서버 | LDAPS | TCP 636 |
3.6. LDAP 서버 구성 링크 복사링크가 클립보드에 복사되었습니다!
LDAP 서버에서 다음 단계를 수행하여 ID 서비스 통합을 준비합니다.
1. LDAP 조회 계정을 생성합니다.
이 계정은 ID 서비스에서 LDAP 서비스를 쿼리하는 데 사용됩니다. 표준 암호 정책 요구 사항 외에도 이 예제 배포에 대해 다음 속성이 필요합니다.
- 이름: OpenStack
- 성: LDAP
- 사용자 이름: svc-ldap
생성된 계정의 암호 만료 설정을 검토합니다.
2. grp-openstack 이라는 OpenStack 사용자를 위한 LDAP 그룹을 생성합니다. 이 그룹의 멤버만 OpenStack ID에 할당된 권한을 가질 수 있습니다.
3. svc-ldap 계정 암호를 설정하고 grp-openstack 그룹에 추가합니다.
3.7. LDAPS 인증서 구성 링크 복사링크가 클립보드에 복사되었습니다!
1. LDAP 환경에서 LDAPS 인증서를 찾습니다. 이 파일은 /etc/openldap/ldap.conf:
TLS_CACERT /etc/ipa/ca.crt
TLS_CACERT /etc/ipa/ca.crt
2. 파일을 OpenStack Identity(keystone)를 실행하는 노드에 복사합니다. 예를 들어 이 명령은 scp 를 사용하여 ca.crt를 node.lab.local 이라는 컨트롤러 노드에 복사합니다.
scp /etc/ipa/ca.crt root@node.lab.local:/root/
scp /etc/ipa/ca.crt root@node.lab.local:/root/
3. 컨트롤러 노드에서 .crt를 .pem으로 변환합니다.
openssl x509 -in ca.crt -out ca.pem -outform PEM
# openssl x509 -in ca.crt -out ca.pem -outform PEM
4. OpenStack 컨트롤러에 .pem을 설치합니다. 예를 들어 Red Hat Enterprise Linux에서는 다음과 같습니다.
cp ca.pem /etc/pki/ca-trust/source/anchors/ update-ca-trust
# cp ca.pem /etc/pki/ca-trust/source/anchors/
# update-ca-trust
5. .crt를 인증서 디렉터리에 복사합니다.
cp ca.crt /etc/ssl/certs/
# cp ca.crt /etc/ssl/certs/
3.8. ID 서비스 구성 링크 복사링크가 클립보드에 복사되었습니다!
이 단계에서는 LDAP와의 통합을 위해 ID 서비스를 준비합니다.
3.8.1. keystone v3에 대한 명령행 액세스 활성화 링크 복사링크가 클립보드에 복사되었습니다!
명령줄에서 ID 서비스 도메인을 관리하려면 keystone v3에 대한 액세스를 활성화해야 합니다.
keystone 서비스를 실행하는 컨트롤러에서 다음 절차를 수행합니다.
1. 기존 환경 변수 파일의 사본을 생성합니다. director 기반 배포에서는 overcloudrc:라고 합니다.
cp overcloudrc overcloudrc-v3
$ cp overcloudrc overcloudrc-v3
2. 새 overcloudrc-v3 파일을 편집합니다.
-
OS_AUTH_URL을 v2.0 에서 v3 로 변경합니다. 예를 들면 다음과 같습니다.
export OS_AUTH_URL=https://controllerIP:5000/v3/
export OS_AUTH_URL=https://controllerIP:5000/v3/
-
overcloudrc-v3하단에 다음 항목을 추가합니다.
export OS_IDENTITY_API_VERSION=3 export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=Default
export OS_IDENTITY_API_VERSION=3
export OS_PROJECT_DOMAIN_NAME=Default
export OS_USER_DOMAIN_NAME=Default
3. 파일을 가져와 현재 명령행 세션에 대해 다음 옵션을 활성화합니다.
source overcloudrc-v3
$ source overcloudrc-v3
3.8.2. 컨트롤러 구성 링크 복사링크가 클립보드에 복사되었습니다!
keystone 서비스를 실행하는 컨트롤러에서 다음 절차를 수행합니다.
1. SELinux를 구성합니다.
setsebool -P authlogin_nsswitch_use_ldap=on
# setsebool -P authlogin_nsswitch_use_ldap=on
2. 도메인 디렉터리를 생성합니다.
mkdir /etc/keystone/domains/ chown keystone /etc/keystone/domains/
# mkdir /etc/keystone/domains/
# chown keystone /etc/keystone/domains/
3. 여러 백엔드를 사용하도록 ID 서비스를 구성합니다.
yum install 할 수 있습니다.
crudini 를 사용하여 crudini를 설치해야
crudini --set /etc/keystone/keystone.conf identity domain_specific_drivers_enabled true crudini --set /etc/keystone/keystone.conf identity domain_config_dir /etc/keystone/domains crudini --set /etc/keystone/keystone.conf assignment driver sql
# crudini --set /etc/keystone/keystone.conf identity domain_specific_drivers_enabled true
# crudini --set /etc/keystone/keystone.conf identity domain_config_dir /etc/keystone/domains
# crudini --set /etc/keystone/keystone.conf assignment driver sql
Red Hat OpenStack Platform director를 사용하는 경우 /etc/keystone/keystone.conf 는 Puppet에서 관리합니다. 결과적으로 openstack overcloud deploy 프로세스를 실행할 때마다 추가한 사용자 정의 구성을 덮어쓸 수 있었습니다. 따라서 이 구성을 매번 수동으로 다시 추가해야 할 수 있습니다. 향후 director 릴리스에는 배포 후 스크립트를 사용하여 이러한 설정을 자동으로 다시 적용할 수 있는 Puppet 매개변수가 포함될 것으로 예상됩니다.
4. 추가 백엔드를 구성합니다.
a. LDAP 통합을 위한 keystone 도메인을 생성합니다. 새 keystone 도메인에 사용할 이름을 결정한 다음 도메인을 만들어야 합니다. 예를 들어 이 명령은 LAB 라는 keystone 도메인을 생성합니다.
openstack domain create LAB
# openstack domain create LAB
이 명령을 사용할 수 없는 경우 명령행 세션에 keystone v3 을 활성화했는지 확인합니다.
b. 구성 파일을 생성합니다.
LDAP 백엔드를 추가하려면 /etc/keystone/domains/keystone.LAB.conf 라는 새 파일에 LDAP 설정을 입력합니다. 여기서 LAB 는 이전에 생성된 도메인 이름입니다. LDAP 배포에 맞게 아래의 샘플 설정을 편집해야 합니다.
각 설정에 대한 설명:
| 설정 | 설명 |
|---|---|
|
|
인증에 사용할 LDAP 서버입니다. LDAPS 포트 |
|
| LDAP 쿼리에 사용할 LDAP의 계정입니다. |
|
| 위에서 사용한 LDAP 계정의 일반 텍스트 암호입니다. |
|
| ID 서비스에 제공된 사용자를 필터링합니다. 결과적으로 grp-openstack 그룹의 멤버만 ID 서비스에 정의된 권한을 가질 수 있습니다. |
|
| LDAP의 OpenStack 계정 경로입니다. |
|
|
LDAP 사용자의 유형을 정의합니다. LDAP의 경우 |
|
| 사용자 ID에 사용할 LDAP 값을 매핑합니다. |
|
| 이름에 사용할 LDAP 값을 매핑합니다. |
|
| 사용자 이메일 주소에 사용할 LDAP 값을 매핑합니다. |
|
| 이 값을 비워 둡니다. |
|
|
keystone에는 읽기 전용 액세스 권한만 필요하므로 이 값을 |
|
|
keystone에는 읽기 전용 액세스 권한만 필요하므로 이 값을 |
|
|
keystone에는 읽기 전용 액세스 권한만 필요하므로 이 값을 |
5. config 파일의 소유권을 keystone 사용자로 변경합니다.
chown keystone /etc/keystone/domains/keystone.LAB.conf
# chown keystone /etc/keystone/domains/keystone.LAB.conf
6. 도메인에 대한 admin 사용자에게 액세스 권한을 부여합니다.
이는 OpenStack 관리자 계정에 LDAP의 권한을 부여하지 않습니다. 이 경우 domain이라는 용어는 OpenStack의 keystone 도메인 사용을 나타냅니다.
a. LAB 도메인의 ID 를 가져옵니다.
b. admin 사용자의 ID 값을 가져옵니다.
openstack user list --domain default | grep admin
# openstack user list --domain default | grep admin
| 3d75388d351846c6a880e53b2508172a | admin |
c. admin 역할의 ID 값을 가져옵니다.
d. 반환된 도메인 및 관리자 ID를 사용하여 admin 사용자를 keystone LAB 도메인의 admin 역할에 추가하는 명령을 구성합니다.
openstack role add --domain 6800b0496429431ab1c4efbb3fe810d4 --user 3d75388d351846c6a880e53b2508172a 785c70b150ee4c778fe4de088070b4cf
# openstack role add --domain 6800b0496429431ab1c4efbb3fe810d4 --user 3d75388d351846c6a880e53b2508172a 785c70b150ee4c778fe4de088070b4cf
7. 로그인 페이지에서 LAB keystone 도메인을 사용하도록 대시보드를 구성합니다. /etc/openstack-dashboard/local_settings:에 다음 행을 추가합니다.
다중 도메인 대시보드 구성은 이 버전의 Red Hat OpenStack Platform에서 지원되지 않습니다. 결과적으로 이 가이드에서는 단일 도메인에 대한 대시보드 구성만 설명합니다.
OPENSTACK_API_VERSIONS = {
"identity": 3
}
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'LAB'
OPENSTACK_API_VERSIONS = {
"identity": 3
}
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'LAB'
Red Hat OpenStack Platform director를 사용하는 경우 /etc/openstack-dashboard/local_settings 는 Puppet에서 관리합니다. 결과적으로 openstack overcloud deploy 프로세스를 실행할 때마다 추가한 사용자 정의 구성을 덮어쓸 수 있었습니다. 따라서 이 구성을 매번 수동으로 다시 추가해야 할 수 있습니다. 향후 director 릴리스에는 배포 후 스크립트를 사용하여 이러한 설정을 자동으로 다시 적용할 수 있는 Puppet 매개변수가 포함될 것으로 예상됩니다.
8. httpd 서비스를 다시 시작하여 변경 사항을 적용합니다.
systemctl restart httpd.service
# systemctl restart httpd.service
9. 명령에 keystone 도메인 이름을 추가하여 LDAP 도메인의 사용자 목록을 확인합니다.
openstack user list --domain LAB
# openstack user list --domain LAB
10. 로컬 keystone 데이터베이스의 서비스 계정을 확인합니다.
openstack user list --domain default
# openstack user list --domain default
3.8.3. keystone v3을 사용하도록 Compute 구성 링크 복사링크가 클립보드에 복사되었습니다!
Compute는 기본적으로 keystone v2.0 을 사용하므로 다중 도메인 기능을 사용하려면 keystone v3 을 사용하도록 구성해야 합니다.
1. 각 컴퓨팅 노드 및 컨트롤러에서 keystone_authtoken 값을 조정합니다.
crudini --set /etc/nova/nova.conf keystone_authtoken auth_version v3
# crudini --set /etc/nova/nova.conf keystone_authtoken auth_version v3
2. 컨트롤러에서 이러한 서비스를 다시 시작하여 변경 사항을 적용합니다.
systemctl restart openstack-nova-api.service openstack-nova-cert.service openstack-nova-conductor.service openstack-nova-consoleauth.service openstack-nova-novncproxy.service openstack-nova-scheduler.service
# systemctl restart openstack-nova-api.service openstack-nova-cert.service openstack-nova-conductor.service openstack-nova-consoleauth.service openstack-nova-novncproxy.service openstack-nova-scheduler.service
3. 각 컴퓨팅 노드에서 이 서비스를 다시 시작하여 변경 사항을 적용합니다.
systemctl restart openstack-nova-compute.service
# systemctl restart openstack-nova-compute.service
3.8.4. keystone v3을 사용하도록 블록 스토리지를 구성 링크 복사링크가 클립보드에 복사되었습니다!
keystone v3에 인증하도록 Block Storage(cinder)도 구성해야 합니다.
In /etc/cinder/cinder.conf:
[keystone_authtoken] auth_uri = https://controllerIP:5000/v3 auth_version = v3
[keystone_authtoken] auth_uri = https://controllerIP:5000/v3 auth_version = v3Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
auth_uri-controllerIP를 컨트롤러의 IP 주소로 바꿉니다. 배포에 컨트롤러가 두 개 이상 있는 경우 컨트롤러 IP 대신 keystone 엔드포인트 VIP를 사용해야 합니다.
-
3.8.5. LDAP 사용자가 프로젝트에 액세스 가능 링크 복사링크가 클립보드에 복사되었습니다!
grp-openstack LDAP 그룹의 멤버인 LDAP 사용자에게는 대시보드에서 프로젝트에 로그인할 수 있는 권한을 부여할 수 있습니다.
1. LDAP 사용자 목록을 검색합니다.
2. 역할 목록을 검색합니다.
3. 이러한 역할 중 하나에 추가하여 프로젝트에 대한 액세스 권한을 사용자에게 부여합니다. 예를 들어 user1 을 demo 프로젝트의 일반 사용자가 되도록 하려면 _member_ 역할에 추가합니다.
openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e _member_
# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e _member_
또는 user1 이 demo 프로젝트의 관리 사용자가 되도록 하려면 admin 역할에 추가합니다.
openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e admin
# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e admin
결과적으로 user1 은 LDAP 사용자 이름과 암호를 입력하여 대시보드에 로그인할 수 있습니다.
사용자가 "오류: 컨테이너 목록을 검색할 수 없음" 오류가 발생하고 컨테이너를 관리할 수 있어야 하는 경우 SwiftOperator 역할에 추가해야 합니다.
3.9. 도메인 탭에 대한 액세스 권한 부여 링크 복사링크가 클립보드에 복사되었습니다!
admin 사용자가 Domain 탭을 볼 수 있도록 하려면 기본 도메인에서 admin 역할을 할당해야 합니다.
admin사용자의 UUID를 찾습니다.openstack user list | grep admin
$ openstack user list | grep admin | a6a8adb6356f4a879f079485dad1321b | admin |Copy to Clipboard Copied! Toggle word wrap Toggle overflow 기본도메인의admin역할을admin사용자에게 추가합니다.openstack role add --domain default --user a6a8adb6356f4a879f079485dad1321b admin
$ openstack role add --domain default --user a6a8adb6356f4a879f079485dad1321b adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow 결과적으로
admin사용자는 이제Domain탭을 볼 수 있습니다.
3.10. 새 프로젝트 생성 링크 복사링크가 클립보드에 복사되었습니다!
이러한 통합 단계를 완료한 후에는 새 프로젝트를 만들 때 Default 도메인에서 생성할지 또는 방금 생성한 keystone 도메인에 만들지 여부를 결정해야 합니다. 이 결정은 워크플로우와 사용자 계정 관리 방법을 통해 얻을 수 있습니다. Default 도메인은 서비스 계정과 관리 프로젝트에 사용되는 내부 도메인으로 간주할 수 있으므로 AD 지원 사용자를 다른 keystone 도메인에 배치하는 것이 적합할 수 있습니다. LDAP 사용자가 있고 분리 목적으로 여러 keystone 도메인이 있을 필요는 없습니다.
3.10.1. 명령줄 변경 링크 복사링크가 클립보드에 복사되었습니다!
특정 명령의 경우 해당 도메인을 지정해야 할 수 있습니다. 예를 들어 이 명령에 --domain LAB 을 추가하면 LAB 도메인( grp-openstack 그룹의 멤버임)에서 사용자를 반환합니다.
openstack user list --domain LAB
# openstack user list --domain LAB
--domain Default 를 추가하면 내장된 keystone 계정을 반환합니다.
openstack user list --domain Default
# openstack user list --domain Default
3.10.2. LDAP 통합 테스트 링크 복사링크가 클립보드에 복사되었습니다!
이 절차에서는 대시보드 기능에 대한 사용자 액세스를 테스트하여 LDAP 통합을 검증합니다.
1. LDAP에서 테스트 사용자를 생성하고 사용자를 grp-openstack LDAP 그룹에 추가합니다.
2. 사용자를 demo 테넌트의 _member_ 역할에 추가합니다.
3. LDAP 테스트 사용자의 자격 증명을 사용하여 대시보드에 로그인합니다.
4. 각 탭을 클릭하여 오류 메시지 없이 성공적으로 표시되는지 확인합니다.
5. 대시보드를 사용하여 테스트 인스턴스를 빌드합니다.
이러한 단계에 문제가 발생하면 기본 제공 관리자 계정으로 3-5 단계를 수행하십시오. 성공한 경우 OpenStack이 여전히 예상대로 작동하고 LDAP Cryostat ID 통합 설정 내의 다른 위치에 문제가 있음을 보여줍니다. 3.13절. “문제 해결”을 참조하십시오.
3.11. 고가용성 구성 링크 복사링크가 클립보드에 복사되었습니다!
keystone v3을 활성화하면 해당 도메인의 구성 파일에 여러 LDAP 서버를 나열하여 이 구성을 고가용성으로 설정할 수 있습니다.
1. 두 번째 서버를 url 항목에 추가합니다. 예를 들어 keystone.LAB.conf 파일의 url 설정을 업데이트하면 ID 서비스가 모든 쿼리 트래픽을 목록의 첫 번째 LDAP 서버로 보냅니다. ldap.lab.local:
url = ldaps://ldap.lab.local,ldaps://ldap2.lab.local
url = ldaps://ldap.lab.local,ldaps://ldap2.lab.local
ldap.lab.local 에 대한 쿼리가 사용할 수 없기 때문에 실패하는 경우 ID 서비스는 list: ldap2.lab.local. 이 구성은 라운드 로빈 방식으로 쿼리를 수행하지 않으므로 부하 분산 솔루션으로 간주할 수 없습니다.
2. /etc/openldap/ldap.conf 에 네트워크 시간 초과를 설정합니다.
NETWORK_TIMEOUT 2
NETWORK_TIMEOUT 2
또한 컨트롤러와 LDAP 서버 간에 방화벽이 구성되어 있는 경우 컨트롤러에서 패킷을 자동으로 삭제하도록 LDAP 서버를 구성해서는 안 됩니다. 이렇게 하면 python-keystoneclient 가 중단을 올바르게 감지하고 목록의 다음 LDAP 서버로 요청을 리디렉션할 수 있습니다.
쿼리가 목록의 두 번째 LDAP 서버로 리디렉션되는 동안 연결 지연이 발생할 수 있습니다. 첫 번째 서버에 대한 연결이 두 번째 연결을 시도하기 전에 먼저 시간 초과해야하기 때문입니다.
3.12. 관리자가 아닌 사용자에 대한 RC 파일 생성 링크 복사링크가 클립보드에 복사되었습니다!
관리자가 아닌 사용자에 대한 RC 파일을 생성해야 할 수도 있습니다. 예를 들면 다음과 같습니다.
3.13. 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
3.13.1. LDAP 연결 테스트 링크 복사링크가 클립보드에 복사되었습니다!
LDAP 서버에 대해 원격으로 테스트 쿼리를 수행하려면 ldapsearch 를 사용합니다. 이 경우 네트워크 연결이 작동하고 LDAP 서비스가 작동 중임을 나타냅니다. 이 예에서 테스트 쿼리는 포트 636의 ldap.lab.local 서버에 대해 수행됩니다.
ldapsearch -D "cn=directory manager" -H ldaps://ldap.lab.local:636 -b "dc=lab,dc=local" -s sub "(objectclass=*)" -w RedactedComplexPassword
# ldapsearch -D "cn=directory manager" -H ldaps://ldap.lab.local:636 -b "dc=lab,dc=local" -s sub "(objectclass=*)" -w RedactedComplexPassword
LDAPSearch 는 openldap-clients 패키지의 일부입니다. # yum install openldap-clients 를 사용하여 설치할 수 있습니다.
3.13.2. 포트 액세스 테스트 링크 복사링크가 클립보드에 복사되었습니다!
nc 를 사용하여 LDAPS 포트(636)에 원격으로 액세스할 수 있는지 확인합니다. 이 예에서는 ldap.lab.local 서버에 대해 프로브가 수행됩니다. ctrl-c를 눌러 프롬프트를 종료합니다.
nc -v ldap.lab.local 636
# nc -v ldap.lab.local 636
Ncat: Version 6.40 ( http://nmap.org/ncat )
Ncat: Connected to 192.168.200.10:636.
^C
연결을 설정하지 않으면 방화벽 구성 문제가 표시될 수 있습니다.