4.2. RHSA-2018:2214 - 중요: openstack-tripleo-heat-templates 보안 업데이트

이 섹션에 포함된 버그는 RHSA-2018:2214 권고에서 다룹니다. 이 권고에 대한 자세한 내용은 https://access.redhat.com/errata/RHSA-2018:2214.html 에서 확인할 수 있습니다.

openstack-tripleo-common

Ansible 플레이북의 로그에 배포, 업데이트 및 업그레이드 중 작업 타이밍에 대한 정보를 제공하는 타임스탬프가 포함됩니다.

openstack-tripleo-heat-templates

이전에는 OpenDaylight의 오래된 캐시로 인해 오버클라우드 업데이트가 실패했습니다. 이번 업데이트를 통해 OpenDaylight가 중지되고 새 버전으로 업그레이드하기 전에 오래된 캐시가 제거됩니다. 레벨 1 업데이트는 OpenDaylight 배포에서 작동합니다. 2차 업데이트는 현재 지원되지 않습니다.

기존 오버클라우드 배포에서 Octavia를 활성화하면 컨트롤러 노드의 방화벽 규칙이 잘못 구성되어 있으므로 Octavia API 끝점에 연결할 수 없습니다.

해결방법:

모든 컨트롤러 노드에서 방화벽 규칙을 추가하고 DROP 규칙 앞에 삽입되는지 확인합니다.

IPv4:
  # iptables -A INPUT -p tcp -m multiport --dports 9876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy ipv4" -j ACCEPT
  # iptables -A INPUT -p tcp -m multiport --dports 13876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy_ssl ipv4" -j ACCEPT
  # iptables -A INPUT -p tcp -m multiport --dports 9876,13876 -m state --state NEW -m comment --comment "120 octavia_api ipv4" -j ACCEPT

IPv6:
  # ip6tables -A INPUT -p tcp -m multiport --dports 9876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy ipv6" -j ACCEPT
  # ip6tables -A INPUT -p tcp -m multiport --dports 13876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy_ssl ipv6" -j ACCEPT
  # ip6tables -A INPUT -p tcp -m multiport --dports 9876,13876 -m state --state NEW -m comment --comment "120 octavia_api ipv6" -j ACCEPT

IPv4:
  # iptables -A INPUT -p tcp -m multiport --dports 9876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy ipv4" -j ACCEPT
  # iptables -A INPUT -p tcp -m multiport --dports 13876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy_ssl ipv4" -j ACCEPT
  # iptables -A INPUT -p tcp -m multiport --dports 9876,13876 -m state --state NEW -m comment --comment "120 octavia_api ipv4" -j ACCEPT

IPv6:
  # ip6tables -A INPUT -p tcp -m multiport --dports 9876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy ipv6" -j ACCEPT
  # ip6tables -A INPUT -p tcp -m multiport --dports 13876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy_ssl ipv6" -j ACCEPT
  # ip6tables -A INPUT -p tcp -m multiport --dports 9876,13876 -m state --state NEW -m comment --comment "120 octavia_api ipv6" -j ACCEPT

HAProxy를 재시작합니다.

docker restart haproxy-bundle-docker-0

  # docker restart haproxy-bundle-docker-0

OpenDaylight 로깅이 이전 로그가 누락되었을 수 있습니다. 이는 OpenDaylight의 journald 로깅 (Docker logs opendaylght_api" 명령 사용)과 관련하여 알려진 문제입니다. 현재 해결방법은 OpenDaylight 로깅을 컨테이너 내부에서 /opt/opendaylight/data/logs/karaf.log에 기록할 "file" 메커니즘으로 전환하는 것입니다. 이렇게 하려면 OpenDaylightLogMechanism: 'file'이라는 heat 매개변수를 구성합니다.

기존 오버클라우드에 대해 오버클라우드 배포 명령을 다시 실행하지 못했습니다. pacemaker 관리 리소스를 재시작하지 못했습니다. 예를 들어 haproxy에 새 서비스를 추가하는 경우 haproxy Pacemaker 리소스를 수동으로 다시 시작할 때까지 새로 구성된 서비스를 사용할 수 없게 됩니다.

이번 업데이트를 통해 pacemaker 리소스의 구성 변경이 감지되고 pacemaker 리소스가 자동으로 다시 시작됩니다. pacemaker 관리 리소스 구성의 모든 변경 사항은 오버클라우드에 반영됩니다.

minor-update 워크플로우 내의 서비스 배포 작업은 플레이북 목록의 특수한 항목으로 인해 두 번 실행되었습니다. 이번 업데이트에서는 뛰어난 플레이북 항목을 제거하고 업데이트된 플레이북에서 직접 호스트 준비 작업을 포함합니다. 마이너 버전 업데이트의 작업은 원하는 순서로 한 번 실행됩니다.

이전에는 사전 프로비저닝된 서버에 오버클라우드를 배포하는 데 사용된 heat 템플릿에 UpgradeInitCommonCommand 매개변수가 없었습니다. 'openstack overcloud upgrade prepare' 명령은 필요한 모든 작업을 수행하지 않아 일부 환경에서 업그레이드하는 동안 문제가 발생했습니다.

이번 업데이트에서는 사전 프로비저닝된 서버에 사용된 템플릿에 UpgradeInitCommonCommand가 추가되어 'openstack overcloud upgrade prepare' 명령이 필요한 작업을 수행할 수 있습니다.

보안을 강화하기 위해 기본 OpenDaylightPassword "admin"이 임의로 생성된 16자리 숫자로 교체되었습니다. heat 템플릿에 암호를 지정하여 임의로 생성된 암호를 덮어쓸 수 있습니다.

cat odl_password.yaml
parameter_defaults:
  OpenDaylightPassword: admin

$ cat odl_password.yaml
parameter_defaults:
  OpenDaylightPassword: admin

그런 다음 파일을 overcloud deploy 명령에 전달합니다.

openstack overcloud deploy <other env files> -e odl_password.yaml

openstack overcloud deploy <other env files> -e odl_password.yaml

Puppet-opendaylight

이전에는 Karaf 쉘(OpenDaylight의 관리 쉘)이 포트 8101의 특정 IP에 바인딩되지 않아 Karaf 쉘이 공용 방향 외부 네트워크에서 수신 대기했습니다. 이로 인해 외부 네트워크를 포트의 OpenDaylight에 액세스하는 데 사용할 수 있으므로 보안 취약점이 생성되었습니다.

이번 업데이트에서는 배포 중에 Karaf 쉘을 내부 API 네트워크 IP에 바인딩하므로 Karaf 쉘은 프라이빗 내부 API 네트워크에서만 액세스할 수 있습니다.