OpenStack ID와 외부 사용자 관리 서비스 통합

Red Hat OpenStack Platform 16.1

Active Directory 또는 Red Hat Identity Management를 외부 인증 백엔드로 사용

OpenStack Documentation Team

초록

OpenStack Identity(keystone) 서비스를 Microsoft AD DS(Active Directory Domain Service), Red Hat IdM(Identity Management) 및 LDAP와 통합합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오. :leveloffset: +0

Red Hat 문서에 관한 피드백 제공

문서 개선을 위한 의견을 보내 주십시오. Red Hat이 어떻게 이를 개선하는지 알려주십시오.

DDF(직접 문서 피드백) 기능 사용

특정 문장, 단락 또는 코드 블록에 대한 직접 주석은 피드백 추가 DDF 기능을 사용하십시오.

  1. 다중 페이지 HTML 형식으로 설명서를 봅니다.
  2. 문서 오른쪽 상단에 Feedback (피드백) 버튼이 표시되는지 확인합니다.
  3. 주석 처리하려는 텍스트 부분을 강조 표시합니다.
  4. 피드백 추가를 클릭합니다.
  5. 주석을 사용하여 Add Feedback (피드백 추가) 필드를 작성합니다.
  6. 선택 사항: 설명서 팀이 문제에 대한 자세한 내용을 문의할 수 있도록 이메일 주소를 추가하십시오.
  7. 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와 통합하는 프로세스에는 다음 단계가 포함됩니다.

  1. Active Directory 자격 증명 구성 및 LDAPS 인증서 내보내기
  2. OpenStack에 LDAPS 인증서 설치 및 구성
  3. 하나 이상의 LDAP 백엔드를 사용하도록 director 설정
  4. Active Directory 백엔드에 액세스하도록 컨트롤러 노드 구성
  5. OpenStack 프로젝트에 대한 Active Directory 사용자 또는 그룹 액세스 구성
  6. 도메인 및 사용자 목록이 올바르게 생성되었는지 확인합니다.
  7. 선택 사항: 관리자가 아닌 사용자에 대한 자격 증명 파일을 만듭니다.

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 서버에서 다음 단계를 수행합니다.

  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'
  2. 이 계정의 암호를 설정한 다음 활성화합니다. AD 도메인의 복잡성 요구 사항을 준수하는 암호를 지정하라는 메시지가 표시됩니다.

    PS C:\> Set-ADAccountPassword svc-ldap -PassThru | Enable-ADAccount
  3. grp-openstack 이라는 RHOSP 사용자의 그룹을 생성합니다. 이 그룹의 멤버만 OpenStack ID에 할당된 권한을 가질 수 있습니다.

    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"
  5. svc-ldap 사용자를 grp-openstack 그룹에 추가합니다.

    PS C:\> ADD-ADGroupMember "grp-openstack" -members "svc-ldap"
  6. AD 도메인 컨트롤러에서 인증서 MMC 를 사용하여 LDAPS 인증서의 공개 키(개인 키 아님)를 DER 인코딩 x509 .cer 파일로 내보냅니다. 이 파일을 RHOSP 관리자에게 전송합니다.
  7. 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에서 내보냅니다.

절차

  1. 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
  2. 선택 사항: ldapsearch 와 같은 진단 명령을 실행해야 하는 경우 RHEL 인증서 저장소에 인증서를 추가해야 합니다.

    1. .cer를. pem 으로 변환합니다. 이 예에서는 addc.lab.local.cer :이라는 소스 인증서 파일을 사용합니다.

      # openssl x509 -inform der -in addc.lab.local.cer -out addc.lab.local.pem
    2. 컨트롤러 노드에 .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 매개변수로 추가하여 이 경로를 재정의할 수 있습니다.

