1장. 이미지 서비스(glance)

RHOSP(Red Hat OpenStack Platform)에서 이미지 및 스토리지를 관리합니다.

가상 머신 이미지는 부팅 가능한 운영 체제가 설치된 가상 디스크가 포함된 파일입니다. 가상 시스템 이미지는 다양한 형식으로 지원됩니다. RHOSP에서는 다음 형식을 사용할 수 있습니다.

  • RAW - 구조화되지 않은 디스크 이미지 형식입니다.
  • QCOW2 - QEMU 에뮬레이터에서 지원하는 디스크 형식입니다. 이 형식에는 QCOW2v3(때로는 QCOW3이라고 함)이 포함되며 QEMU 1.1 이상이 필요합니다.
  • ISO - 바이너리 파일에 저장된 디스크에 있는 데이터의 섹터별 사본입니다.
  • AKI - Amazon 커널 이미지를 나타냅니다.
  • AMI - Amazon 시스템 이미지를 나타냅니다.
  • ARI - Amazon RAMDisk 이미지를 나타냅니다.
  • VDI - VirtualBox 가상 시스템 모니터 및 QEMU 에뮬레이터에서 지원하는 디스크 형식입니다.
  • VHD - VMware, VirtualBox 등의 가상 시스템 모니터에서 사용하는 일반 디스크 형식입니다.
  • PLOOP - Virtuozzo에서 OS 컨테이너를 실행하기 위해 지원하고 사용하는 디스크 형식입니다.
  • OVA - 이미지 서비스(glance)에 저장된 항목이 OVA tar 아카이브 파일임을 나타냅니다.
  • DOCKER - Image 서비스(glance)에 저장된 것이 컨테이너 파일 시스템의 Docker tar 아카이브임을 나타냅니다.

ISO 는 일반적으로 가상 시스템 이미지 형식으로 간주되지 않지만 ISO에는 설치된 운영 체제가 있는 부팅 가능한 파일 시스템이 포함되어 있기 때문에 다른 가상 시스템 이미지 파일과 동일한 방식으로 사용합니다.

공식 Red Hat Enterprise Linux 클라우드 이미지를 다운로드하려면 계정에 유효한 Red Hat Enterprise Linux 서브스크립션이 있어야 합니다.

고객 포털에 로그인하지 않은 경우 Red Hat 계정 자격 증명을 입력해야 하는 프롬프트가 열립니다.

1.1. 이미지 서비스 이해

RHOSP(Red Hat OpenStack Platform) 이미지 서비스(glance) 기능.

1.1.1. 지원되는 이미지 서비스 백엔드

