6.8. 네트워킹

OpenStack Networking은 여러 노드에 여러 프로세스를 배포하는 독립 실행형 서비스입니다. 이러한 프로세스는 서로 다른 OpenStack 서비스와 상호 작용합니다. OpenStack Networking 서비스의 주요 프로세스는 OpenStack Networking API를 노출하고 추가 처리를 위해 프로젝트 요청을 플러그인 제품군에 전달하는 Python 데몬인 neutron-server입니다.

OpenStack Networking 구성 요소는 다음과 같습니다.

다음 다이어그램에서는 OpenStack Networking 구성 요소의 아키텍처 및 네트워킹 흐름 다이어그램을 보여줍니다.

View larger image

DVR(Distributed Virtual Routing) 및 L3HA(High Availability)를 사용하면 이 접근 방식이 크게 변경됩니다. L3HA는 라우터 간에 VRRP를 구현하므로 이러한 모드는 neutron의 보안 환경을 변경합니다. VRRP 스푸핑의 위협을 해결하려면 배포의 크기를 올바르게 조정하고 강화하여 라우터 간 로컬 네트워크 트래픽을 민감하게 처리해야 합니다. DVR은 네트워크 노드가 필요한 동안 네트워킹 구성 요소(예: 라우팅)를 컴퓨팅 노드로 이동합니다. 따라서 컴퓨팅 노드에는 공용 네트워크에 대한 액세스 권한이 있어야 하므로, 방화벽 규칙 및 보안 모델이 이 접근 방식을 지원하는지 확인해야 하므로 노출을 늘리고 추가적인 보안 고려가 필요합니다.

이 섹션에서는 컨트롤러 노드, 네트워크 노드 및 인스턴스를 실행하는 계산 노드 집합을 포함하는 표준 아키텍처에 대해 설명합니다. 물리적 서버에 대한 네트워크 연결을 설정하기 위해 일반적인 neutron 배포에는 최대 4개의 개별 물리적 데이터 센터 네트워크가 있습니다.

View larger image

이 트래픽을 별도의 영역으로 분할하는 것이 좋습니다. 자세한 내용은 다음 섹션을 참조하십시오.

중요한 시스템을 서로 분리하기 위해 보안 영역 개념을 사용하는 것이 좋습니다. 실제로는 VLAN 및 방화벽 규칙을 사용하여 네트워크 트래픽을 격리하는 것을 의미합니다. 이 sho uld는 세부적인 세부 정보로 수행되며, 결과적으로 neutron에 연결해야 하는 서비스만 이를 수행할 수 있습니다.

다음 다이어그램에서는 특정 구성 요소를 분리하기 위해 영역이 생성되었음을 확인할 수 있습니다.

View larger image

.

OpenStack 네트워크 인프라를 설계하는 초기 아키텍처 단계에서 적절한 보안 제어 및 감사 메커니즘을 식별하기 위해 ee 물리적 네트워킹 인프라를 설계하는 데 도움이 되는 적절한 전문 지식을 확보하는 것이 중요합니다.

OpenStack Networking은 프로젝트에 고유한 가상 네트워크를 설계할 수 있는 기능을 제공하는 가상화된 네트워크 서비스 계층을 추가합니다. 현재 이러한 가상화된 서비스는 기존 네트워킹보다 성숙하지 않습니다. 가상화된 서비스의 현재 상태를 고려하십시오. 가상화된 서비스의 현재 상태가 가상화되고 기존 네트워크 경계에서 구현해야 하는 컨트롤을 지정하기 때문에 이를 채택하기 전에.

OpenStack Networking은 프로젝트/네트워크 조합에서 트래픽 분리를 위해 서로 다른 두 가지 메커니즘을 사용할 수 있습니다. VXLAN 또는 GRE 캡슐화를 사용하는 VLAN(IEEE 802.1Q 태그 지정) 또는 L2 터널. OpenStack 배포의 범위와 규모는 트래픽 분리 또는 격리에 사용해야 하는 방법을 결정합니다.