절차

  1. 배포에 사용할 heat 템플릿에서 KeystoneLDAPDomainEnable 플래그를 true 로 설정합니다. 이렇게 하면 identity 구성 그룹 내의 keystone에 domain_specific_drivers_enabled 옵션이 구성됩니다.
  2. tripleo-heat-templates 에서 KeystoneLDAPBackendConfigs 매개변수를 설정하여 LDAP 백엔드 구성 사양을 추가합니다. 그런 다음 필요한 LDAP 옵션을 지정할 수 있습니다.
  3. keystone_domain_specific_ldap_backend.yaml 환경 파일의 사본을 생성합니다.

    $ cp /usr/share/openstack-tripleo-heat-templates/environments/services/keystone_domain_specific_ldap_backend.yaml /home/stack/templates/
  4. /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

    이러한 매개 변수의 값은 배포에 영향을 미치지 않으며 안전하게 제거할 수 있습니다.

  5. 선택 사항: 환경 파일에 더 많은 도메인을 추가합니다. 예를 들면 다음과 같습니다.

        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 도메인을 사용합니다. 도메인 이름을 구성 중인 도메인의 실제 이름으로 바꿉니다.

  1. LAB 도메인의 ID를 가져옵니다.

    $ openstack domain show LAB
    +---------+----------------------------------+
    | Field   | Value                            |
    +---------+----------------------------------+
    | enabled | True                             |
    | id      | 6800b0496429431ab1c4efbb3fe810d4 |
    | name    | LAB                              |
    +---------+----------------------------------+
  2. 기본 도메인에서 admin 사용자의 ID를 가져옵니다.

    $ openstack user list --domain default | grep admin
    | 3d75388d351846c6a880e53b2508172a | admin      |
  3. 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_      |
      +----------------------------------+---------------+
  4. 도메인 및 admin ID를 사용하여 admin 사용자를 keystone LAB 도메인의 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 라는 프로젝트를 사용합니다.

절차

  1. 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  |
      +------------------------------------------------------------------+---------------------+
  2. 역할 목록을 검색합니다.

    # 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 |
      +----------------------------------+---------------+
  3. 이러한 역할 중 하나 이상에 추가하여 사용자 그룹에 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 을 입력하여 대시보드에 로그인할 있습니다.

domain
참고

사용자에게 오류가 발생하면 오류: 컨테이너 목록을 검색할 수 없으며 컨테이너를 관리할 수 있어야 하는 경우 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 라는 프로젝트를 사용합니다.

절차

  1. OpenStack ID 도메인에서 사용자 목록을 검색합니다.

    # openstack user list --domain LAB
     +------------------------------------------------------------------+----------------+
    | ID                                                               | Name           |
    +------------------------------------------------------------------+----------------+
    | 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e | user1          |
    | 12c062faddc5f8b065434d9ff6fce03eb9259537c93b411224588686e9a38bf1 | user2          |
    | afaf48031eb54c3e44e4cb0353f5b612084033ff70f63c22873d181fdae2e73c | user3          |
    | e47fc21dcf0d9716d2663766023e2d8dc15a6d9b01453854a898cabb2396826e | user4          |
    +------------------------------------------------------------------+----------------+
  2. 역할 목록을 검색합니다.

    # 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 |
      +----------------------------------+---------------+
  3. 이러한 역할 중 하나 이상에 추가하여 RHOSP 프로젝트에 대한 액세스 권한을 부여합니다. 예를 들어, user1demo 프로젝트의 일반 사용자가 되도록 하려면 통합 중인 외부 서비스에 따라 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_
  4. user1demo 프로젝트의 관리 사용자가 되도록 하려면 사용자를 admin 역할에 추가합니다.

    # openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e admin

결과

user1 사용자는 외부 사용자 이름 및 암호를 입력하고 Domain (도메인) 필드에 LAB 을 입력하여 대시보드에 로그인할 수 있습니다.

domain
참고

사용자에게 오류가 발생하면 오류: 컨테이너 목록을 검색할 수 없으며 컨테이너를 관리할 수 있어야 하는 경우 SwiftOperator 역할에 추가해야 합니다.