다음 Image 서비스(glance) 백엔드 시나리오가 지원됩니다.

  • Ceph를 사용할 때 RBD는 기본 백엔드입니다. 자세한 내용은 Advanced Overcloud Customization 가이드의 Ceph Storage 설정을 참조하십시오.
  • RBD 다중 저장소. 자세한 내용은 2.1절. “스토리지 에지 아키텍처의 요구 사항”의 내용을 참조하십시오.
  • 오브젝트 스토리지(swift). 자세한 내용은 Advanced Overcloud Customization 가이드의 외부 Object Storage 클러스터 사용을 참조하십시오.

    이미지 서비스는 Object Storage 유형 및 백엔드를 기본값으로 사용합니다.

  • 블록 스토리지(cinder). 자세한 내용은 Advanced Overcloud Customization 가이드 의 Image 서비스용 cinder 백엔드 구성을 참조하십시오.
  • NFS. 자세한 내용은 Advanced Overcloud Customization 가이드의 NFS 스토리지 구성을 참조하십시오.

    중요

    NFS는 지원되는 이미지 서비스 배포 옵션이지만 더 강력한 옵션을 사용할 수 있습니다.

    NFS는 이미지 서비스에 고유하지 않습니다. 이미지 서비스에 NFS 공유를 마운트하면 이미지 서비스에서 작업을 관리하지 않습니다. 이미지 서비스는 파일 시스템에 데이터를 작성하지만 백엔드가 NFS 공유임을 인식하지 못합니다.

    이 유형의 배포에서는 공유가 실패하는 경우 이미지 서비스에서 요청을 다시 시도할 수 없습니다. 즉, 백엔드에서 오류가 발생하면 저장소가 읽기 전용 모드로 전환되거나 로컬 파일 시스템에 데이터를 계속 쓸 수 있습니다. 이 경우 데이터 손실 위험이 있습니다. 이 상황에서 복구하려면 공유를 마운트하고 동기화한 다음 이미지 서비스를 다시 시작해야 합니다. 이러한 이유로 Red Hat은 이미지 서비스 백엔드로 NFS를 권장하지 않습니다.

    그러나 NFS를 이미지 서비스 백엔드로 사용하도록 선택하는 경우 다음 모범 사례 중 일부가 위험을 완화하는 데 도움이 될 수 있습니다.

    • 신뢰할 수 있는 프로덕션 등급 NFS 백엔드를 사용합니다.
    • 컨트롤러 노드와 NFS 백엔드 간에 강력하고 안정적인 연결이 있는지 확인합니다. 계층 2(L2) 네트워크 연결이 권장됩니다.
    • 마운트된 공유에 대한 모니터링 및 경고를 포함합니다.
    • 기본 파일 시스템 권한을 설정합니다. 저장소로 사용하는 공유 파일 시스템에 쓰기 권한이 있어야 합니다.
    • glance-api 프로세스가 실행되는 사용자 및 그룹에 로컬 파일 시스템의 마운트 지점에 대한 쓰기 권한이 없는지 확인합니다. 즉, 프로세스는 마운트 가능한 마운트 실패를 감지하고 쓰기 시도 중에 저장소를 읽기 전용 모드로 설정할 수 있습니다.

1.1.2. 이미지 서명 및 확인

배포자가 이미지에 서명하고 서명과 공개 키 인증서를 이미지 속성으로 저장할 수 있도록 함으로써 이미지 서명 및 확인을 통해 이미지 무결성과 신뢰성을 보호합니다.

이 기능을 활용하여 다음 작업을 수행할 수 있습니다.

  • 개인 키를 사용하여 이미지에 서명하고 이미지, 서명 및 공개 키 인증서(확인 메타데이터)에 대한 참조를 업로드합니다. 그런 다음 이미지 서비스는 서명이 유효한지 확인합니다.
  • 계산 서비스에 이미지를 생성하고, 계산 서비스에 이미지에 서명하고, 이미지 및 확인 메타데이터를 업로드합니다. 이미지 서비스는 서명이 유효한지 다시 확인합니다.
  • 계산 서비스에서 서명된 이미지를 요청합니다. 이미지 서비스는 이미지 및 확인 메타데이터를 제공하므로, 계산 서비스에서 부팅하기 전에 이미지를 검증할 수 있습니다.

이미지 서명 및 확인에 대한 자세한 내용은 OpenStack 키 관리자를 사용하여 시크릿 관리 가이드의 이미지 확인(glance) 을 참조하십시오.

1.1.3. 이미지 변환

이미지 변환은 이미지를 가져오는 동안 작업 API를 호출하여 이미지를 변환합니다.

가져오기 워크플로의 일부로 플러그인은 이미지 변환을 제공합니다. 이 플러그인은 배포자 구성에 따라 활성화 또는 비활성화할 수 있습니다. 따라서 배포자는 배포에 사용할 기본 이미지 형식을 지정해야 합니다.

내부적으로 이미지 서비스는 특정 형식으로 이미지의 비트를 받습니다. 이러한 비트는 임시 위치에 저장됩니다. 그런 다음 플러그인이 트리거되어 이미지를 대상 형식으로 변환하고 최종 대상으로 이동합니다. 작업이 완료되면 임시 위치가 삭제됩니다. 결과적으로 처음에 업로드된 형식은 이미지 서비스에 의해 유지되지 않습니다.

이미지 변환에 대한 자세한 내용은 다음을 참조하십시오. 1.2.8절. “이미지 변환 활성화”

참고

변환은 이미지를 가져올 때만 트리거할 수 있습니다. 이미지를 업로드할 때 실행되지 않습니다. 예를 들면 다음과 같습니다.