VLAN은 특정 VLAN ID(VID) 필드 값이 있는 IEEE 802.1Q 헤더를 포함하는 특정 물리적 네트워크에서 패킷으로 인식됩니다. 동일한 실제 netw ork를 공유하는 VLAN 네트워크는 L2에서 서로 격리되며 겹치는 IP 주소 공간을 가질 수도 있습니다. VLAN 네트워크를 지원하는 개별 실제 네트워크는 고유한 VID 값이 있는 별도의 VLAN trun k로 처리됩니다. 유효한 VID 값은 1 ~ 4094입니다.

VLAN 구성 복잡성은 OpenStack 설계 요구 사항에 따라 다릅니다. OpenStack 네트워킹이 VLAN을 더 효율적으로 사용할 수 있도록 하려면 VLAN 범위(각 프로젝트당 하나씩)를 할당하고 각 컴퓨팅 노드 실제 스위치 포트를 VLAN 트렁크 포트로 설정해야 합니다.

네트워크 터널링은 해당 조합에 속하는 네트워크 트래픽을 식별하는 데 사용되는 고유한 "tunnel-id"와 각 프로젝트/네트워크 조합을 캡슐화합니다. 프로젝트의 L2 네트워크 연결은 물리적 지역 또는 기본 네트워크 설계와 독립적입니다. IP 패킷 내부에 트래픽을 캡슐화하면 해당 트래픽이 계층-3 경계를 통과하여 사전 구성된 VLAN 및 VLAN 트렁킹이 필요하지 않습니다. 터널링은 네트워크 데이터 트래픽에 난독화 계층을 추가하여 개별 프로젝트 트래픽의 가시성을 줄이고 모니터링 지점을 끊습니다.

OpenStack Networking은 현재 GRE 및 VXLAN 캡슐화를 모두 지원합니다. L2 격리를 제공하는 기술 선택은 배포에 생성될 프로젝트 네트워크의 범위와 크기에 따라 달라집니다.

계산에서는 OpenStack Networking 서비스를 사용하여 프로젝트 네트워크 트래픽 액세스 제어를 지원합니다. 보안 그룹을 사용하면 관리자와 프로젝트에서 가상 인터페이스 포트를 통과할 수 있는 트래픽 유형과 방향(수신/송신)을 지정할 수 있습니다. 보안 그룹 규칙은 상태 저장 L2-L4 트래픽 필터입니다.

OpenStack Networking 라우터는 여러 L2 네트워크를 연결할 수 있으며 하나 이상의 사설 L2 네트워크를 공유 외부 네트워크에 연결하는 게이트웨이(예: 인터넷에 액세스할 수 있는 공용 네트워크)를 제공할 수도 있습니다.

L3 라우터는 라우터를 외부 네트워크에 업링크하는 게이트웨이 포트에서 기본 SNAT(Network Address Translation) 기능을 제공합니다. 이 라우터 SNAT(소스 NAT)는 기본적으로 모든 송신 트래픽을 지원하며 유동 IP를 지원합니다. 이 IP는 외부 네트워크의 공용 IP에서 라우터에 연결된 다른 서브넷의 개인 IP로의 정적 일대일 양방향 매핑을 생성합니다. 유동 IP( DNAT를 통해)는 인스턴스에 대한 외부 인바운드 연결을 제공하며 한 인스턴스에서 다른 인스턴스로 이동할 수 있습니다.

프로젝트당 L3 라우팅과 Floating IP를 사용하여 프로젝트 인스턴스를 보다 세부적으로 연결해 보십시오. 공용 네트워크에 연결되거나 유동 IP를 사용하여 특별히 고려해야 합니다. 신중하게 고려한 보안 그룹을 사용하면 외부에 노출되어야 하는 서비스에 대한 액세스를 필터링하는 것이 좋습니다.

기본적으로 QoS(Quality of Service) 정책 및 규칙은 클라우드 관리자가 관리하므로 프로젝트에서 특정 QoS 규칙을 만들거나 포트에 비정형 정책을 연결할 수 없게 됩니다. 일부 통신 애플리케이션과 같은 일부 사용 사례에서는 관리자가 프로젝트를 신뢰하여 ir own 정책을 만들고 포트에 연결할 수 있습니다. 이 작업은 policy.json 파일을 수정하여 수행할 수 있습니다.

Red Hat OpenStack Platform 12에서 neutron은 수신 및 송신 트래픽에 대한 대역폭 제한 QoS 규칙을 지원합니다. 이 QoS 규칙은 QosBandwidthLimitRule 로 명명되며 초당 킬로비트로 측정되는 2개의 부정적 정수를 허용합니다.