1.7. OpenStack ID 도메인 및 사용자 목록 보기

openstack domain list 명령을 사용하여 사용 가능한 항목을 나열합니다. ID 서비스에서 여러 도메인을 구성하면 대시보드 로그인 페이지에서 새 Domain (도메인) 필드가 활성화됩니다. 사용자는 로그인 자격 증명과 일치하는 도메인을 입력해야 합니다.

중요

통합을 완료한 후 Default 도메인 또는 새로 생성된 keystone 도메인에서 새 프로젝트를 생성할지 여부를 결정해야 합니다. 워크플로와 사용자 계정을 관리하는 방법을 고려해야 합니다. 가능한 경우 Default 도메인을 내부 도메인으로 사용하여 서비스 계정 및 admin 프로젝트를 관리하고 외부 사용자를 별도의 도메인에 유지합니다.

이 예에서 외부 계정은 LAB 도메인을 지정해야 합니다. admin 과 같은 기본 제공 keystone 계정은 Default 를 도메인으로 지정해야 합니다.

절차

  1. 도메인 목록을 표시합니다.

    # openstack domain list
    +----------------------------------+---------+---------+----------------------------------------------------------------------+
    | ID                               | Name    | Enabled | Description                                                          |
    +----------------------------------+---------+---------+----------------------------------------------------------------------+
    | 6800b0496429431ab1c4efbb3fe810d4 | LAB     | True    |                                                                      |
    | default                          | Default | True    | Owns users and projects available on Identity API v2. |
    +----------------------------------+---------+---------+----------------------------------------------------------------------+
  2. 특정 도메인의 사용자 목록을 표시합니다. 이 명령은 --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)과 같은 외부 사용자 관리 서비스와 통합

절차

  1. 외부 사용자 관리 서비스에서 test 사용자를 생성하고 사용자를 grp-openstack 그룹에 추가합니다.
  2. Red Hat OpenStack Platform에서 demo 프로젝트의 _member_ 역할에 사용자를 추가합니다.
  3. AD 테스트 사용자의 자격 증명을 사용하여 대시보드에 로그인합니다.
  4. 각 탭을 클릭하여 오류 메시지 없이 성공적으로 표시되는지 확인합니다.
  5. 대시보드를 사용하여 테스트 인스턴스를 구축합니다.
참고

이러한 단계에 문제가 발생하면 admin 계정으로 대시보드에 로그인하고 해당 사용자로 후속 단계를 수행합니다. 테스트에 성공하면 OpenStack이 여전히 예상대로 작동 중이며 OpenStack ID와 Active Directory의 통합 설정에 문제가 있음을 나타냅니다.

1.10. Active Directory 통합 문제 해결

OpenStack ID와 Active Directory 통합을 사용할 때 오류가 발생하면 LDAP 연결을 테스트하거나 인증서 신뢰 구성을 테스트해야 할 수 있습니다. LDAPS 포트에 액세스할 수도 있습니다.

참고

오류 유형 및 위치에 따라 이 절차의 관련 단계만 수행합니다.