$ glance image-create-via-import \
    --disk-format qcow2 \
    --container-format bare \
    --name NAME \
    --visibility public \
    --import-method web-download \
    --uri http://server/image.qcow2

1.1.4. 상호 운용 가능한 이미지 가져오기

상호 운용 가능한 이미지 가져오기 워크플로를 사용하면 다음 두 가지 방법으로 이미지를 가져올 수 있습니다.

  • web-download (기본값) 방법을 사용하여 URI에서 이미지를 가져옵니다.
  • glance-direct 방법을 사용하여 로컬 파일 시스템에서 이미지를 가져옵니다.

1.1.5. 이미지 서비스 캐싱으로 확장성 개선

glance-api 캐싱 메커니즘을 사용하여 이미지 서비스(glance) API 서버에 이미지 복사본을 저장하고 자동으로 검색하여 확장성을 개선합니다. 이미지 서비스 캐싱을 사용하면 glance-api를 여러 호스트에서 실행할 수 있습니다. 즉, 백엔드 스토리지에서 동일한 이미지를 여러 번 검색할 필요가 없습니다. 이미지 서비스 캐싱은 이미지 서비스 작업에 영향을 미치지 않습니다.

Red Hat OpenStack Platform director(tripleo) heat 템플릿을 사용하여 이미지 서비스 캐싱을 구성합니다.

절차

  1. 환경 파일에서 glance-api.conf heat 템플릿에서 플레이버 값을 keystone+cachemanagement 로 자동 설정하는 GlanceCacheEnabled 매개변수 값을 true 로 설정합니다.

    parameter_defaults:
        GlanceCacheEnabled: true
  2. 오버클라우드를 재배포할 때 openstack overcloud deploy 명령에 환경 파일을 포함합니다.
  3. 선택 사항: 오버클라우드를 재배포할 때 대체 빈도로 glance_cache_pruner 를 조정합니다. 다음 예제에서는 5분의 빈도를 보여줍니다.

    parameter_defaults:
      ControllerExtraConfig:
        glance::cache::pruner::minute: '*/5'

    파일 시스템 전체 시나리오를 방지하려면 필요에 따라 빈도를 조정합니다. 대체 빈도를 선택할 때 다음 요소를 포함합니다.

    • 환경에 캐시할 파일의 크기입니다.
    • 사용 가능한 파일 시스템 공간의 양입니다.
    • 환경이 이미지를 캐시하는 빈도입니다.

1.1.6. 이미지 사전 캐싱

RHOSP(Red Hat OpenStack Platform) director는 glance-api 서비스의 일부로 이미지를 사전 캐시할 수 있습니다.

1.1.6.1. 주기적인 이미지 사전 캐싱을 위한 기본 간격 구성

이미지 사전 캐싱의 기본 주기 간격은 300초입니다. 요구 사항에 따라 기본 간격을 늘리거나 줄일 수 있습니다.

절차

  1. 요구 사항에 따라 언더클라우드의 환경 파일에 ExtraConfig 매개변수를 사용하여 새 간격을 추가합니다.

    parameter_defaults:
      ControllerExtraConfig:
        glance::config::glance_api_config:
          DEFAULT/cache_prefetcher_interval:
            value: '<300>'

    <300>을 이미지를 미리 캐시하는 간격으로 원하는 시간(초)으로 바꿉니다.

  2. /home/stack/templates/ 의 환경 파일의 간격을 조정한 후 stack 사용자로 로그인하고 구성을 배포합니다.

    $ openstack overcloud deploy --templates \
    -e /home/stack/templates/<env_file>.yaml

    <env_file>을 추가한 ExtraConfig 설정이 포함된 환경 파일의 이름으로 바꿉니다.

    중요

    오버클라우드를 생성할 때 추가 환경 파일을 전달한 경우 -e 옵션을 사용하여 오버클라우드를 원하지 않는 변경을 방지하여 다시 여기에 전달합니다.

openstack overcloud deploy 명령에 대한 자세한 내용은 Director 설치 및 사용 가이드의 Deployment 명령을 참조하십시오.

1.1.6.2. 주기적 작업을 사용하여 이미지 사전 캐시

사전 요구 사항