QoSBandwidthLimitRule 은 neutron Open vSwitch, Linux 브리지 및 SR-IOV 드라이버에서 구현되었습니다. 그러나 SR-IOV 드라이버의 경우 max-burst-kbps 값이 사용되지 않으며 설정된 경우 무시됩니다.

QoS 규칙 QosDscp MarkingRule 은 IPv4(RFC 2474)의 서비스 헤더 유형과 모든 트래픽에서 IPv6의 트래픽 클래스 헤더를 사용하여 규칙이 적용되는 가상 머신에서 차별화된 서비스 헤더(DSCP) 값을 설정합니다. 이것은 네트워크를 통과할 때 패킷의 드롭 우선 순위를 나타내는 21개의 유효한 값이 있는 6비트 헤더입니다. 방화벽이 올바른 트래픽 또는 유효하지 않은 트래픽과 해당 액세스 제어 목록과 일치하도록 사용할 수도 있습니다.

OpenStack 로드 밸런싱 서비스(octavia)는 Red Hat OpenStack Platform director 설치를 위한 LBaaS(서비스로서의 부하 분산) 구현을 제공합니다. 로드 밸런싱을 달성하기 위해 octavia는 여러 공급업체 드라이버 활성화를 지원합니다. 참조 공급자 드라이버(Amphora 공급자 드라이버)는 오픈 소스, 확장 가능하고 가용성이 높은 로드 밸런싱 공급자입니다. 가상 머신 한 대를 관리하여 부하 분산 서비스를 제공합니다.총체적으로 amphorae-온디맨드로 구동됩니다.

로드 밸런싱 서비스에 대한 자세한 내용은 Using Octavia for Load Balancing-as-a-Service 가이드를 참조하십시오.

이 섹션에서는 OpenStack 배포 내의 프로젝트 네트워크 보안에 적용할 때 OpenStack Networking 구성 모범 사례를 설명합니다.

OpenStack Networking API 서비스가 들어오는 클라이언트 연결을 위해 네트워크 소켓을 바인딩하는 인터페이스 또는 IP 주소를 제한하려면 /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf 파일에 bind_host 및 bind_por t 를 지정합니다.

Address to bind the API server
Port the bind the API server to

# Address to bind the API server
bind_host = IP ADDRESS OF SERVER

# Port the bind the API server to
bind_port = 9696

OpenStack Networking 서비스의 다양한 구성 요소는 메시징 대기열 또는 데이터베이스 연결을 사용하여 OpenStack Networking의 다른 구성 요소와 통신합니다.

OpenStack Networking은 사용자에게 네트워크 리소스의 셀프 서비스 구성을 제공합니다. 클라우드 아키텍트와 운영자는 사용자에게 사용 가능한 네트워크 리소스를 생성, 업데이트 및 삭제할 수 있는 기능을 제공하는 데 있어 설계 활용 사례를 평가하는 것이 중요합니다.

OpenStack 네트워킹 내의 정책 엔진 및 해당 구성 파일(policy.json)은 프로젝트 네트워킹 방법 및 오브젝트에 대한 사용자의 더 세분화된 권한 부여를 제공하는 방법을 제공합니다. OpenStack N 외작업 정책 정의는 네트워크 가용성, 네트워크 보안 및 전반적인 OpenStack 보안에 영향을 미칩니다. 클라우드 아키텍트와 운영자는 네트워크 리소스 관리에 대한 사용자 및 프로젝트 액세스 권한을 신중하게 평가해야 합니다.

OpenStack 배포에서 여러 다른 보안 영역에 여러 외부 액세스 지점을 제공하는 경우 프로젝트의 여러 vNIC를 여러 외부 액세스 po intsTI에 연결하는 기능을 제한하는 것이 중요합니다. 이 기능은 이러한 보안 영역을 브리지하고 예기치 않은 보안 손상으로 이어질 수 있습니다. Compute(컴퓨팅)에서 제공하는 호스트 집계 기능을 사용하거나 e 프로젝트 인스턴스를 서로 다른 가상 네트워크 구성으로 여러 프로젝트로 분할하여 이러한 위험을 완화할 수 있습니다. 호스트 집계에 대한 자세한 내용은 https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html/configuring_the_compute_service_for_instance_creation/crea ting-and-managing-host-aggregates[호스트 집계 및 관리] 링크를 참조하십시오.