절차

  1. ldapsearch 명령을 사용하여 Active Directory 도메인 컨트롤러에 대한 테스트 쿼리를 원격으로 수행하여 LDAP 연결을 테스트합니다. 여기에서 성공적인 결과는 네트워크 연결이 작동 중이며 AD DS 서비스가 작동 중임을 나타냅니다. 이 예제에서는 포트 636addc.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
    참고
    • ldapsearchopenldap-clients 패키지의 일부입니다. # dnf install openldap-clients를 사용하여 설치할 수 있습니다.
    • 이 명령은 호스트 운영 체제에서 필요한 인증서를 찾아야 합니다.
  2. Peer의 Certificate 발행자가 인식되지 않는 오류가 표시되면 ldapsearch 명령을 테스트하는 동안 TLS_CACERTDIR 경로가 올바르게 설정되었는지 확인합니다. 예를 들면 다음과 같습니다.

    TLS_CACERTDIR /etc/openldap/certs
  3. 임시 해결 방법으로 인증서 유효성 검사를 비활성화하는 것이 좋습니다.

    중요

    이 설정을 영구적으로 구성해서는 안 됩니다.

    /etc/openldap/ldap.conf 에서 다음을 허용하도록 TLS_REERT 매개변수를 설정합니다.

    TLS_REQCERT allow

    이 값을 설정한 후 ldapsearch 쿼리가 작동하는 경우 인증서 신뢰가 올바르게 구성되었는지 검토해야 할 수 있습니다.

  4. 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과 통합하는 프로세스에는 다음 단계가 포함됩니다.

  1. novajoin을 사용하여 IdM에 언더클라우드 및 오버클라우드 등록
  2. Ansible을 사용하여 언더클라우드 및 오버클라우드에 TLS-e 구현
  3. IdM 서버 자격 증명을 설정하고 LDAPS 인증서를 내보냅니다.
  4. OpenStack에 LDAPS 인증서 설치 및 구성
  5. 하나 이상의 LDAP 백엔드를 사용하도록 director 설정
  6. IdM 백엔드에 액세스하도록 컨트롤러 노드 구성
  7. OpenStack 프로젝트에 대한 IdM 사용자 또는 그룹 액세스 권한 구성
  8. 도메인 및 사용자 목록이 올바르게 생성되었는지 확인합니다.
  9. 선택 사항: 관리자가 아닌 사용자에 대한 인증 정보 파일 만들기

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. 매개변수 권장 사항

옵션권장 사항

--admin-password

제공하는 값을 기록해 둡니다. IdM을 사용하도록 Red Hat OpenStack Platform을 구성할 때 이 암호가 필요합니다.

--ip-address

제공하는 값을 기록해 둡니다. 언더클라우드 및 오버클라우드 노드에는 이 IP 주소에 대한 네트워크 액세스가 필요합니다.

--setup-dns

IdM 서버에 통합 DNS 서비스를 설치하려면 이 옵션을 사용합니다. 언더클라우드 및 오버클라우드 노드는 도메인 이름 확인을 위해 IdM 서버를 사용합니다.

--auto-forwarders

/etc/resolv.conf 의 주소를 DNS 전달자로 사용하려면 이 옵션을 사용합니다.

--auto-reverse

IdM 서버 IP 주소에 대한 역방향 레코드 및 영역을 확인하려면 이 옵션을 사용합니다. 역방향 레코드 또는 영역을 확인할 수 없는 경우 IdM은 역방향 영역을 생성합니다. 이를 통해 IdM 배포가 간소화됩니다.

--ntp-server, --ntp-pool

이러한 옵션 중 하나 또는 둘 다를 사용하여 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이며 업데이트된 템플릿 및 구성 파일과 일치하도록 기존 배포 구성만 조정합니다.

  1. /etc/resolv.conf 파일을 구성합니다.

    /etc/resolv.conf 의 언더클라우드에 적절한 검색 도메인과 이름 서버를 설정합니다. 예를 들어 배포 도메인이 example.com 이고 FreeIPA 서버의 도메인이 bigcorp.com 인 경우 /etc/resolv.conf에 다음 행을 추가합니다.

    search example.com bigcorp.com
    nameserver $IDM_SERVER_IP_ADDR
  2. 필요한 소프트웨어를 설치합니다.

    sudo dnf install -y python3-ipalib python3-ipaclient krb5-devel
  3. 환경에 고유한 값을 사용하여 환경 변수를 내보냅니다.

    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 사용자 자격 증명은 새 호스트 및 서비스를 추가할 수 있는 관리자여야 합니다.

  4. 언더클라우드에서 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
  5. undercloud.conf에 다음 매개 변수를 추가합니다.

    undercloud_nameservers = $IDM_SERVER_IP_ADDR
    overcloud_domain_name = example.com
  6. 언더클라우드를 배포합니다.

    openstack undercloud install