주기적으로 작업을 사용하여 이미지를 사전 캐시하려면 glance _api 서비스가 실행 중인 노드에 직접 연결된 glance -cache-manage 명령을 사용해야 합니다. 서비스 요청에 응답하는 노드를 숨기는 프록시를 사용하지 마십시오. undercloud에서 glance_api 서비스가 실행 중인 네트워크에 액세스할 수 없으므로 기본적으로 controller-0 이라고 하는 첫 번째 Overcloud 노드에서 명령을 실행합니다.

다음 전제 조건 절차를 완료하여 올바른 호스트에서 명령을 실행하고 필요한 자격 증명이 있으며 glance- api 컨테이너 내부에서 glance-cache-manage 명령을 실행 중인지 확인합니다.

절차

  1. stack 사용자로 언더클라우드에 로그인하고 controller-0 의 프로비저닝 IP 주소를 식별합니다.

    (undercloud) [stack@site-undercloud-0 ~]$ openstack server list -f value -c Name -c Networks | grep controller
    overcloud-controller-1 ctlplane=192.168.24.40
    overcloud-controller-2 ctlplane=192.168.24.13
    overcloud-controller-0 ctlplane=192.168.24.71
    (undercloud) [stack@site-undercloud-0 ~]$
  2. 오버클라우드에 인증하려면 기본적으로 /home/stack/overcloudrc 에 저장된 인증 정보를 controller-0 에 복사합니다.

    $ scp ~/overcloudrc heat-admin@192.168.24.71:/home/heat-admin/
  3. controller-0 에 연결합니다.

    $ ssh heat-admin@192.168.24.71
  4. controller-0 에서 heat-admin 사용자로 glance_api 서비스의 IP 주소를 식별합니다. 다음 예에서 IP 주소는 172.25.1.105 입니다.

    (overcloud) [root@controller-0 ~]# grep -A 10 '^listen glance_api' /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg
    listen glance_api
     server central-controller0-0.internalapi.redhat.local 172.25.1.105:9292 check fall 5 inter 2000 rise 2
  5. glance-cache-manage 명령은 glance_api 컨테이너에서만 사용할 수 있으므로 Overcloud에 인증할 환경 변수가 이미 설정된 해당 컨테이너에 대해 실행할 스크립트를 생성합니다. 다음 콘텐츠를 사용하여 controller-0/home/heat-adminglance_pod.sh 라는 스크립트를 생성합니다.

    sudo podman exec -ti \
     -e NOVA_VERSION=$NOVA_VERSION \
     -e COMPUTE_API_VERSION=$COMPUTE_API_VERSION \
     -e OS_USERNAME=$OS_USERNAME \
     -e OS_PROJECT_NAME=$OS_PROJECT_NAME \
     -e OS_USER_DOMAIN_NAME=$OS_USER_DOMAIN_NAME \
     -e OS_PROJECT_DOMAIN_NAME=$OS_PROJECT_DOMAIN_NAME \
     -e OS_NO_CACHE=$OS_NO_CACHE \
     -e OS_CLOUDNAME=$OS_CLOUDNAME \
     -e no_proxy=$no_proxy \
     -e OS_AUTH_TYPE=$OS_AUTH_TYPE \
     -e OS_PASSWORD=$OS_PASSWORD \
     -e OS_AUTH_URL=$OS_AUTH_URL \
     -e OS_IDENTITY_API_VERSION=$OS_IDENTITY_API_VERSION \
     -e OS_COMPUTE_API_VERSION=$OS_COMPUTE_API_VERSION \
     -e OS_IMAGE_API_VERSION=$OS_IMAGE_API_VERSION \
     -e OS_VOLUME_API_VERSION=$OS_VOLUME_API_VERSION \
     -e OS_REGION_NAME=$OS_REGION_NAME \
    glance_api /bin/bash
  6. overcloudrc 파일을 가져오고 필요한 환경 변수를 사용하여 glance_pod.sh 스크립트를 실행하여 overcloud 컨트롤러 노드를 인증하는 데 필요한 환경 변수를 사용하여 glance_api 컨테이너에 실행합니다.

    [heat-admin@controller-0 ~]$ source overcloudrc
    (overcloudrc) [heat-admin@central-controller-0 ~]$ bash glance_pod.sh
    ()[glance@controller-0 /]$
  7. glance image-list 와 같은 명령을 사용하여 컨테이너에서 Overcloud에 대해 인증된 명령을 실행할 수 있는지 확인합니다.

    ()[glance@controller-0 /]$ glance image-list
    +--------------------------------------+----------------------------------+
    | ID                                   | Name                             |
    +--------------------------------------+----------------------------------+
    | ad2f8daf-56f3-4e10-b5dc-d28d3a81f659 | cirros-0.4.0-x86_64-disk.img       |
    +--------------------------------------+----------------------------------+
    ()[glance@controller-0 /]$