보안 그룹은 보안 그룹 규칙의 컬렉션입니다. 보안 그룹 및 해당 규칙을 사용하면 관리자와 프로젝트에서 ed가 가상 인터페이스 포트를 통과할 수 있는 트래픽 유형과 방향(수신/송신)을 지정할 수 있습니다. OpenStack Networking에서 가상 인터페이스 포트를 만들면 보안 그룹과 연결됩니다. 배포별로 동작을 변경하기 위해 규칙을 default 보안 그룹에 추가할 수 있습니다.

계산 API를 사용하여 보안 그룹을 수정하는 경우 업데이트된 보안 그룹은 인스턴스의 모든 가상 인터페이스 포트에 적용됩니다. 이는 neutron에서 볼 수 있듯이 계산 보안 그룹 API가 포트 기반이 아닌 인스턴스 기반이기 때문입니다.

할당량은 프로젝트에 사용할 수 있는 네트워크 리소스 수를 제한하는 기능을 제공합니다. 모든 프로젝트에 기본 할당량을 적용할 수 있습니다. 할당량 옵션을 검토하려면 /var/lib/config-data/puppet-generated /neutron/etc/neutron/neutron.conf 를 참조하십시오.

OpenStack Networking은 할당량 확장 API를 통해 프로젝트별 할당량 제한도 지원합니다. 프로젝트별 할당량을 사용하려면 /var/lib/config-data/puppet-generated/neutron/e tc/neutron/neutron.conf 에 quota _driver 옵션을 설정해야 합니다. 예를 들면 다음과 같습니다.

quota_driver = neutron.db.quota_db.DbQuotaDriver

quota_driver = neutron.db.quota_db.DbQuotaDriver

OpenStack Networking에는 인스턴스에 대한 ARP 스푸핑의 위협을 완화하는 데 도움이 되는 기능이 내장되어 있습니다. 결과적으로 발생하는 위험에 대해 신중하게 고려하지 않는 한 이 작업을 비활성화해서는 안 됩니다.

구성 파일에는 구성 요소의 원활한 작동에 필요한 중요한 매개 변수 및 정보가 포함되어 있습니다. 권한이 없는 사용자가 의도하거나 실수로 매개변수 또는 파일 자체를 수정하거나 삭제하는 경우 심각한 가용성 문제로 인해 다른 최종 사용자에게 서비스 거부가 발생합니다. 따라서 이러한 중요한 구성 파일의 사용자 소유권을 root로 설정하고 그룹 소유권을 neutron으로 설정해야 합니다.

호스트에 neutron 그룹이 없습니다. ls -l 을 사용하면 그룹 소유자의 GID가 표시됩니다.

sudo ls -l /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf
-rw-r-----. 1 root 42435 41748 Dec 11 09:34 /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf

sudo stat -L -c "%U %G" /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf
root UNKNOWN

sudo ls -l /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf
-rw-r-----. 1 root 42435 41748 Dec 11 09:34 /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf

sudo stat -L -c "%U %G" /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf
root UNKNOWN

neuton.conf 구성 파일의 사용자 및 그룹 소유권이 각각 root 및 neutron 으로 설정되어 있는지 확인합니다.

sudo docker exec -it neutron_api stat -L -c "%U %G" /etc/neutron/neutron.conf
root neutron

sudo docker exec -it neutron_api stat -L -c "%U %G" /etc/neutron/neutron.conf
root neutron

neutron.conf 설정 파일의 권한이 640 으로 설정되었는지 확인합니다.

stat -L -c "%a" /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf

$ stat -L -c "%a" /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf

/var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf 에서 [DEFAULT] 섹션 아래의 auth_strategy 값이 keystone 으로 설정되었고 noauth 또는 noauth 2 가 아닌지 확인합니다.

/var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf 에서 [keystone _authtoken] 섹션 아래의 auth_ uri 값이 https로 시작하는 ID API 끝점으로 설정되어 있는지 확인합니다.

/var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf 에서 [DEFAULT] 섹션 아래의 매개변수 use_ssl 이 True 로 설정되어 있는지 확인합니다.