검증

다음 단계를 완료하여 언더클라우드가 올바르게 등록되었는지 확인합니다.

  1. IdM에 호스트를 나열합니다.

    $ kinit admin
    $ ipa host-find
  2. 언더클라우드에 /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
  1. 오버클라우드를 배포하기 전에 다음과 유사한 내용을 사용하여 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 로 추가하고 설정해야 합니다.
  2. 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 \
    ...
  3. 끝점 목록에 대한 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 통합을 진행하기 전에 등록 프로세스를 수행해야 합니다. 등록 과정에는 다음 단계가 포함됩니다.

  1. 언더클라우드 노드를 CA(인증 기관)에 추가
  2. IdM에 언더클라우드 노드 추가
  3. 선택 사항: IdM 서버를 오버클라우드의 DNS 서버로 설정
  4. 환경 파일 준비 및 오버클라우드 배포
  5. IdM 및 RHOSP에서 오버클라우드 등록 테스트
  6. 선택 사항: IdM에서 novajoin의 DNS 항목 추가
참고

novajoin에 IdM 등록은 현재 언더클라우드 및 오버클라우드 노드에서만 사용할 수 있습니다. 오버클라우드 인스턴스에 대한 novajoin 통합은 이후 릴리스에서 지원될 것으로 예상됩니다.

2.4.1. 인증 기관에 언더클라우드 노드 추가

오버클라우드를 배포하기 전에 언더클라우드 노드에 python3-novajoin 패키지를 설치하고 novajoin -ipa-setup 스크립트를 실행하여 언더클라우드를 CA(인증 기관)에 추가합니다.

절차

  1. 언더클라우드 노드에서 python3-novajoin 패키지를 설치합니다.

    $ sudo dnf install python3-novajoin
  2. 언더클라우드 노드에서 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] 섹션에 다음 설정을 구성합니다.

절차

  1. novajoin 서비스를 활성화합니다.

    [DEFAULT]
    enable_novajoin = true
  2. IdM을 사용하여 언더클라우드 노드를 등록할 수 있도록 1회성 암호(OTP)를 설정합니다.

    ipa_otp = <otp>
  3. neutron의 DHCP 서버에서 제공할 오버클라우드의 도메인 이름을 설정합니다.

    overcloud_domain_name = <domain>
  4. 언더클라우드의 호스트 이름을 설정합니다.

    undercloud_hostname = <undercloud FQDN>
  5. IdM을 언더클라우드의 이름 서버로 설정합니다.

    undercloud_nameservers = <IdM IP>
  6. 더 큰 환경의 경우 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>
  7. 선택 사항: 로컬 openSSL 인증 기관에서 director의 공용 끝점에 대한 SSL 인증서를 생성 하려면 generate_service_certificate 매개변수를 true 로 설정합니다.

    generate_service_certificate = true
  8. undercloud.conf 파일을 저장합니다.
  9. 언더클라우드 배포 명령을 실행하여 기존 언더클라우드에 변경 사항을 적용합니다.

    $ openstack undercloud install

검증

다음 단계를 완료하여 언더클라우드가 올바르게 등록되었는지 확인합니다.

  1. IdM에 호스트를 나열합니다.

    $ kinit admin
    $ ipa host-find
  2. 언더클라우드에 /etc/novajoin/krb5.keytab 이 있는지 확인합니다.

    ls /etc/novajoin/krb5.keytab

2.4.3. 오버클라우드의 DNS 서버로 Red Hat IdM(Identity Manager) 설정

IdM 환경에 대한 자동 감지 및 등록이 용이하려면 DNS 서버로 IdM을 설정합니다. 이 절차는 선택 사항이지만 권장되는 절차입니다.