절차

  1. admin 사용자로 캐시할 이미지를 대기열에 지정합니다.

    $ glance-cache-manage --host=<host_ip> queue-image <image_id>
    • <host_ip>를 glance-api 컨테이너가 실행 중인 컨트롤러 노드의 IP 주소로 바꿉니다.
    • <image_id>를 대기열에 추가할 이미지의 ID로 바꿉니다.

      사전 캐시하려는 이미지를 큐에 추가한 경우 cache_images 주기적 작업은 대기 중인 모든 이미지를 동시에 가져오기합니다.

      참고

      이미지 캐시는 각 노드에 로컬이기 때문에 Red Hat OpenStack Platform이 HA(3, 5 또는 7 컨트롤러 사용)와 함께 배포되면 glance-cache-manage 명령을 실행할 때 --host 옵션으로 호스트 주소를 지정해야 합니다.

  2. 다음 명령을 실행하여 이미지 캐시의 이미지를 확인합니다.

    $ glance-cache-manage --host=<host_ip> list-cached

    <host_ip>를 사용자 환경에 있는 호스트의 IP 주소로 바꿉니다.

관련 정보

다음과 같은 목적으로 추가 glance-cache-manage 명령을 사용할 수 있습니다.

  • list-cached: 현재 캐시된 모든 이미지를 나열합니다.
  • list-queued: 현재 캐싱에 대기 중인 모든 이미지를 나열합니다.
  • 캐싱을 위해 이미지를 대기열에 대기하는 queue-image.
  • delete-cached-image 를 사용하여 캐시에서 이미지를 제거합니다.
  • delete-all-cached-images 를 사용하여 캐시에서 모든 이미지를 제거합니다.
  • delete-queued-image 를 사용하여 캐시 큐에서 이미지를 삭제합니다.
  • 캐시 큐에서 모든 이미지를 삭제하려면 delete-all-queued-images 를 삭제합니다.

1.1.7. 이미지 서비스 API를 사용하여 스파스 이미지 업로드 활성화

Image 서비스(glance) API를 사용하면 스파스 이미지 업로드를 사용하여 네트워크 트래픽을 줄이고 스토리지 공간을 절약할 수 있습니다. 이 기능은 DCN(Distributed Compute Node) 환경에서 특히 유용합니다. 스파스 이미지 파일을 사용하면 이미지 서비스에서 null 바이트 시퀀스를 작성하지 않습니다. 이미지 서비스는 지정된 오프셋을 사용하여 데이터를 기록합니다. 스토리지 백엔드는 이러한 오프셋을 실제로 스토리지 공간을 사용하지 않는 null 바이트로 해석합니다.

제한

  • 스파스 이미지 업로드는 Ceph RBD에서만 지원됩니다.
  • 파일 시스템에는 스파스 이미지 업로드가 지원되지 않습니다.
  • 클라이언트와 이미지 서비스 API 간 전송 중에 스파스 값은 유지 관리되지 않습니다. 이미지는 이미지 서비스 API 수준에서 스파스됩니다.

사전 요구 사항

  • RHOSP(Red Hat OpenStack Platform) 배포는 이미지 서비스 백엔드에 RBD를 사용합니다.

절차

  1. stack 사용자로 Undercloud 노드에 로그인합니다.
  2. stackrc 인증 정보 파일을 소싱합니다.

    $ source stackrc
  3. 다음 콘텐츠를 사용하여 환경 파일을 생성합니다.

    parameter_defaults:
        GlanceSparseUploadEnabled: true
  4. 다른 환경 파일을 사용하여 스택에 새 환경 파일을 추가하고 오버클라우드를 배포합니다.

    $ openstack overcloud deploy \
    --templates \
    …
    -e <existing_overcloud_environment_files> \
    -e <new_environment_file>.yaml \
    …

    이미지 업로드에 대한 자세한 내용은 1.2.2절. “이미지 업로드” 을 참조하십시오.