절차

  1. 언더클라우드에 연결합니다.

    $ source ~/stackrc
  2. IdM을 DNS 이름 서버로 사용하도록 컨트롤 플레인 서브넷을 구성합니다.

    $ openstack subnet set ctlplane-subnet --dns-nameserver  <idm_server_address>
  3. IdM 서버를 사용하도록 환경 파일에서 DnsServers 매개변수를 설정합니다.

    parameter_defaults:
      DnsServers: ["<idm_server_address>"]

    일반적으로 이 매개변수는 사용자 지정 network-environment.yaml 파일에 정의됩니다.

2.4.4. novajoin 등록을 사용하여 환경 파일 준비 및 오버클라우드 배포

IdM 통합을 사용하여 오버클라우드를 배포하려면 환경 파일을 생성하고 편집하여 오버클라우드에서 정의한 도메인을 기반으로 사용자 지정 도메인 매개변수 CloudDomain 및 CloudName 을 사용하도록 오버클라우드를 구성합니다. 그런 다음 모든 환경 파일과 배포에 필요한 추가 환경 파일을 사용하여 오버클라우드를 배포합니다.

절차

  1. /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
  2. /home/stack/templates/custom-domain.yaml 환경 파일을 편집하고 배포에 맞게 CloudDomainCloudName* 값을 설정합니다.

    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
  3. 사용자 환경에 적합한 TLS 구현을 선택합니다.

    • enable-tls.yaml 환경 파일을 사용하여 사용자 정의 인증서로 외부 끝점을 보호합니다.

      1. /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-tls.yaml/home/stack/templates 로 복사합니다.
      2. 사용자 정의 인증서 및 키를 포함하도록 /home/stack/enable-tls.yaml 환경 파일을 수정합니다.
      3. 배포에 다음 환경 파일을 포함하여 내부 및 외부 끝점을 보호합니다.

        • 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 항목을 생성해야 합니다.

      1. 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
      2. 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'}]
      3. 필요에 따라 각 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
      4. 배포에 다음 환경 파일을 포함하여 내부 및 외부 끝점을 보호합니다.

        • 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 사용자를 쿼리할 수 있는지 확인할 수 있습니다.

  1. 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
  2. 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 서버에서 이 절차를 수행합니다.

  1. OpenStack ID 서비스에서 IdM LDAP 서비스를 쿼리하는 데 사용할 LDAP 조회 계정을 생성합니다.

    # kinit admin
    # ipa user-add
    First name: OpenStack
    Last name: LDAP
    User  [radministrator]: svc-ldap
    참고

    생성된 후 이 계정의 암호 만료 설정을 검토합니다.

  2. grp-openstack 이라는 RHOSP 사용자의 그룹을 생성합니다. 이 그룹의 멤버만 OpenStack ID에 할당된 권한을 가질 수 있습니다.

    # 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
  4. 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 서버 자격 증명이 구성되어 있습니다.

절차

  1. IdM 환경에서 LDAPS 인증서를 찾습니다. 이 파일은 /etc/openldap/ldap.conf를 사용하여 찾을 수 있습니다.

    TLS_CACERT /etc/ipa/ca.crt
  2. keystone 서비스를 실행하는 컨트롤러 노드에 파일을 복사합니다. 예를 들어 scp 명령은 ca.crt 파일을 node.lab.local에 복사합니다.

    # scp /etc/ipa/ca.crt root@node.lab.local:/root/
  3. ca.crt 파일을 인증서 디렉터리에 복사합니다. keystone 서비스가 인증서에 액세스하는 데 사용할 위치입니다.

    # cp ca.crt /etc/pki/ca-trust/source/anchors
  4. 선택 사항: ldapsearch 와 같은 진단 명령을 실행해야 하는 경우 RHEL 인증서 저장소에 인증서를 추가해야 합니다.

    1. 3. 컨트롤러 노드에서 .crt를. pem 형식으로 변환합니다.

      # openssl x509 -in ca.crt -out ca.pem -outform PEM
    2. 컨트롤러 노드에 .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 매개변수로 추가하여 이 경로를 재정의할 수 있습니다.

절차

  1. 배포에 사용할 heat 템플릿에서 KeystoneLDAPDomainEnable 플래그를 true 로 설정합니다. 이렇게 하면 identity 구성 그룹 내의 keystone에 domain_specific_drivers_enabled 옵션이 구성됩니다.
  2. tripleo-heat-templates 에서 KeystoneLDAPBackendConfigs 매개변수를 설정하여 LDAP 백엔드 구성 사양을 추가합니다. 그런 다음 필요한 LDAP 옵션을 지정할 수 있습니다.
  3. keystone_domain_specific_ldap_backend.yaml 환경 파일의 사본을 생성합니다.

    $ cp /usr/share/openstack-tripleo-heat-templates/environments/services/keystone_domain_specific_ldap_backend.yaml /home/stack/templates/
  4. /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

    이러한 매개 변수의 값은 배포에 영향을 미치지 않으며 안전하게 제거할 수 있습니다.

  5. 선택 사항: 환경 파일에 더 많은 도메인을 추가합니다. 예를 들면 다음과 같습니다.

        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 도메인을 사용합니다. 도메인 이름을 구성 중인 도메인의 실제 이름으로 바꿉니다.

  1. LAB 도메인의 ID를 가져옵니다.

    $ openstack domain show LAB
    +---------+----------------------------------+
    | Field   | Value                            |
    +---------+----------------------------------+
    | enabled | True                             |
    | id      | 6800b0496429431ab1c4efbb3fe810d4 |
    | name    | LAB                              |
    +---------+----------------------------------+
  2. 기본 도메인에서 admin 사용자의 ID를 가져옵니다.

    $ openstack user list --domain default | grep admin
    | 3d75388d351846c6a880e53b2508172a | admin      |
  3. 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_      |
      +----------------------------------+---------------+
  4. 도메인 및 admin ID를 사용하여 admin 사용자를 keystone LAB 도메인의 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 라는 프로젝트를 사용합니다.

절차

  1. 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  |
      +------------------------------------------------------------------+---------------------+
  2. 역할 목록을 검색합니다.

    # 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 |
      +----------------------------------+---------------+
  3. 이러한 역할 중 하나 이상에 추가하여 사용자 그룹에 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 을 입력하여 대시보드에 로그인할 있습니다.

domain
참고

사용자에게 오류가 발생하면 오류: 컨테이너 목록을 검색할 수 없으며 컨테이너를 관리할 수 있어야 하는 경우 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 라는 프로젝트를 사용합니다.

절차

  1. OpenStack ID 도메인에서 사용자 목록을 검색합니다.

    # openstack user list --domain LAB
     +------------------------------------------------------------------+----------------+
    | ID                                                               | Name           |
    +------------------------------------------------------------------+----------------+
    | 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e | user1          |
    | 12c062faddc5f8b065434d9ff6fce03eb9259537c93b411224588686e9a38bf1 | user2          |
    | afaf48031eb54c3e44e4cb0353f5b612084033ff70f63c22873d181fdae2e73c | user3          |
    | e47fc21dcf0d9716d2663766023e2d8dc15a6d9b01453854a898cabb2396826e | user4          |
    +------------------------------------------------------------------+----------------+
  2. 역할 목록을 검색합니다.

    # 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 |
      +----------------------------------+---------------+
  3. 이러한 역할 중 하나 이상에 추가하여 RHOSP 프로젝트에 대한 액세스 권한을 부여합니다. 예를 들어, user1demo 프로젝트의 일반 사용자가 되도록 하려면 통합 중인 외부 서비스에 따라 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_
  4. user1demo 프로젝트의 관리 사용자가 되도록 하려면 사용자를 admin 역할에 추가합니다.

    # openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e admin