검증

이미지를 가져오고 크기를 확인하여 스파스 이미지 업로드를 확인할 수 있습니다.

  1. 이미지 파일을 로컬로 다운로드합니다.

    $ wget <file_location>/<file_name>

    & lt;file_location >을 파일 위치로 바꿉니다. & lt;file_name >을 파일 이름으로 바꿉니다.

    다음 절차에서는 예제 명령을 사용합니다. 적절한 경우 값을 해당 환경의 값으로 바꿉니다.

    $ wget https://cloud.centos.org/centos/6/images/CentOS-6-x86_64-GenericCloud-1508.qcow2
  2. 업로드할 이미지의 디스크 크기 및 가상 크기를 확인합니다.

     qemu-img info <file_name>

    다음 절차에서는 예제 명령을 사용합니다. 적절한 경우 값을 해당 환경의 값으로 바꿉니다.

    $ qemu-img info CentOS-6-x86_64-GenericCloud-1508.qcow2
    
    image: CentOS-6-x86_64-GenericCloud-1508.qcow2
    file format: qcow2
    virtual size: 8 GiB (8589934592 bytes)
    disk size: 1.09 GiB
    cluster_size: 65536
    Format specific information:
    compat: 0.10
    refcount bits: 1
  3. 이미지를 가져옵니다.

    $ glance image-create-via-import --disk-format qcow2 --container-format bare --name centos_1 --file <file_name>
  4. 이미지 ID를 기록합니다. 후속 단계에서 필요합니다.
  5. 이미지를 가져오고 활성 상태인지 확인합니다.

    $ openstack image show <image_id>
  6. Ceph Storage 노드에서 이미지 크기가 1 단계의 출력에서 가상 크기보다 작은지 확인합니다.

    $ sudo rbd -p images diff <image_id> | awk '{ SUM += $2 } END { print SUM/1024/1024/1024 " GB" }'
    
    1.03906 GB
  7. 선택 사항: 컨트롤러 노드의 Glance 구성 파일에 rbd_thin_provisioning 이 구성되었는지 확인할 수 있습니다.

    1. SSH를 사용하여 컨트롤러 노드에 액세스합니다.

      $ ssh -A -t heat-admin@<controller_node_IP_address>
    2. 해당 컨트롤러 노드에서 rbd_thin_provisioningTrue 와 같은지 확인합니다.

      $ sudo podman exec -it glance_api sh -c 'grep ^rbd_thin_provisioning /etc/glance/glance-api.conf'

1.1.8. Metadef API 보안

RHOSP(Red Hat OpenStack Platform)에서 사용자는 키 값 쌍을 정의하고 메타데이터를 메타데이터(metadef) API로 태그할 수 있습니다. 현재는 사용자가 생성할 수 있는 메타 재정의 네임스페이스, 오브젝트, 속성, 리소스 또는 태그 수에 제한이 없습니다.

Metadef API는 권한 없는 사용자에게 정보를 유출할 수 있습니다. 악의적인 사용자는 제한 부족을 악용하고 무제한 리소스로 Image 서비스(glance) 데이터베이스를 채울 수 있습니다. 그러면 DoS(서비스 거부) 스타일 공격이 발생할 수 있습니다.

이미지 서비스 정책은 메타 파일 API를 제어합니다. 그러나 metadef API의 기본 정책 설정을 사용하면 모든 사용자가 metadef 정보를 생성하거나 읽을 수 있습니다. metadef 리소스는 소유자와 격리되지 않으므로 내부 인프라 세부 정보 또는 고객 이름과 같이 잠재적으로 민감한 이름의 메타 파일 리소스는 악의적인 사용자에게 해당 정보를 노출할 수 있습니다.

1.1.8.1. metadef API를 제한하도록 정책 구성