결과

user1 사용자는 외부 사용자 이름 및 암호를 입력하고 Domain (도메인) 필드에 LAB 을 입력하여 대시보드에 로그인할 수 있습니다.

domain
참고

사용자에게 오류가 발생하면 오류: 컨테이너 목록을 검색할 수 없으며 컨테이너를 관리할 수 있어야 하는 경우 SwiftOperator 역할에 추가해야 합니다.

2.11. OpenStack ID 도메인 및 사용자 목록 보기

openstack domain list 명령을 사용하여 사용 가능한 항목을 나열합니다. ID 서비스에서 여러 도메인을 구성하면 대시보드 로그인 페이지에서 새 Domain (도메인) 필드가 활성화됩니다. 사용자는 로그인 자격 증명과 일치하는 도메인을 입력해야 합니다.

중요

통합을 완료한 후 Default 도메인 또는 새로 생성된 keystone 도메인에서 새 프로젝트를 생성할지 여부를 결정해야 합니다. 워크플로와 사용자 계정을 관리하는 방법을 고려해야 합니다. 가능한 경우 Default 도메인을 내부 도메인으로 사용하여 서비스 계정 및 admin 프로젝트를 관리하고 외부 사용자를 별도의 도메인에 유지합니다.

이 예에서 외부 계정은 LAB 도메인을 지정해야 합니다. admin 과 같은 기본 제공 keystone 계정은 Default 를 도메인으로 지정해야 합니다.

절차

  1. 도메인 목록을 표시합니다.

    # openstack domain list
    +----------------------------------+---------+---------+----------------------------------------------------------------------+
    | ID                               | Name    | Enabled | Description                                                          |
    +----------------------------------+---------+---------+----------------------------------------------------------------------+
    | 6800b0496429431ab1c4efbb3fe810d4 | LAB     | True    |                                                                      |
    | default                          | Default | True    | Owns users and projects available on Identity API v2. |
    +----------------------------------+---------+---------+----------------------------------------------------------------------+
  2. 특정 도메인의 사용자 목록을 표시합니다. 이 명령은 --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)과 같은 외부 사용자 관리 서비스와 통합

절차

  1. 외부 사용자 관리 서비스에서 test 사용자를 생성하고 사용자를 grp-openstack 그룹에 추가합니다.
  2. Red Hat OpenStack Platform에서 demo 프로젝트의 _member_ 역할에 사용자를 추가합니다.
  3. AD 테스트 사용자의 자격 증명을 사용하여 대시보드에 로그인합니다.
  4. 각 탭을 클릭하여 오류 메시지 없이 성공적으로 표시되는지 확인합니다.
  5. 대시보드를 사용하여 테스트 인스턴스를 구축합니다.
참고

이러한 단계에 문제가 발생하면 admin 계정으로 대시보드에 로그인하고 해당 사용자로 후속 단계를 수행합니다. 테스트에 성공하면 OpenStack이 여전히 예상대로 작동 중이며 OpenStack ID와 Active Directory의 통합 설정에 문제가 있음을 나타냅니다.

2.14. Red Hat IdM(Identity Manager) 통합 문제 해결

Red Hat IdM(Identity Manager)과 OpenStack Identity 통합을 사용할 때 오류가 발생하면 LDAP 연결을 테스트하거나 인증서 신뢰 구성을 테스트해야 할 수 있습니다. LDAPS 포트에 액세스할 수도 있습니다.

참고

오류 유형 및 위치에 따라 이 절차의 관련 단계만 수행합니다.

절차

  1. 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
    참고

    ldapsearchopenldap-clients 패키지의 일부입니다. # dnf install openldap-clients를 사용하여 설치할 수 있습니다.

  2. 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

    연결을 설정하지 못하면 방화벽 구성 문제를 나타낼 수 있습니다.

법적 공지

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.