Image 서비스(glance)의 보안을 강화하려면 메타 파일 수정 API를 RHOSP(Red Hat OpenStack Platform) 배포에서 기본적으로 admin 전용 액세스로 제한합니다.

절차

  1. 클라우드 관리자로서 Image 서비스 metadef API에 대한 정책 재정의를 포함하려면 lock-down-glance-metadef-api.yaml 과 같은 별도의 heat 템플릿 환경 파일을 생성합니다.

    ...
    parameter_defaults:
      GlanceApiPolicies: {
    	glance-metadef_default: { key: 'metadef_default', value: '' },
    	glance-metadef_admin: { key: 'metadef_admin', value: 'role:admin' },
    	glance-get_metadef_namespace: { key: 'get_metadef_namespace', value: 'rule:metadef_default' },
    	glance-get_metadef_namespaces: { key: 'get_metadef_namespaces', value: 'rule:metadef_default' },
    	glance-modify_metadef_namespace: { key: 'modify_metadef_namespace', value: 'rule:metadef_admin' },
    	glance-add_metadef_namespace: { key: 'add_metadef_namespace', value: 'rule:metadef_admin' },
    	glance-delete_metadef_namespace: { key: 'delete_metadef_namespace', value: 'rule:metadef_admin' },
    	glance-get_metadef_object: { key: 'get_metadef_object', value: 'rule:metadef_default' },
    	glance-get_metadef_objects: { key: 'get_metadef_objects', value: 'rule:metadef_default' },
    	glance-modify_metadef_object: { key: 'modify_metadef_object', value: 'rule:metadef_admin' },
    	glance-add_metadef_object: { key: 'add_metadef_object', value: 'rule:metadef_admin' },
    	glance-delete_metadef_object: { key: 'delete_metadef_object', value: 'rule:metadef_admin' },
    	glance-list_metadef_resource_types: { key: 'list_metadef_resource_types', value: 'rule:metadef_default' },
    	glance-get_metadef_resource_type: { key: 'get_metadef_resource_type', value: 'rule:metadef_default' },
    	glance-add_metadef_resource_type_association: { key: 'add_metadef_resource_type_association', value: 'rule:metadef_admin' },
    	glance-remove_metadef_resource_type_association: { key: 'remove_metadef_resource_type_association', value: 'rule:metadef_admin' },
    	glance-get_metadef_property: { key: 'get_metadef_property', value: 'rule:metadef_default' },
    	glance-get_metadef_properties: { key: 'get_metadef_properties', value: 'rule:metadef_default' },
    	glance-modify_metadef_property: { key: 'modify_metadef_property', value: 'rule:metadef_admin' },
    	glance-add_metadef_property: { key: 'add_metadef_property', value: 'rule:metadef_admin' },
    	glance-remove_metadef_property: { key: 'remove_metadef_property', value: 'rule:metadef_admin' },
    	glance-get_metadef_tag: { key: 'get_metadef_tag', value: 'rule:metadef_default' },
    	glance-get_metadef_tags: { key: 'get_metadef_tags', value: 'rule:metadef_default' },
    	glance-modify_metadef_tag: { key: 'modify_metadef_tag', value: 'rule:metadef_admin' },
    	glance-add_metadef_tag: { key: 'add_metadef_tag', value: 'rule:metadef_admin' },
    	glance-add_metadef_tags: { key: 'add_metadef_tags', value: 'rule:metadef_admin' },
    	glance-delete_metadef_tag: { key: 'delete_metadef_tag', value: 'rule:metadef_admin' },
    	glance-delete_metadef_tags: { key: 'delete_metadef_tags', value: 'rule:metadef_admin' }
      }
    
    …
  2. 오버클라우드를 배포할 때 -e 옵션을 사용하여 배포 명령에 정책 덮어쓰기가 포함된 환경 파일을 포함합니다.

    $ openstack overcloud deploy -e lock-down-glance-metadef-api.yaml

1.1.8.2. metadef API 활성화

이전에 메타데이터 정의(metadef) API를 제한하거나 새 기본값을 완화하려는 경우 메타 파일 수정 정책을 재정의하여 사용자가 해당 리소스를 업데이트할 수 있습니다.

중요

metadef API에 대한 쓰기 액세스 권한을 사용하는 사용자가 클라우드 관리자는 모든 사용자가 해당 API에 액세스할 수 있도록 할 수 있습니다. 그러나 이러한 유형의 구성에서는 의도치 않게 민감한 리소스 이름(예: 고객 이름 및 내부 프로젝트)을 유출할 수 있습니다. 관리자는 모든 사용자에게 읽기 액세스만 활성화되어 있더라도 취약할 수 있는 이전에 생성된 리소스를 식별하도록 시스템을 감사해야 합니다.

절차

  1. 클라우드 관리자로 언더클라우드에 로그인하고 정책을 재정의할 파일을 만듭니다. 예를 들면 다음과 같습니다.

    $ cat open-up-glance-api-metadef.yaml
  2. metadef API 읽기-쓰기 액세스를 모든 사용자에게 허용하도록 정책 덮어쓰기 파일을 구성합니다.

    GlanceApiPolicies: {
        glance-metadef_default: { key: 'metadef_default', value: '' },
        glance-get_metadef_namespace: { key: 'get_metadef_namespace', value: 'rule:metadef_default' },
        glance-get_metadef_namespaces: { key: 'get_metadef_namespaces', value: 'rule:metadef_default' },
        glance-modify_metadef_namespace: { key: 'modify_metadef_namespace', value: 'rule:metadef_default' },
        glance-add_metadef_namespace: { key: 'add_metadef_namespace', value: 'rule:metadef_default' },
        glance-delete_metadef_namespace: { key: 'delete_metadef_namespace', value: 'rule:metadef_default' },
        glance-get_metadef_object: { key: 'get_metadef_object', value: 'rule:metadef_default' },
        glance-get_metadef_objects: { key: 'get_metadef_objects', value: 'rule:metadef_default' },
        glance-modify_metadef_object: { key: 'modify_metadef_object', value: 'rule:metadef_default' },
        glance-add_metadef_object: { key: 'add_metadef_object', value: 'rule:metadef_default' },
        glance-delete_metadef_object: { key: 'delete_metadef_object', value: 'rule:metadef_default' },
        glance-list_metadef_resource_types: { key: 'list_metadef_resource_types', value: 'rule:metadef_default' },
        glance-get_metadef_resource_type: { key: 'get_metadef_resource_type', value: 'rule:metadef_default' },
        glance-add_metadef_resource_type_association: { key: 'add_metadef_resource_type_association', value: 'rule:metadef_default' },
        glance-remove_metadef_resource_type_association: { key: 'remove_metadef_resource_type_association', value: 'rule:metadef_default' },
        glance-get_metadef_property: { key: 'get_metadef_property', value: 'rule:metadef_default' },
        glance-get_metadef_properties: { key: 'get_metadef_properties', value: 'rule:metadef_default' },
        glance-modify_metadef_property: { key: 'modify_metadef_property', value: 'rule:metadef_default' },
        glance-add_metadef_property: { key: 'add_metadef_property', value: 'rule:metadef_default' },
        glance-remove_metadef_property: { key: 'remove_metadef_property', value: 'rule:metadef_default' },
        glance-get_metadef_tag: { key: 'get_metadef_tag', value: 'rule:metadef_default' },
        glance-get_metadef_tags: { key: 'get_metadef_tags', value: 'rule:metadef_default' },
        glance-modify_metadef_tag: { key: 'modify_metadef_tag', value: 'rule:metadef_default' },
        glance-add_metadef_tag: { key: 'add_metadef_tag', value: 'rule:metadef_default' },
        glance-add_metadef_tags: { key: 'add_metadef_tags', value: 'rule:metadef_default' },
        glance-delete_metadef_tag: { key: 'delete_metadef_tag', value: 'rule:metadef_default' },
        glance-delete_metadef_tags: { key: 'delete_metadef_tags', value: 'rule:metadef_default' }
      }
    참고

    rule:eatadeta_default 를 사용하도록 모든 메타 파일 정책을 구성해야 합니다.

  3. 오버클라우드를 배포할 때 -e 옵션을 사용하여 배포 명령에 새 정책 파일을 포함합니다.

    $ openstack overcloud deploy -e open-up-glance-api-metadef.yaml