지난 편에서 CPU 함정을 넘었습니다. 하지만 그건 시작이었습니다. DevStack이 완주할 때까지 Neutron → Glance → Nova/Placement에서 연달아 막혔거든요. 이번 편은 그 실제 에러들과 원인, 그리고 관통하는 하나의 패턴을 정리합니다. 같은 벽을 만난 분께 지도가 되길 바랍니다.
벽 2. 테넌트 네트워크 생성 실패 (503)
다시 돌리자 이번엔 네트워크 생성에서 죽었습니다.
HttpException: 503: No project network is available for allocation.
서비스·네트워크·이미지가 다 됐는데 인스턴스가 ERROR. 이유는 “No valid host was found”. 하이퍼바이저는 up인데 왜? nova-compute 로그가 진짜 원인을 보여줬습니다.
400 Bad Request: Unknown resource class in inventory ...
No such resource class MEMORY_MB.
즉 placement DB에 표준 자원 클래스(MEMORY_MB·VCPU·DISK_GB)가 로드되지 않아서, nova-compute가 자원 인벤토리를 placement에 등록하지 못했습니다. 인벤토리가 없으니 스케줄러가 “쓸 수 있는 호스트 없음”으로 판단한 거죠.
관통하는 하나의 패턴
벽 3·4·5를 보면 공통점이 보입니다.
서비스 프로세스는 떠 있는데, 그 뒤에 와야 할 “초기화·동기화·등록”이 안 끝나 있다.
geneve 풀 동기화, glance 엔드포인트, placement 자원 클래스 — 전부 stack.sh가 끝까지 완주하며 해줬어야 할 마무리 단계입니다. 제 경우 stack.sh가 중간에 여러 번 죽으면서 이 마무리들이 제각각 미완성으로 남았고, 그래서 재시도할 때마다 “부분적으로만 살아있는” 상태가 겹쳐 새 증상이 계속 튀어나온 겁니다.
여기서 배운 교훈: DevStack은 “깨끗한 상태에서 한 번에 완주”가 생명입니다. 중간 실패 후 그 위에 계속 재시도하면, 서로 다른 실행의 잔재가 섞여 디버깅이 미궁에 빠집니다. 다음 편에서 이 교훈과 현실적인 후기를 정리하겠습니다.
OpenStack을 공부하다 보면 대부분 Neutron(네트워킹)에서 벽을 만납니다. 저도 그랬습니다. 컴퓨트·스토리지는 직관적인데, 네트워크는 개념이 겹겹이라 헷갈리죠. 이번 글은 홈랩 랩에서 삽질하며 정리한 Neutron 핵심 개념 지도입니다. 이거 하나 잡으면 OpenStack의 절반은 끝납니다.
1. 왜 Neutron이 어려운가
Neutron은 소프트웨어로 네트워크(스위치·라우터·방화벽)를 통째로 구현합니다(SDN). 물리 네트워크 지식 + 가상 네트워크 개념 + 여러 에이전트가 한꺼번에 얽혀서 어렵게 느껴지는 겁니다. 그래서 개념을 계층으로 쪼개서 봐야 합니다.
2. 두 가지 네트워크 — Provider vs Tenant
Provider 네트워크
Tenant(Project) 네트워크
정체
기존 물리망에 직접 연결
프로젝트별 격리된 가상망
관리 주체
관리자
사용자(테넌트)
용도
외부와 바로 통신
내부 인스턴스끼리
격리
없음(공용)
VLAN/VXLAN으로 격리
쉽게 말해 Provider는 “회사 실제 네트워크에 꽂는 선”, Tenant는 “내 프로젝트만의 사설망”입니다. 실제 클라우드에선 테넌트망(사설) + 라우터 + 외부 provider망 조합을 가장 많이 씁니다.
3. 핵심 구성요소
ML2 플러그인 + L2 에이전트: 실제 스위칭 담당(Open vSwitch 또는 Linux Bridge). VLAN/VXLAN으로 망을 나눔.
L3 에이전트: 가상 라우터. 테넌트망 ↔ 외부망 라우팅, Floating IP 처리.
DHCP 에이전트: 인스턴스에 IP 자동 할당.
Security Group: 인스턴스 단위 방화벽(포트 허용/차단).
4. Floating IP — 외부 접속의 핵심
인스턴스는 보통 사설 IP만 가집니다. 외부에서 접속하려면 Floating IP(외부망의 공인/실 IP)를 인스턴스에 “붙였다 뗐다” 합니다. 개념이 NAT과 같아서, Floating IP ↔ 인스턴스 사설 IP를 라우터(L3 에이전트)가 매핑합니다.
외부 사용자 → Floating IP(외부망) → [L3 라우터/NAT] → 인스턴스 사설 IP
“인스턴스는 만들었는데 SSH가 안 돼요”의 99%는 Floating IP 미할당 + Security Group에서 22번 미허용입니다. 이 둘을 먼저 확인하세요.
5. 홈랩 랩에서의 배치
컨트롤러: neutron-server(API) + DHCP/L3 에이전트
컴퓨트: L2 에이전트(OVS/Linux Bridge)만
외부망은 Proxmox의 Linux Bridge(vmbr)에 물려 provider 네트워크로 노출
즉 Proxmox의 브리지가 OpenStack provider 네트워크의 물리 기반이 됩니다. 중첩 구조라 처음엔 헷갈리지만, “Proxmox 브리지 = 물리망, 그 위에 Neutron 가상망”으로 이해하면 정리됩니다.
6. 공부 순서
Provider 네트워크부터: 기존 망에 인스턴스를 직접 붙여 “통신되는 것”을 먼저 경험.
Tenant 네트워크 + 라우터: 사설망을 만들고 라우터로 외부와 연결.
Floating IP + Security Group: 외부 접속과 방화벽까지.
7. 정리
Neutron은 “Provider(실제망) vs Tenant(가상 사설망)”와 “L2(스위칭)·L3(라우팅/Floating IP)·Security Group(방화벽)”이라는 두 축으로 나눠 보면 정리됩니다. 외부 접속이 안 될 땐 Floating IP와 Security Group부터. 이 구조가 손에 익으면 OpenStack이 훨씬 만만해집니다.
OpenStack을 처음 보면 Nova, Neutron, Cinder, Keystone, Glance… 낯선 이름에 압도됩니다. 하지만 각각이 “클라우드의 한 부품”이라고 생각하면 의외로 명료합니다. 제가 홈랩 랩에서 공부하며 정리한, 핵심 컴포넌트 지도를 공유합니다.
1. 컴포넌트 한눈에
컴포넌트
역할
익숙한 비유
Keystone
인증·권한(Identity)
로그인·출입증
Glance
OS 이미지 저장소
설치 ISO 창고
Nova
컴퓨트(인스턴스 생성)
VM을 찍어내는 공장
Neutron
네트워킹(가상 네트워크)
가상 스위치·라우터
Cinder
블록 스토리지(볼륨)
붙였다 뗐다 하는 디스크
Horizon
웹 대시보드
관리 콘솔
여기에 오브젝트 스토리지 Swift, 오케스트레이션 Heat 등이 더 있지만, 위 6개가 “인스턴스 하나 띄우기”의 핵심입니다.
2. 인스턴스 하나 띄울 때 무슨 일이 벌어지나
컴포넌트가 어떻게 맞물리는지는 “VM 하나 생성” 흐름을 따라가면 단번에 이해됩니다.
1) 사용자 → Keystone 에 로그인 → 토큰 발급 (이후 모든 요청에 사용)
2) Nova 에 "인스턴스 생성" 요청
3) Nova → Glance 에서 OS 이미지 가져옴
4) Nova → Neutron 에 네트워크/포트 요청 (IP 할당)
5) (선택) Nova → Cinder 에서 볼륨 붙임
6) Nova 스케줄러가 적당한 compute 노드 선택 → VM 부팅
7) Horizon 대시보드에서 상태 확인
즉 Keystone(인증)으로 문을 열고 → Nova(컴퓨트)가 지휘하면서 → Glance(이미지)·Neutron(네트워크)·Cinder(볼륨)를 불러다 조립하는 구조입니다. 이 흐름 하나만 머리에 넣으면 나머지가 술술 풀립니다.
컴퓨트 노드: Nova-compute·Neutron 에이전트 — 실제 인스턴스가 여기서 돎
스토리지: Cinder 백엔드(LVM/Ceph 등)
그래서 컨트롤러는 CPU·메모리를, 컴퓨트는 인스턴스용 자원을 더 챙겨줘야 합니다. 제 랩에서 컴퓨트 노드에 RAM을 더 준 이유가 이것입니다.
4. 공부 순서 추천
Keystone부터: 인증이 안 되면 아무것도 안 됩니다. 토큰·프로젝트·롤 개념 먼저.
Glance → Nova: 이미지 올리고 인스턴스 하나 띄워보기(성취감 큼).
Neutron: 가장 어렵습니다. 네트워크가 되면 절반은 끝난 것.
Cinder: 볼륨 붙이기까지 하면 기본은 완성.
5. 정리
OpenStack은 이름이 많아 겁나 보이지만, “인증(Keystone) → 컴퓨트(Nova)가 이미지·네트워크·볼륨을 조립”이라는 큰 그림 하나면 충분히 잡힙니다. 각 컴포넌트를 따로 외우지 말고, 인스턴스 생성 흐름 속에서 이해하세요. 홈랩 랩에서 직접 인스턴스를 한 번 띄워보면 이 모든 게 손에 익습니다.
OpenStack 프로젝트 테넌트 격리는 멀티테넌트 환경에서 가장 먼저 다져야 하는 기본기입니다. 겉으로는 프로젝트만 나누면 끝나 보이지만, 실제 운영에 들어가면 네트워크, 권한, 이미지, 볼륨, 스케줄링까지 같이 봐야 하더라고요. 저도 초반에는 프로젝트만 분리하면 충분하다고 생각했는데, 나중에 보니 공유 네트워크 하나가 경계를 흐리는 경우가 있었습니다.
이번 글에서는 OpenStack 프로젝트 테넌트 격리를 어디까지 논리적으로 나눌지, 어디서부터 물리적 성격의 분리를 추가할지 비교해보겠습니다. 체크리스트만 훑는 글이 아니라, OpenStack 보안 관점에서 무엇을 먼저 적용해야 하는지와 테넌트 분리 수준별 운영 비용까지 같이 정리해보겠습니다.
프로젝트, 네트워크, 하이퍼바이저, 스토리지 계층이 어떻게 분리되는지 한눈에 보여주는 아키텍처 이미지입니다.
왜 OpenStack 프로젝트 테넌트 격리에서 프로젝트만 나누면 끝이 아닐까
쉽게 말해 프로젝트는 행정 구역에 가깝고, 실제 경계는 따로 있습니다. 사용자는 프로젝트 기준으로 자원을 보지만, 패킷 흐름, 이미지 접근 권한, 볼륨 연결, 컴퓨트 노드 배치까지 자동으로 다 분리되지는 않거든요. 그래서 프로젝트 분리는 출발점일 뿐이고, 그 바깥 계층을 같이 설계해야 실전에서 흔들리지 않습니다.
Identity: 누가 어떤 프로젝트에 들어갈 수 있는지 결정합니다.
Network: 테넌트 간 동서 트래픽을 제어하는 핵심 축입니다.
Compute: 같은 하이퍼바이저에 섞을지, 분리할지 정합니다.
Storage: 이미지와 볼륨이 의도치 않게 공유되지 않도록 막아야 합니다.
Policy/RBAC: 운영자 권한이 지나치게 넓으면 격리 설계가 쉽게 무너집니다.
운영해보면 사고는 화려한 기능보다 기본 설정 하나를 공유 상태로 둔 채 지나간 부분에서 더 자주 납니다. 특히 Horizon과 CLI로 만든 리소스가 섞이면 누가 무엇을 어떤 의도로 공유했는지 추적이 꽤 까다롭습니다. 이 지점이 생각보다 중요하더라고요.
OpenStack 프로젝트 테넌트 격리 전략, 4단계로 나눠서 보기
현업에서는 보통 4단계로 나눠 봅니다. 아래 표는 설계 검토할 때 바로 가져다 쓰기 좋은 기준에 가깝습니다.
전략
핵심 방식
격리 강도
운영 복잡도
추천 상황
주의 포인트
기본 논리 분리
프로젝트, 사용자, 보안 그룹 분리
중간
낮음
사내 개발/테스트 환경
공유 네트워크나 공개 이미지가 남아 있으면 경계가 약해집니다.
네트워크 중심 분리
프로젝트별 네트워크, 라우터, RBAC 최소화
높음
중간
팀 간 독립 운영, 고객 분리
외부망 연결 방식과 Floating IP 정책을 같이 봐야 합니다.
컴퓨트 배치 분리
Host Aggregate, Availability Zone 분리
높음
중간~높음
규제 대응, noisy neighbor 완화
스케줄링 정책과 리소스 부족 시 예외 처리 기준이 필요합니다.
스토리지/암호화 포함 강한 분리
볼륨 타입 분리, 암호화, 이미지 접근 제한
매우 높음
높음
민감 데이터, 외부 고객 서비스
키 관리와 백업 경로까지 같이 분리해야 효과가 살아납니다.
핵심은 단순합니다. OpenStack 보안은 기능 하나로 끝나지 않습니다. 프로젝트 분리는 시작이고, 네트워크와 권한 모델을 어떻게 묶느냐가 실제 체감 보안을 좌우합니다.
기본 골격: 프로젝트, 사용자, 권한부터 단단하게
처음 설계할 때는 프로젝트를 조직 단위로만 나누기 쉬운데, 실제로 써보면 환경 단위(dev, stage, prod)까지 별도 프로젝트로 자르는 편이 운영이 훨씬 편합니다. 같은 팀이라도 운영 환경과 개발 환경이 섞이면 이미지 공유나 보안 그룹 재사용이 자연스럽게 생기거든요. 나중에 감사나 장애 대응 때 차이가 꽤 크게 납니다.
프로젝트를 환경 또는 고객 기준으로 분리합니다.
사용자는 최소 권한 원칙에 맞춰 필요한 프로젝트에만 넣습니다.
운영자 계정은 범용 admin 하나로 뭉개지 말고 역할을 나눕니다.
공유 리소스는 허용보다 금지를 기본값으로 잡습니다.
openstack project create prod-team-a
openstack user create --project prod-team-a --password-prompt teama-admin
openstack role add --project prod-team-a --user teama-admin member
openstack project create dev-team-a
openstack user create --project dev-team-a --password-prompt teama-dev
openstack role add --project dev-team-a --user teama-dev member
openstack role assignment list --project prod-team-a --names
openstack quota show prod-team-a
위 명령은 모두 OpenStackClient에서 일반적으로 사용하는 기본 흐름입니다. 다만 수동으로 반복 생성하기 시작하면 프로젝트마다 quota나 역할 구성이 조금씩 달라지기 쉽습니다. 이게 나중에 제일 사람을 힘들게 하더라고요.
판단 기준도 같이 기억해두면 좋습니다.
role assignment list 결과에 예상하지 못한 admin 계열 역할이 보이면 권한 과다를 먼저 의심합니다.
quota show가 비어 있거나 기본값만 따라가면 특정 테넌트의 자원 폭주를 제어하기 어렵습니다.
운영자 공용 계정을 여러 팀이 함께 쓰면 추적성이 크게 떨어집니다.
OpenStack 프로젝트 테넌트 격리에서 실전 차이는 네트워크 분리에서 난다
프로젝트를 나눠도 네트워크가 공유되면 체감상 같은 건물에 문패만 바꿔 다는 수준이 됩니다. 그래서 멀티테넌트 환경에서는 프로젝트별 자체 네트워크와 자체 라우터를 기본값으로 두는 편이 안전합니다. 공유 네트워크나 RBAC 공유는 예외 승인 방식으로 돌리는 게 번거로워 보여도, 사고 예방 효과는 확실합니다.
이 구간에서 자주 나오는 실수도 비슷합니다. 외부 게이트웨이만 다르면 충분하다고 생각하거나, 보안 그룹 규칙을 여러 프로젝트에서 관성적으로 복사해 쓰는 경우죠. 처음엔 편한데 규칙이 커질수록 누가 왜 열었는지 설명이 안 됩니다.
각 프로젝트가 독립된 네트워크와 라우터를 가지며, 외부망은 공용이더라도 내부 통신 경계는 분리되는 구조를 보여주는 이미지입니다.
운영하다 보면 테스트 서버 때문에 0.0.0.0/0로 SSH를 잠깐 열어뒀는데, 비슷한 규칙이 운영 프로젝트에도 따라 들어간 경우가 꼭 생깁니다. 이런 경험 한 번쯤 있으실 겁니다. 그래서 보안 그룹은 템플릿화하되, 프로젝트별 별도 객체로 관리하는 편이 훨씬 낫더라고요.
재현 가능한 시나리오 하나
예를 들어 팀 A와 팀 B가 같은 클라우드를 쓰고 있는데, 운영자가 편의를 위해 하나의 공유 네트워크를 두 프로젝트에 RBAC로 열어뒀다고 가정해보겠습니다. 그 상태에서 두 팀의 인스턴스가 같은 L2 세그먼트에 붙고 보안 그룹 규칙까지 느슨하면, 동서 통신이 예상보다 넓게 열릴 수 있습니다. 이럴 때는 아래 순서로 확인하면 됩니다.
openstack network show <network>로 네트워크 소유자와 공유 상태를 확인합니다.
openstack network rbac list에서 어떤 프로젝트에 접근이 열려 있는지 봅니다.
openstack port list --project <project>로 각 프로젝트 포트가 어느 네트워크에 붙었는지 추적합니다.
여기서 중요한 건 숫자보다 의도하지 않은 연결 관계입니다. 보안 진단은 평균값을 보는 작업이라기보다 예외 케이스를 집요하게 확인하는 작업에 가깝습니다.
한 단계 더: 컴퓨트와 스토리지까지 분리해야 하는 경우
여기서부터는 고객 성격에 따라 판단이 갈립니다. 같은 하이퍼바이저에 다른 고객 워크로드가 같이 올라가도 되는지, 볼륨 백엔드가 완전히 공용이어도 되는지 따져봐야 하거든요. 규제 대응이나 민감한 데이터가 있다면 논리 분리만으로는 설명이 부족한 경우가 많습니다.
Availability Zone: 프로젝트별 또는 업무별 배치 경계를 만듭니다.
Host Aggregate: 특정 컴퓨트 노드 그룹으로 스케줄링합니다.
Volume Type: 성능, 백엔드, 암호화 정책을 나눕니다.
Image 접근 제어: 공개 이미지와 공유 이미지를 최소화합니다.
openstack aggregate create team-a-aggregate
openstack aggregate add host team-a-aggregate compute-01
openstack aggregate add host team-a-aggregate compute-02
openstack aggregate set --zone team-a-az team-a-aggregate
openstack volume type list
openstack image list --public
openstack image list --shared
openstack image show <image-id>
명령 자체는 단순해 보여도 운영 포인트는 따로 있습니다. 스케줄링 실패 로그를 어떻게 해석할지 기준을 정해두지 않으면, 인스턴스 생성 실패를 무조건 리소스 부족으로만 보기 쉽습니다. 실제로는 aggregate 메타데이터나 AZ 선택이 맞지 않아 배치가 막히는 경우도 많습니다.
이미지 공개 설정도 꼭 봐야 합니다. 프로젝트 격리를 열심히 해놨는데 public 또는 shared 이미지 안에 민감한 에이전트 설정이나 초기 계정 스크립트가 들어 있으면 다른 종류의 사고가 됩니다. 그래서 golden image를 쓰더라도 공개 범위는 아주 좁게 잡는 편이 안전합니다.
특정 프로젝트가 전용 컴퓨트 노드 그룹과 가용 영역으로 스케줄링되는 모습을 설명하는 이미지입니다.
자주 봤던 문제와 해결 방법
문서만 보면 구조가 깔끔해 보이지만, 실무에서는 늘 예외가 먼저 튀어나옵니다. 아래 네 가지는 멀티테넌트 환경에서 정말 자주 만나는 문제입니다.
1. 공유 리소스가 남아 있는 경우
가장 흔합니다. 네트워크, 이미지, 보안 그룹 템플릿 운영 방식 중 하나라도 사실상 공유 상태로 굴러가면 경계가 흐려집니다. 해결책은 단순합니다. 기본값을 비공유로 두고, 필요한 경우만 승인 절차로 열기입니다.
2. 운영자 권한이 너무 넓은 경우
도와주려고 준 권한이 나중에는 우회 경로가 됩니다. 도메인 관리자와 클라우드 관리자 역할을 분리하지 않으면 프로젝트 격리의 의미가 금방 약해집니다. 이 부분은 생각보다 체감 차이가 큽니다.
3. 보안 그룹을 방화벽처럼 과신하는 경우
보안 그룹은 중요하지만 전부는 아닙니다. 라우팅, 포트 소유, Floating IP 정책, 메타데이터 서비스 접근 제어까지 같이 봐야 합니다. 보안 그룹 하나로 다 해결하려고 하면 운영이 오히려 꼬입니다.
4. 로그는 있는데 읽는 기준이 없는 경우
이 문제도 꽤 큽니다. 예를 들어 인스턴스가 의도한 AZ에 올라가지 않았다면, 단순 실패로 넘기지 말고 격리 정책이 실제로 작동 중인지 또는 예외 정책이 필요한지를 같이 판단해야 합니다. 장애 대응 문서에는 아래 체크 순서를 넣어두면 도움이 됩니다.
네트워크 문제면 포트 소속 프로젝트와 보안 그룹 규칙부터 확인
배치 문제면 AZ, aggregate, flavor extra spec 사용 여부 확인
스토리지 문제면 volume type과 백엔드 정책 일치 여부 확인
처음엔 체크 항목이 많아 보여도, 순서를 정해두면 대응 속도가 확실히 빨라집니다. 이런 건 실제로 해보면 차이가 바로 느껴집니다.
검증은 이렇게 합니다: 설정 확인보다 경계 확인
OpenStack 프로젝트 테넌트 격리가 잘 됐는지 보려면 리소스가 생성됐는지만 보면 부족합니다. 다른 프로젝트 사용자 입장에서 안 보여야 할 것이 정말 안 보이는지, 붙으면 안 되는 네트워크가 실제로 안 붙는지까지 확인해야 합니다. 결국 중요한 건 설정값이 아니라 경계가 의도대로 작동하는지입니다.
프로젝트 A 계정으로 로그인해 프로젝트 B의 네트워크, 인스턴스, 볼륨이 보이는지 확인합니다.
RBAC 목록에서 예상하지 못한 공유 규칙이 없는지 확인합니다.
공개 이미지와 공유 이미지 목록을 각각 점검합니다.
보안 그룹 규칙에 과도한 Any 규칙이 없는지 확인합니다.
openstack server list --project prod-team-a
openstack network list --project prod-team-a
openstack port list --project prod-team-a
openstack volume list --project prod-team-a
openstack image list --private
openstack image list --public
openstack image list --shared
openstack network rbac list
해석 기준은 이렇습니다.
보이면 안 되는 타 프로젝트 리소스가 보이면 Identity 또는 공유 정책 점검이 먼저입니다.
프로젝트 전용 네트워크가 아닌 공용 네트워크에 포트가 붙어 있으면 설계 예외인지 설정 누락인지 바로 구분해야 합니다.
공개 이미지나 공유 이미지가 과도하게 많으면 이미지 배포 체계를 다시 잡는 편이 좋습니다.
보안 그룹에 광범위한 인바운드 규칙이 있으면 앞단 제어 계층까지 같이 검토하는 게 안전합니다.
프로젝트별 리소스 목록, RBAC 규칙, 공개 이미지 수를 점검하는 운영 검증 화면을 표현한 이미지입니다.
비교해보면, 어떤 전략을 선택해야 할까
이쯤 되면 선택 기준이 조금 선명해집니다. 모든 환경에 최고 강도의 분리를 넣는다고 꼭 좋은 건 아닙니다. 운영 복잡도가 확 올라가거든요. 반대로 고객 서비스나 민감 데이터 환경인데 기본 논리 분리만 두는 것도 위험합니다.
환경
추천 격리 수준
이유
추가 권고
사내 개발/테스트
프로젝트 + 네트워크 분리
운영 부담을 크게 늘리지 않으면서도 사고 범위를 줄일 수 있습니다.
공유 리소스 승인 절차는 반드시 둡니다.
운영 서비스
프로젝트 + 네트워크 + 이미지 통제
서비스 간 영향 최소화와 변경 추적이 중요합니다.
보안 그룹 템플릿과 quota 정책을 같이 표준화합니다.
외부 고객 멀티테넌트
프로젝트 + 네트워크 + 컴퓨트 분리
고객 간 경계와 noisy neighbor 대응이 필요합니다.
AZ, aggregate, 운영자 역할 분리를 같이 적용합니다.
민감 정보/규제 환경
전 계층 분리 + 스토리지 암호화
논리 분리만으로는 설명 책임이 부족할 수 있습니다.
백업, 키 관리, 감사 로그 보존 정책까지 묶어 설계합니다.
이 표는 정답표라기보다, 실제 운영에서 어디까지 해야 충분한지 가늠하는 기준점에 가깝습니다. 저도 가벼운 실험 환경에서는 단순하게 갔지만, 운영 환경으로 갈수록 네트워크와 권한 모델을 먼저 단단히 다지는 쪽이 결과가 좋았습니다.
FAQ: OpenStack 프로젝트 테넌트 격리에서 헷갈리는 포인트
프로젝트만 나누면 테넌트 분리가 끝난 건가요?
아닙니다. 프로젝트는 시작점입니다. 네트워크 공유, 이미지 공개 또는 공유, 운영자 권한 범위가 남아 있으면 경계가 충분하지 않을 수 있습니다.
보안 그룹만 잘 쓰면 되지 않나요?
보안 그룹은 중요하지만 전부가 아닙니다. 라우터, RBAC, 이미지 접근, 컴퓨트 배치까지 같이 봐야 진짜 클라우드 보안이 됩니다.
가용 영역 분리는 언제 필요할까요?
고객별 워크로드 분리, 규제 대응, 성능 간섭 완화가 필요할 때 고려합니다. 다만 운영 복잡도가 올라가니 일반 개발 환경에는 과할 수 있습니다.
현업 기준으로 권고를 딱 정리하면
팀 내부 개발 환경이라면 프로젝트 분리, 프로젝트별 네트워크, 최소 권한 모델까지만 해도 효과가 큽니다. 이 조합이 운영 부담 대비 효율이 가장 좋습니다. 반면 외부 고객이 함께 쓰는 멀티테넌트 클라우드라면 여기서 멈추기 아쉽습니다. 그 경우에는 네트워크 공유 금지, 이미지 공개 최소화, AZ 또는 Host Aggregate 기반 배치 분리까지 넣는 편이 맞습니다.
민감 데이터가 있는 서비스라면 더 분명합니다. 스토리지 암호화와 볼륨 타입 분리까지 포함해 전 계층으로 끌고 가는 게 낫습니다. 운영은 조금 복잡해져도, 사고 이후 설명 비용보다 훨씬 싸게 먹힙니다. 다음 글에서는 Keystone 역할 설계와 서비스 계정 분리 패턴도 다뤄보겠습니다. 이전 글의 보안 그룹 운영 기준과 함께 보면 흐름이 더 잘 잡힐 겁니다.
개발, 운영, 외부 고객, 민감 정보 환경별로 어떤 격리 전략을 선택해야 하는지 요약한 인포그래픽 이미지입니다.
오픈스택 운영 회고라는 주제로 글을 쓰게 된 이유는 단순합니다. 3년 정도 직접 굴려보니, 처음 기대했던 것과 실제 운영에서 마주치는 현실이 꽤 다르더라고요. 처음엔 “우리도 프라이빗 클라우드(Private Cloud, 사설 클라우드) 하나 제대로 만들어보자” 하고 시작했는데, 막상 돌려보면 기술보다 운영 체력이 더 중요했습니다. 특히 오픈스택 안정성, 클라우드 비용, 그리고 팀의 인프라 관리 방식이 서로 얽혀 있어서, 한 군데만 잘한다고 끝나지 않거든요.
제가 직접 해보니 오픈스택은 분명히 강력합니다. 하지만 강력하다는 말이 곧 편하다는 뜻은 아니었습니다. 기능은 많고 유연성도 높지만, 그만큼 설계와 운영 기준이 없으면 금방 복잡도가 올라갑니다. 혹시 지금 오픈스택 도입을 고민 중이시거나, 이미 운영 중인데 “왜 이렇게 손이 많이 가지?” 싶은 분이라면 오늘 글이 꽤 현실적인 체크리스트가 될 겁니다.
컨트롤 플레인과 컴퓨트, 스토리지, 네트워크가 어떻게 나뉘는지 한눈에 보여주는 아키텍처 이미지입니다.
오픈스택 운영 회고를 시작하기 전에: 쉽게 말해 오픈스택이란?
쉽게 말해 오픈스택(OpenStack)은 가상 서버, 네트워크, 스토리지 같은 인프라 자원을 API로 다루게 해주는 클라우드 운영 프레임워크입니다. 퍼블릭 클라우드(Public Cloud, 공개형 클라우드)에서 버튼 몇 번으로 VM을 만드는 경험을, 우리 데이터센터나 사내 서버 환경에서 구현한다고 생각하시면 이해가 빠릅니다.
근데 여기서 오해하면 안 되는 게 하나 있어요. 오픈스택은 제품 하나를 설치하면 끝나는 패키지가 아니라, 여러 컴포넌트가 맞물려 돌아가는 생태계에 가깝습니다. 예를 들면 Nova(노바, 컴퓨트 관리), Neutron(뉴트론, 네트워크 관리), Cinder(신더, 블록 스토리지), Glance(글랜스, 이미지 관리), Keystone(키스톤, 인증) 같은 서비스가 서로 의존합니다. 처음엔 이게 뭔가 싶었는데, 실제로 써보니까 문제 하나가 다른 레이어로 전파되는 경우가 많아서 구조를 이해하는 게 정말 중요했습니다.
영역
대표 컴포넌트
역할
운영 포인트
인증
Keystone
사용자와 서비스 인증
토큰, 권한, 서비스 엔드포인트 정리
컴퓨트
Nova
가상머신 생성과 스케줄링
하이퍼바이저 상태, 배치 정책 확인
네트워크
Neutron
가상 네트워크와 라우팅
장애 시 추적 난도가 높음
스토리지
Cinder, Swift
블록/오브젝트 스토리지 제공
백엔드 성능과 장애 복구 설계 중요
이미지
Glance
VM 이미지 관리
이미지 표준화가 운영 품질 좌우
3년 운영하면서 느낀 핵심: 안정성은 소프트웨어보다 운영 기준에서 나옵니다
여기서 중요한 포인트! 많은 분들이 오픈스택 안정성을 이야기할 때 소프트웨어 자체의 완성도만 떠올리시는데, 제 경험상 운영 결과를 가르는 건 오히려 다음 세 가지였습니다.
변경 관리(Change Management, 변경 관리)가 있는가
관측성(Observability, 모니터링/로그/메트릭 가시성)이 충분한가
장애 복구 시나리오를 문서가 아니라 실제로 검증했는가
처음 1년은 솔직히 삽질 좀 했습니다 ㅎㅎ 서비스는 떠 있는데 사용자 입장에서는 VM이 안 만들어지고, 네트워크는 붙은 것처럼 보이는데 외부 통신이 안 되고, 스토리지는 정상인데 attach가 지연되는 식의 애매한 문제가 많았거든요. 그때 깨달은 게 있습니다. 오픈스택은 장애가 안 나는 시스템이 아니라, 장애를 빨리 좁혀갈 수 있게 만들어야 하는 시스템이라는 점입니다.
그래서 운영 기준을 바꿨습니다. 컴포넌트별 헬스체크를 따로 보고, API 응답 시간과 큐 적체 여부를 함께 보고, 배포 전에 롤백 경로를 먼저 정리했습니다. 그 뒤로 체감 안정성이 많이 올라갔습니다. 실제로 써보니까 “문제가 줄었다”기보다 “문제가 생겨도 덜 무섭다” 쪽이 더 정확하더라고요.
비용 관점에서 본 오픈스택: 라이선스보다 사람이 비쌉니다
클라우드 비용 이야기도 빼놓을 수 없죠. 오픈스택을 검토할 때 흔히 “오픈소스니까 싸지 않나요?”라는 질문을 받습니다. 반은 맞고 반은 틀립니다. 라이선스 비용만 보면 유리할 수 있습니다. 하지만 실제 총비용(TCO, Total Cost of Ownership)을 보면 얘기가 달라집니다.
제가 정리한 기준은 이렇습니다.
하드웨어 조달 비용이 들어갑니다.
네트워크 설계와 스토리지 백엔드 운영 비용이 들어갑니다.
장애 대응 가능한 운영 인력 비용이 꽤 큽니다.
자동화와 표준화가 부족하면 사람 시간이 계속 녹습니다.
특히 클라우드 비용에서 가장 자주 놓치는 부분이 “기회비용”입니다. 퍼블릭 클라우드라면 몇 분 안에 끝났을 일을, 온프레미스 OpenStack 환경에서는 승인, 자원 계획, 이미지 검증, 네트워크 정책 반영까지 여러 단계를 거쳐야 할 수 있거든요. 물론 규모가 커지고 워크로드가 고정적이면 오픈스택이 유리한 구간도 분명 있습니다. 다만 그 전제는 운영 자동화가 어느 정도 완성되어 있어야 한다
항목
퍼블릭 클라우드
오픈스택 기반 프라이빗 클라우드
초기 구축
낮음
높음
확장 속도
빠름
설계 수준에 따라 다름
운영 자유도
제한적
매우 높음
인력 의존도
상대적으로 낮음
높음
비용 예측
사용량 기반
고정비와 운영비 혼합
실전 구현: 제가 운영 중 반복해서 확인한 기본 점검 절차
이제 조금 실무적으로 가보겠습니다. 아래 절차는 제가 정기 점검이나 장애 초기 대응 때 자주 확인하던 흐름입니다. 배포 방식이 다르더라도 기본 개념은 비슷합니다.
1. 서비스 상태 확인
openstack service list
openstack compute service list
openstack network agent list
openstack hypervisor list
이 단계에서는 서비스가 “떠 있느냐”보다 비정상적으로 down 처리된 항목이 없는지를 먼저 봅니다. 특히 컴퓨트 노드가 보이는데 스케줄링이 안 되는 경우가 있어서, 단순 프로세스 상태만 믿으면 안 되더라고요.
2. 리소스 생성 동작 확인
openstack image list
openstack flavor list
openstack network list
openstack server create --flavor m1.small --image test-image --network private-net test-vm
openstack server list
테스트 VM 하나를 실제로 올려보는 게 중요합니다. 모니터링이 모두 초록색이어도, 실제 프로비저닝(Provisioning, 자원 생성 절차) 단계에서 실패하는 경우가 꽤 있습니다. 저도 처음엔 대시보드만 보고 안심했었는데, 실사용 검증이 빠지면 꼭 뒤에서 터지더라고요.
서비스 목록 확인, 하이퍼바이저 점검, 테스트 VM 생성 검증까지 이어지는 운영 점검 흐름을 설명하는 이미지입니다.
3. 네트워크 연결성 확인
openstack port list --server test-vm
openstack floating ip list
ping -c 4 <floating-ip>
ssh -i ~/.ssh/id_rsa cloud-user@<floating-ip>
네트워크는 늘 마지막까지 확인해야 합니다. Neutron(뉴트론, 네트워크 관리)은 구성 자유도가 큰 만큼 문제 원인도 다양합니다. 보안 그룹(Security Group, 가상 방화벽 규칙), 라우터, 플로팅 IP(Floating IP, 외부 연결용 IP), L2/L3 에이전트 상태를 같이 봐야 하거든요.
이건 실제 제품 설정이라기보다 운영 체크 항목을 어떻게 표준화할지 보여주는 예시입니다. 핵심은 정적 상태 점검과 동적 사용자 시나리오 점검을 분리해서 관리하는 겁니다.
⚠️ 트러블슈팅: 3년 동안 자주 만난 문제들
여기서는 정말 많이 겪었던 문제만 추려보겠습니다. 혹시 이런 경험 있으신가요? 장애 알람은 없는데 사용자만 불편하다고 하는 상황이요. 오픈스택에서는 꽤 흔합니다.
1. 서비스는 정상인데 VM 생성이 지연되는 문제
처음엔 스케줄러(Scheduler, 자원 배치기) 문제인가 싶었는데, 실제로는 백엔드 스토리지 응답 지연이나 이미지 다운로드 지연이 원인인 경우가 있었습니다. 겉보기엔 Nova 문제처럼 보이는데, 파고들면 Glance나 스토리지 레이어였던 거죠. 이럴 땐 API 로그만 보지 말고 생성 요청이 어느 단계에서 오래 머무는지를 추적해야 합니다.
2. 네트워크 연결이 간헐적으로 실패하는 문제
이건 진짜 골치 아팠습니다. 제가 직접 해보니 네트워크 문제는 재현이 안 될 때가 가장 힘들더라고요. 보안 그룹 규칙, MTU, 라우팅 경로, 에이전트 상태가 모두 맞물리기 때문에 증상만 보고 섣불리 판단하면 시간만 씁니다. 그래서 저는 네트워크 이슈가 나면 아래 순서로 봤습니다.
이건 기술 문제라기보다 조직 문제에 가깝습니다. 누가 퇴근하면 아무도 못 건드리는 작업이 생기기 시작하면, 그 순간부터 안정성은 떨어진다고 봐야 합니다. 저도 한동안 특정 점검 절차를 머릿속으로만 기억하고 있었는데, 나중에 돌아보니 그게 제일 위험했어요. 문서화와 자동화가 귀찮아 보여도 결국 가장 싸게 먹힙니다.
openstack server show test-vm
openstack console log show test-vm
openstack port show <port-id>
openstack hypervisor stats show
문제가 생기면 위 같은 기본 명령어부터 차근차근 보는 습관이 중요합니다. 급하다고 바로 재시작부터 하면 원인 단서가 금방 사라지거든요.
검증과 결과: 운영이 편해졌다고 느낀 순간
운영은 결국 체감이 중요합니다. 제가 오픈스택 경험을 통해 “이제 좀 자리 잡았구나” 느낀 기준은 화려한 기능 추가가 아니었습니다.
새 VM 생성 성공 여부를 운영자가 감으로 판단하지 않게 됐을 때
장애 발생 시 어느 레이어부터 볼지 팀 내 공통 언어가 생겼을 때
정기 점검 결과가 사람마다 다르지 않게 됐을 때
비용 논의에서 라이선스가 아니라 운영 방식이 중심이 됐을 때
이런 변화가 생기면 인프라 관리의 수준이 한 단계 올라갑니다. 이전에는 문제를 “해결”하는 데 집중했다면, 이후에는 문제를 “예측 가능하게 만드는 것”으로 관점이 바뀌더라고요. 이 차이가 꽤 큽니다.
서비스 상태, 자원 사용량, 장애 추적 포인트를 한 화면에서 보는 운영 대시보드 느낌의 이미지입니다.
오픈스택을 추천할 때와 말릴 때
모든 환경에 오픈스택이 정답은 아닙니다. 이건 꼭 말씀드리고 싶었습니다. 제가 멘토처럼 조언드린다면 기준은 꽤 명확합니다.
추천하는 경우
워크로드가 비교적 예측 가능하고 장기 운영 비중이 큰 경우
네트워크, 스토리지, 가상화에 대한 내부 이해도가 있는 경우
자동화와 운영 표준화에 시간을 투자할 수 있는 경우
데이터 주권이나 내부 통제가 중요한 경우
말리고 싶은 경우
소수 인원이 모든 걸 동시에 맡아야 하는 경우
빠른 기능 출시가 최우선이고 인프라가 차별점이 아닌 경우
장애 대응 경험이 부족한 상태에서 복잡한 네트워크 구성을 바로 가져가려는 경우
운영 인력 확보 없이 비용 절감만 기대하는 경우
근데 여기서 중요한 건, 말린다고 해서 기술이 나쁘다는 뜻은 아니라는 점입니다. 도구의 성격과 조직의 운영 성숙도가 맞아야 한다
정리와 FAQ: 놓치지 말아야 할 것들
오픈스택 운영 회고를 한 줄로 정리하면 이렇습니다. 안정성은 아키텍처보다 운영 기준에서 나오고, 비용은 라이선스보다 사람과 절차에서 갈립니다. 저도 처음엔 기능 중심으로 봤는데, 결국 오래 가는 환경은 단순하고 반복 가능하게 만든 환경이었습니다.
다음 글에서는 홈랩(Home Lab, 개인 실험실) 기준으로 소규모 OpenStack 검증 환경을 어떻게 꾸렸는지, 그리고 어떤 식으로 실험 순서를 잡았는지 다뤄볼 예정입니다. 이전 글에서 다뤘던 가상화 레이어 점검 방법과 함께 보시면 더 이해가 쉬우실 겁니다.
자주 묻는 질문
Q. 오픈스택은 무조건 비용 절감에 유리한가요?
A. 아닙니다. 하드웨어와 운영 인력, 자동화 수준까지 같이 봐야 합니다. 특히 초반에는 생각보다 손이 많이 갑니다.
Q. 오픈스택 안정성을 높이려면 가장 먼저 뭘 해야 하나요?
A. 서비스 상태 확인보다 먼저 운영 기준을 표준화하는 게 좋습니다. 누가 봐도 같은 절차로 점검할 수 있어야 합니다.
Q. 오픈스택 경험이 적은 팀도 시작할 수 있을까요?
A. 가능합니다. 다만 작은 범위에서 시작하고, 네트워크와 스토리지 복잡도를 초반에 과하게 올리지 않는 게 좋습니다.
안정성, 비용, 운영 기준 세 가지 핵심 교훈을 요약해서 보여주는 마무리 인포그래픽 이미지입니다.
OpenStack 프라이빗 클라우드 보안 이야기는 평소엔 좀 뒤로 밀리기 쉽습니다. 서비스가 잘 돌고 있으면 당장 체감이 안 되거든요. 그런데 클라우드 보안 감사 한 번 들어오면 분위기가 바로 달라집니다. 계정 정책, API TLS, 로그 보관, 이미지 무결성 같은 항목이 한꺼번에 쏟아지니까요. 저도 홈랩과 실무 환경에서 비슷한 점검을 여러 번 겪어봤는데, 처음엔 “이건 설정 파일 몇 개만 손보면 되겠지” 싶었거든요. 근데 막상 들어가 보니 Keystone(키스톤, 인증/인가), Nova(노바, 컴퓨트), Neutron(뉴트론, 네트워크), RabbitMQ(래빗MQ, 메시지 브로커)까지 서로 얽혀 있어서 삽질 좀 했습니다 ㅎㅎ
이번 글은 특정 벤더 보고서 하나를 요약하는 방식보다는, 최근 감사에서 반복적으로 지적되는 OpenStack 보안 항목을 공식 Security Guide와 체크리스트 기준으로 묶어서 정리한 내용입니다. 즉, 보고서가 달라도 결국 자주 걸리는 포인트는 비슷하더라고요. 그래서 오늘은 OpenStack 프라이빗 클라우드 보안을 실제 운영 관점에서 어떻게 강화할지, 제가 실무에서 우선순위를 잡는 방식으로 풀어보겠습니다.
쉽게 말해 감사는 “설정이 있느냐”보다 보안 경계(Security Boundary, 보안 경계)가 실제로 분리되어 있느냐를 봅니다. OpenStack은 컴포넌트가 많아서, 한 군데만 HTTPS를 켰다고 끝나지 않거든요. 예를 들어 Horizon(호라이즌, 대시보드)은 TLS를 쓰는데 서비스 간 내부 통신은 평문으로 남아 있거나, RabbitMQ 인증서는 넣었는데 호스트네임 검증은 꺼져 있는 식입니다. 겉으로는 안전해 보여도 감사에서는 바로 티가 납니다.
제가 최근 점검할 때도 지적이 많이 나온 항목은 아래 네 가지였습니다.
관리망과 외부망 분리 부족: 내부 API가 외부 엔드포인트를 타는 경우
과도한 권한: 관리자 계정 공유, 서비스 계정 권한 과다
로그는 있는데 감사 추적이 어려움: 중앙 수집과 상관분석 부재
이미지/메시지 경로 무결성 미흡: 이미지 서명 검증, 메시지 브로커 TLS 검증 미설정
2. OpenStack 보안 베스트 프랙티스, 핵심만 먼저 잡아보겠습니다
OpenStack 보안 베스트 프랙티스를 한 줄로 줄이면 이겁니다. “외부 공개 구간만 막지 말고, 내부 제어면(Control Plane, 제어 평면)까지 신뢰하지 말자.” 저도 처음엔 내부망이면 괜찮지 않나 싶었는데, 실제로는 운영자 실수나 계정 탈취가 더 무섭더라고요.
감사 항목
자주 보이는 문제
즉시 대응
장기 대응
인증/인가
관리자 계정 공유, MFA 미적용
관리자 계정 분리, 외부 IdP 연동 검토
RBAC 재설계, 페더레이션 적용
통신 보안
내부 API 평문, 인증서 검증 비활성화
HTTPS 강제, internal endpoint 지정
전 구간 TLS, 인증서 수명주기 자동화
감사 로그
노드별 로그 분산, 이벤트 표준화 부족
중앙 로그 수집
CADF 기반 감사 추적 체계화
무결성
이미지 검증 없음, 설정 파일 변경 감시 없음
서명 검증, 권한 점검
FIM, 골든 이미지 파이프라인
여기서 중요한 포인트! 감사 대응은 문서부터 쓰는 게 아니라 데이터 흐름부터 그려야 합니다. 누가 로그인하고, 어떤 API를 타고, 어떤 메시지 브로커를 지나, 최종적으로 어떤 로그가 남는지 보셔야 합니다. 이 흐름이 안 보이면 체크리스트만 돌려도 자꾸 빠지는 항목이 생깁니다.
3. 실전 구현 1: 계정, 엔드포인트, TLS부터 정리합니다
제가 직접 해보니 제일 효과가 큰 첫 단계는 “접속면 줄이기”였습니다. 즉, 공개 엔드포인트와 내부 엔드포인트를 분리하고, 서비스 간 통신이 public URL이 아니라 internal URL을 쓰도록 강제하는 겁니다.
서비스 카탈로그(Service Catalog, 서비스 목록)에서 internal endpoint를 분리합니다.
각 서비스 설정에서 Keystone 인증 URL과 연동 URL이 HTTPS인지 확인합니다.
이 작업은 단순해 보여도 효과가 큽니다. 내부 관리 트래픽이 외부 공개 주소를 타지 않게 되니까요. 특히 프록시나 로드밸런서가 여러 겹일 때 감사 추적도 훨씬 쉬워집니다.
public endpoint와 internal endpoint를 분리하고 서비스 간 통신을 HTTPS로 고정한 예시 구성입니다.
4. 실전 구현 2: RabbitMQ, 로그, 이미지 무결성을 같이 보셔야 합니다
OpenStack은 API만 안전해도 끝이 아닙니다. 실제로 서비스끼리 대화하는 길목은 RabbitMQ 같은 메시지 브로커인 경우가 많거든요. 여기 TLS를 켜도 인증서 체인만 보고 호스트네임 검증을 안 하면 허점이 남습니다. 최근 oslo.messaging 릴리스 노트에서도 이 부분이 분명히 언급됐습니다. 그래서 제가 운영할 때는 브로커 TLS와 로그 표준화를 같이 묶어서 봅니다.
# /etc/nova/nova.conf 또는 공통 oslo.messaging 설정
[oslo_messaging_rabbit]
ssl = true
ssl_ca_file = /etc/ssl/certs/openstack-ca.pem
ssl_cert_file = /etc/ssl/certs/client.pem
ssl_key_file = /etc/ssl/private/client-key.pem
ssl_enforce_hostname_verification = true
단, 이 옵션은 배포판 패키지 버전에 따라 지원 여부가 다를 수 있습니다. 그래서 바로 적용하기 전에 패키지 changelog나 릴리스 노트를 꼭 보셔야 합니다. 저도 이거 모르고 넣었다가 서비스 재시작만 반복한 적이 있었네요.
감사 로그 쪽은 Keystone의 CADF(Cloud Auditing Data Federation, 클라우드 감사 이벤트 표준) 포맷을 적극 검토할 만합니다. 사람이 보기엔 조금 딱딱하지만, SIEM(보안 정보 이벤트 관리)으로 넘길 때 훨씬 정리가 잘 됩니다.
처음엔 이게 너무 과한가 싶었는데, 골든 이미지(Golden Image, 표준 이미지)를 운영하는 환경에서는 진짜 편하더라고요. 누가 어떤 이미지를 올렸는지, 검증됐는지 흐름이 분명해집니다.
메시지 브로커 TLS 보호와 Keystone CADF 감사 로그가 중앙 수집 시스템으로 모이는 흐름입니다.
5. 실전 구현 3: 파일 권한과 노드 하드닝은 기본인데 가장 많이 놓칩니다
이건 너무 기본 같아서 오히려 빼먹습니다. 그런데 공식 Security Checklist를 보면 Keystone, Nova, Neutron 설정 파일의 소유권과 권한을 아주 명확하게 확인하라고 하거든요. 감사에서도 이건 빠지지 않습니다.
stat -L -c "%U %G %a" /etc/keystone/keystone.conf
stat -L -c "%U %G %a" /etc/nova/nova.conf
stat -L -c "%U %G %a" /etc/neutron/neutron.conf
find /etc/keystone /etc/nova /etc/neutron -type f -perm /027 -ls
제가 주로 보는 기준은 이렇습니다.
서비스 계정과 그룹이 올바른지 확인
설정 파일 권한이 과도하게 열려 있지 않은지 확인
SELinux(셀리눅스, 강제 접근 통제)나 AppArmor 정책과 충돌 없는지 확인
FIM(File Integrity Management, 파일 무결성 감시) 대상에 핵심 설정 파일 포함
여기서 많이 겪는 문제는 자동화 도구가 재배포하면서 권한을 널널하게 바꿔버리는 경우입니다. 특히 템플릿 한 군데 잘못 두면 전체 노드가 같은 실수를 반복합니다. 그래서 저는 배포 후 검증 명령을 CI 파이프라인이나 운영 점검 스크립트에 꼭 넣습니다.
6. ⚠️ 감사 때 자주 터지는 트러블슈팅
이 섹션은 실전에서 진짜 많이 부딪히는 부분입니다.
6-1. HTTPS는 켰는데 인증 실패가 납니다
대부분 CA 체인이나 호스트네임 불일치입니다. 인증서를 넣었다고 끝이 아니고, 서비스가 접속하는 URL과 인증서 SAN(Subject Alternative Name, 주체 대체 이름)이 맞아야 합니다.
6-2. 내부 통신을 HTTPS로 바꾸니 서비스 등록은 됐는데 호출이 꼬입니다
이 경우 public endpoint는 바꿨는데, 개별 서비스 설정은 여전히 외부 주소를 보고 있는 경우가 많습니다. 카탈로그와 각 서비스 설정 파일을 둘 다 봐야 합니다.
6-3. 로그는 모이는데 감사 보고서에서 추적성이 부족하다고 나옵니다
이건 단순 보관이 아니라 상관관계(Correlation, 상관 분석) 문제입니다. 사용자 로그인, 토큰 발급, 인스턴스 생성, 볼륨 연결, 보안그룹 변경 이벤트를 하나의 흐름으로 이어서 볼 수 있어야 하거든요. 그래서 Keystone 이벤트, API 로그, 하이퍼바이저 로그를 따로 보지 말고 묶어야 합니다.
6-4. 보안 강화 후 성능이 걱정됩니다
맞습니다. TLS와 추가 로깅은 비용이 있습니다. 그래서 저는 처음부터 전부 켜기보다 인터넷 노출 구간, 관리자 구간, 메시지 브로커, 이미지 검증 순서로 우선순위를 잡습니다. 한 번에 다 바꾸면 장애 원인 분석이 어려워집니다.
7. 검증은 이렇게 하시면 됩니다
보안 설정은 “넣었다”가 아니라 “검증됐다”로 끝내야 합니다. 제가 보통 마지막에 확인하는 체크는 아래와 같습니다.
모든 핵심 서비스 엔드포인트가 HTTPS인지 확인
서비스 설정의 insecure = true 흔적 제거 확인
메시지 브로커 TLS 연결 및 인증서 검증 확인
CADF 또는 중앙 로그에서 관리자 행위 추적 가능 여부 확인
서명되지 않은 이미지가 정책상 차단되는지 확인
openstack endpoint list --long | egrep "https|Region"
grep -R "insecure *= *true" /etc/keystone /etc/nova /etc/neutron /etc/glance
openssl s_client -connect rabbitmq.internal.example:5671 -servername rabbitmq.internal.example
openstack image list
openstack server list
완료 후 대시보드와 CLI 둘 다 테스트해보세요. Horizon만 되고 CLI가 안 되거나, 반대로 API는 되는데 메타데이터 프록시가 깨지는 경우가 있습니다. 저도 이 단계에서 “드디어 됐다!” 했다가 보안그룹 갱신이 안 되는 걸 뒤늦게 발견한 적이 있었거든요.
보안 점검 항목이 통과되고 중앙 로그에서 관리자 행위를 추적할 수 있는 결과 화면 예시입니다.
8. 정리: OpenStack 프라이빗 클라우드 보안은 순서가 중요합니다
OpenStack 프라이빗 클라우드 보안은 기능을 많이 넣는 게임이 아닙니다. 순서를 잘 잡는 작업에 가깝습니다. 제가 실제로 운영하면서 느낀 우선순위는 이렇습니다. 계정 통제 → 내부 API TLS → 메시지 브로커 보호 → 감사 로그 표준화 → 이미지 무결성 → 파일 무결성 감시. 이 순서로 가면 감사 대응도 수월하고, 장애가 나도 어디서 꼬였는지 찾기 편합니다.
혹시 지금 프라이빗 클라우드 감사 대응을 준비 중이시라면, 문서부터 만들기보다 먼저 엔드포인트와 계정, 로그 흐름을 그림으로 그려보세요. 그 다음에 체크리스트를 맞추면 훨씬 빨라집니다. 다음 글에서는 Barbican(바비칸, 비밀 관리 서비스)과 이미지 서명 체계를 조금 더 깊게 다뤄보겠습니다. 이전에 정리한 리눅스 하드닝 글이 있으시면 그 흐름과 같이 보셔도 연결이 잘 됩니다.
계정 통제, TLS, 로그, 이미지 무결성, 파일 무결성 감시 순서로 정리한 대응 우선순위 요약입니다.
9. 자주 묻는 질문
Q1. 작은 홈랩에도 이렇게까지 해야 할까요?
전부 한 번에 할 필요는 없습니다. 다만 관리자 계정 분리, HTTPS, 설정 파일 권한 점검은 작은 환경에서도 바로 체감됩니다.
Q2. 클라우드 보안 감사에서 가장 빨리 점수 올리는 항목은 뭔가요?
보통은 내부 API TLS, 관리자 접근 통제, 중앙 로그 수집입니다. 이 세 개가 눈에 잘 보이고 재현도 쉽습니다.
Q3. OpenStack 보안 베스트 프랙티스를 어디서 시작하면 좋을까요?
공식 Security Checklist를 서비스별로 돌려보는 게 제일 현실적입니다. Keystone, Nova, Neutron부터 보시면 됩니다.
OpenStack 업그레이드 10가지 체크리스트: 실전 베스트 프랙티스로 성공 확률 높이기
OpenStack 업그레이드는 생각보다 자주, 그리고 생각보다 크게 운영팀을 흔듭니다. 평소엔 잘 돌던 Nova(노바, 컴퓨트 서비스), Neutron(뉴트론, 네트워크 서비스), Cinder(신더, 블록 스토리지 서비스)가 업그레이드 직후 서로 미묘하게 어긋나기 시작하면 진짜 진땀 나거든요. 저도 처음엔 “패키지 버전만 맞추면 되겠지” 했다가 메시지 큐(Message Queue, 서비스 간 비동기 통신), DB schema(데이터베이스 스키마), API microversion(API 세부 버전 정책) 때문에 삽질 좀 했습니다 ㅎㅎ 이번 글은 그런 시행착오를 줄이기 위한 OpenStack 업그레이드 체크리스트를 정리한 내용입니다.
특히 운영 중인 프라이빗 클라우드(private cloud)를 관리하시는 분들이라면, 단순히 패키지를 올리는 작업이 아니라 클라우드 업그레이드 전체 흐름으로 봐야 합니다. 오늘은 제가 홈랩과 실서비스 환경에서 반복해서 확인했던 항목들을 기준으로, 실패 확률을 줄이는 순서와 OpenStack 베스트 프랙티스를 풀어보겠습니다.
컨트롤 플레인과 컴퓨트 노드, 스토리지, 네트워크 컴포넌트가 단계적으로 업그레이드되는 전체 흐름을 보여주는 이미지입니다.
왜 OpenStack 업그레이드가 까다로운가
쉽게 말해 OpenStack은 하나의 프로그램이 아니라 여러 서비스 묶음입니다. Keystone(키스톤, 인증 서비스), Glance(글랜스, 이미지 서비스), Nova, Neutron, Cinder 같은 핵심 서비스가 각각 DB, API, 에이전트, 백엔드 드라이버를 갖고 있고요. 그래서 한 군데만 올리면 끝나는 구조가 아닙니다.
여기서 중요한 포인트! 업그레이드의 핵심은 버전 상승 자체가 아니라 호환성 유지입니다. 실제로 써보니까 장애는 대개 패키지 설치보다 서비스 간 정합성이 깨질 때 발생하더라고요. 예를 들어 API는 올라갔는데 agent(에이전트, 각 노드에서 동작하는 구성요소)가 예전 상태면 네트워크 포트 생성이 꼬이거나, DB migration(데이터베이스 마이그레이션)이 덜 끝난 상태에서 서비스가 붙으면서 애매한 오류를 만들기도 합니다.
OpenStack 업그레이드 전 꼭 봐야 할 10가지 체크리스트
공식 릴리스 노트와 업그레이드 경로 확인 지원되는 업그레이드 경로인지 먼저 확인해야 합니다. 중간 릴리스를 건너뛰면 안 되는 경우가 있거든요.
현재 인벤토리와 의존성 파악 컨트롤러, 컴퓨트, 네트워크 노드, 스토리지 백엔드, 하이퍼바이저, OS 패키지 상태를 정리합니다.
백업과 복구 시나리오 검증 DB dump만 뜨고 끝내면 부족합니다. 실제 복원 테스트까지 해봐야 합니다.
테스트 환경 또는 스테이징 검증 프로덕션과 최대한 비슷한 구조에서 한 번 굴려봐야 예상치 못한 이슈를 줄일 수 있습니다.
API, DB, Message Queue 호환성 점검 RabbitMQ 같은 메시지 큐와 MariaDB/MySQL, PostgreSQL 설정 차이도 같이 봐야 합니다.
드레인(Drain)과 유지보수 창 확보 라이브 마이그레이션 가능 여부, 예약 작업, 사용자 공지까지 포함해서 계획을 세워야 합니다.
롤링 업그레이드 가능 범위 확인 서비스별로 순차 적용 가능한지, 전체 중단이 필요한지 구분해야 합니다.
설정 파일 diff 비교 기존 설정과 새 기본값이 어떻게 달라졌는지 비교해야 합니다.
모니터링과 로그 수집 체계 준비 업그레이드 직후엔 로그가 거의 유일한 힌트일 때가 많습니다.
검증 시나리오 문서화 인스턴스 생성, 삭제, 볼륨 연결, 플로팅 IP, 보안 그룹, 이미지 업로드 같은 기본 기능을 체크리스트로 만들어야 합니다.
업그레이드 방식 비교: 인플레이스 vs 블루그린 관점
현실적으로는 대부분 인플레이스(in-place, 기존 환경에서 직접 업그레이드)를 선택합니다. 비용과 장비 여유 때문이죠. 저도 홈랩에서는 거의 인플레이스로 갔었는데, 대신 검증 시나리오를 더 빡세게 잡았습니다. 반대로 규모가 크고 서비스 중단 허용 범위가 작다면 블루그린(blue-green, 신규 환경을 따로 구성 후 전환) 접근이 더 안전할 수 있습니다.
방식
장점
주의점
인플레이스 업그레이드
추가 자원 부담이 적고 기존 운영 체계를 유지하기 쉽습니다
롤백이 까다롭고 서비스 간 버전 혼합 구간 관리가 중요합니다
블루그린 전환
검증 후 전환이 가능해 리스크를 줄이기 좋습니다
추가 인프라와 데이터 동기화 전략이 필요합니다
하이브리드 단계 전환
핵심 서비스만 분리해 현실적으로 적용하기 좋습니다
운영 절차가 복잡해지고 문서화가 필수입니다
실전 구현: OpenStack 업그레이드 작업 순서
여기서는 배포 도구에 종속되지 않는 공통 흐름으로 설명하겠습니다. Ansible(앤서블, 자동화 도구), Kolla-Ansible, OpenStack-Ansible, 수동 패키지 기반 환경 모두 참고 가능한 순서입니다.
1. 현재 상태 수집
처음엔 이게 뭔가 싶었는데, 이 단계가 제일 중요합니다. 업그레이드 전 상태를 남겨놓지 않으면 장애가 나도 비교 기준이 없거든요.
openstack compute service list
openstack network agent list
openstack volume service list
openstack hypervisor list
openstack server list --all-projects
openstack volume list --all-projects
이 명령으로 서비스 상태를 저장해두면 업그레이드 후 비교가 훨씬 쉬워집니다. 가능하면 결과를 파일로 보관하세요.
2. 데이터베이스와 설정 백업
mysqldump --single-transaction --routines --databases keystone glance nova nova_api neutron cinder > openstack-backup.sql
cp -a /etc/keystone /root/backup/etc-keystone
cp -a /etc/nova /root/backup/etc-nova
cp -a /etc/neutron /root/backup/etc-neutron
cp -a /etc/cinder /root/backup/etc-cinder
제가 직접 해보니 DB dump만 믿고 갔다가 설정 파일 옵션 차이 때문에 더 오래 헤맨 적이 있습니다. 그래서 DB + 설정 파일 + 서비스 목록을 같이 백업하는 습관이 중요합니다.
3. 유지보수 창 공지와 워크로드 정리
운영 환경이라면 프로젝트 사용자에게 공지하고, 가능하면 대규모 배포 작업이나 자동 스케일링 작업은 멈춰두는 게 좋습니다. 라이브 마이그레이션이 가능한 구조라면 컴퓨트 노드 분산도 미리 해두세요.
사전 점검, 백업, 서비스 중지, DB 마이그레이션, 단계별 기동 검증까지 이어지는 작업 순서를 시각화한 이미지입니다.
4. 컨트롤 플레인부터 순차 업그레이드
일반적으로는 인증, 이미지, API, 스케줄러, 컨덕터 같은 컨트롤 플레인(control plane, 중앙 제어 계층)을 먼저 올리고 이후 컴퓨트와 에이전트를 따라갑니다. 근데 여기서 중요한 건 무조건 한 번에 다 올리는 게 아니라 서비스별 검증 후 다음 단계로 이동하는 겁니다.
systemctl stop openstack-nova-api
systemctl stop openstack-nova-scheduler
systemctl stop openstack-nova-conductor
# 패키지 업데이트 또는 배포 도구 실행
# 예: dnf update, apt upgrade, ansible-playbook 실행 등
nova-manage api_db sync
nova-manage db sync
systemctl start openstack-nova-api
systemctl start openstack-nova-scheduler
systemctl start openstack-nova-conductor
서비스 이름은 배포판마다 조금 다를 수 있습니다. 그래서 실환경에 맞는 서비스 유닛 이름을 먼저 확인해야 합니다.
5. Neutron과 Cinder는 연결 관계를 같이 본다
네트워크와 스토리지는 겉보기보다 외부 의존성이 많습니다. Neutron은 L2/L3 agent, ML2 plugin, DHCP, Metadata 구성이 엮여 있고요. Cinder는 백엔드 스토리지 드라이버와의 호환성이 중요합니다. 저도 예전에 API는 멀쩡한데 agent 상태가 down으로 찍혀서 한참 로그를 봤던 적이 있네요.
openstack network agent list
openstack volume service list
journalctl -u neutron-server -n 100
journalctl -u openstack-cinder-volume -n 100
6. 컴퓨트 노드는 소수부터 검증
모든 컴퓨트 노드를 한 번에 건드리지 말고, 먼저 일부 노드만 올려서 인스턴스 생성과 마이그레이션을 확인하는 게 좋습니다. 이건 정말 실전에서 체감이 큽니다. 작은 범위에서 틀어지면 복구가 빠르거든요.
설정 파일에서 자주 놓치는 포인트
deprecated option: 더 이상 권장되지 않는 옵션이 남아 있으면 경고만 보이다가 실제 동작에 영향을 줄 수 있습니다.
endpoint URL: 내부 엔드포인트와 퍼블릭 엔드포인트 주소 체계가 섞이면 인증이나 이미지 호출이 실패할 수 있습니다.
policy: 정책 파일 구조가 바뀌는 경우가 있어 권한 문제가 생기기도 합니다.
backend driver 설정: Cinder, Neutron 플러그인 쪽은 예전 옵션명이 유지되지 않는 경우가 있습니다.
설정 비교는 단순히 파일 존재 여부가 아니라 기본값 변화를 보는 작업입니다. 여기서 중요한 포인트! 새 버전 기본 설정 샘플과 현재 운영 설정을 diff로 비교해보세요.
이건 생각보다 흔합니다. 서비스 계정 권한, 커넥션 문자열, 캐시, 메시지 큐 인증 정보가 미묘하게 어긋난 경우가 많더라고요. 로그에서 connection refused, access denied, transport error 같은 키워드를 먼저 찾으세요.
네트워크 에이전트가 살아 있는데 포트 생성이 실패하는 경우
Neutron server와 agent 버전 조합, ML2 설정, OVS(Open vSwitch, 가상 스위치) 또는 Linux bridge 구성이 어긋난 경우가 많습니다. 이럴 땐 API 응답만 보지 말고 agent heartbeat(에이전트 하트비트)와 브리지 상태를 같이 봐야 합니다.
openstack network agent list
ovs-vsctl show
ip link show
인스턴스는 생성되는데 콘솔 접속이 안 되는 경우
novncproxy, metadata, 보안 그룹, 프록시 설정이 엮여 있는 경우가 많습니다. 처음엔 컴퓨트 문제라고 생각하기 쉬운데, 실제로는 프론트 API나 프록시 계층 이슈인 경우도 있었습니다.
롤백이 필요한데 되돌릴 순서가 없는 경우
사실 제일 무서운 상황입니다. 그래서 업그레이드 시작 전에 “어디까지 실패하면 중단할지” 기준을 잡아야 합니다. 저는 보통 컨트롤 플레인 검증 실패, 인스턴스 신규 생성 실패, 기존 VM 네트워크 연결 실패 이 세 가지를 즉시 중단 기준으로 둡니다.
검증: 업그레이드 후 무엇을 확인해야 하나
업그레이드가 끝났다고 바로 종료하면 안 됩니다. OpenStack 유지보수 관점에서는 사후 검증이 절반입니다. 아래 항목은 꼭 순서대로 확인해보세요.
인증 토큰 발급과 대시보드 로그인 확인
이미지 목록 조회와 신규 이미지 업로드 확인
네트워크 생성, 서브넷 생성, 라우터 연결 확인
테스트 인스턴스 생성과 삭제 확인
플로팅 IP 연결 및 외부 통신 확인
볼륨 생성, 연결, 분리 확인
보안 그룹 규칙 반영 확인
라이브 또는 콜드 마이그레이션 시나리오 확인
모니터링 알림과 로그 수집 확인
에러 로그 증가 여부 추적
서비스 상태가 모두 정상이며 컴퓨트, 네트워크, 스토리지 검증 항목이 체크 완료된 운영 대시보드 이미지입니다.
openstack token issue
openstack image list
openstack network list
openstack server create --flavor m1.small --image test-image --network private test-vm
openstack server list
openstack volume create --size 1 test-volume
openstack volume list
이 검증 절차를 문서화해두면 다음 업그레이드 때 시간이 정말 많이 줄어듭니다. 실제로 써보니까 사람 기억보다 체크리스트가 훨씬 믿을 만하더라고요.
제가 정리해보는 OpenStack 베스트 프랙티스
작게 시작해서 넓힌다: 일부 노드, 일부 서비스부터 검증합니다.
업그레이드 전 상태를 숫자와 결과로 남긴다: 서비스 목록, 워크로드 수, 에이전트 상태를 저장합니다.
백업은 복원 테스트까지 포함한다: 백업 파일 존재만으로 안심하면 안 됩니다.
문서화한다: 명령어, 순서, 실패 지점, 복구 시간을 기록합니다.
배포 도구의 자동화를 맹신하지 않는다: 자동화는 빠르지만, 원인 분석은 사람이 해야 하거든요.
혹시 이런 경험 있으신가요? 업그레이드는 끝났는데 사용자 쪽에서 “왜 VM 생성이 예전보다 느려졌죠?”라는 질문이 나오는 경우요. 이런 건 단순 성공/실패가 아니라 성능과 안정성까지 같이 봐야 한다는 뜻입니다. 그래서 클라우드 업그레이드는 배포 이벤트가 아니라 운영 이벤트로 봐야 합니다.
정리: 체크리스트 기반으로 움직이면 성공 확률이 올라갑니다
OpenStack 업그레이드는 한 번의 명령으로 끝나는 작업이 아닙니다. 서비스 의존성, DB migration, 에이전트 상태, 검증 시나리오가 다 맞물려 있습니다. 저도 처음엔 버전만 맞추면 되겠지 싶었는데, 실제로는 사전 점검과 사후 검증이 훨씬 중요했습니다. 드디어 됐다! 싶은 순간은 마지막 패키지 설치가 아니라, 테스트 VM이 정상적으로 뜨고 네트워크와 볼륨이 다 붙는 걸 확인했을 때 오더라고요.
이번 글에서는 운영 기준으로 바로 써먹을 수 있는 체크리스트 중심으로 정리해봤습니다. 다음 글에서는 Kolla-Ansible 기반 환경에서 업그레이드 점검 포인트를 더 구체적으로 다뤄볼 예정입니다. 이전 글에서 백업 전략을 정리해두셨다면 이번 체크리스트와 같이 묶어서 보시면 흐름이 훨씬 잘 잡히실 겁니다.
업그레이드 전 점검 항목과 업그레이드 후 검증 항목을 한눈에 비교할 수 있는 요약 인포그래픽입니다.
자주 묻는 질문
Q. OpenStack 업그레이드는 무중단으로 가능한가요?
일부 구성에서는 롤링 업그레이드가 가능하지만, 실제 운영에서는 서비스 영향도를 0으로 만들기 쉽지 않습니다. 특히 네트워크와 스토리지 쪽은 사전 검증이 더 중요합니다.
Q. 테스트 환경이 작아도 도움이 되나요?
네, 도움이 됩니다. 완벽히 같지 않아도 서비스 기동 순서, DB migration, 기본 API 검증만 해봐도 큰 차이가 납니다.
Q. 가장 먼저 자동화해야 할 부분은 뭔가요?
상태 수집, 백업, 검증 명령 실행 결과 저장입니다. 이 세 가지가 자동화되면 반복 작업이 훨씬 안정적이 됩니다.
[클라우드 보안] OpenStack 보안 그룹 취약점과 Floating IP 보안 강화 전략
OpenStack 운영하다 보면 제일 많이 방심하는 지점 중 하나가 바로 보안 그룹(Security Group, 가상 방화벽 정책)과 Floating IP(플로팅 IP, 공인 IP를 인스턴스에 동적으로 붙이는 기능) 조합이에요. 저도 홈랩이랑 사내 테스트 환경에서 처음 이 구조를 만졌을 때는 “보안 그룹만 잘 걸어두면 끝 아닌가?” 싶었는데, 실제로 뜯어보면 그렇지 않더라고요. 특히 OpenStack 보안 그룹 취약점이라고 검색해서 들어오신 분들이라면, 단순히 룰 몇 개 추가하는 수준이 아니라 연결 상태(state), NAT(Network Address Translation, 네트워크 주소 변환), 정책 권한까지 같이 봐야 한다는 게 핵심이에요.
이번 글은 2014년에 공개된 OpenStack Security Note OSSN-0020에서 다뤄진 Floating IP 분리 후 기존 NAT 연결이 살아남는 문제, 그리고 2022년 이후에도 논의된 특정 Floating IP 지정 시 외부 네트워크 게이트웨이 IP와 충돌할 수 있는 운영 리스크를 바탕으로 정리했어요. 즉, 새로운 미확인 이슈를 다루는 게 아니라, 실제로 문서화된 동작과 운영상 취약 지점을 기준으로 Floating IP 보안 전략을 재구성한 분석입니다.
보안 그룹, Neutron 라우터, 외부 네트워크, 인스턴스 사이의 트래픽 흐름을 한눈에 보여주는 개요 이미지가 들어갈 자리입니다.
1. 왜 이 이슈를 다시 봐야 하나요
공식 보안 노트 OSSN-0020은 Neutron L3 agent 환경에서 Floating IP를 해제해도 이미 맺어진 연결(established connection)은 바로 끊기지 않을 수 있다고 설명해요. 쉽게 말해, 운영자는 “공인 IP를 떼었으니 외부 접근도 끝났다”고 생각했는데, 실제 세션은 계속 살아 있는 상황이 생길 수 있다는 뜻이거든요.
이게 위험한 이유는 장애 대응이나 침해 대응 때 판단을 잘못하게 만들기 때문이에요. 예를 들어 외부에서 SSH가 붙어 있던 인스턴스에서 이상 행위가 발견돼서 Floating IP만 급하게 떼는 경우가 있잖아요. 저도 예전에 비슷하게 대응했다가, “어? 왜 세션이 안 죽지?” 하고 한참 봤던 적이 있어요. 나중에야 알았는데 보안 그룹 정책과 Floating IP 분리만으로 세션 종료가 보장되지 않는다는 게 핵심이었거든요.
2. OpenStack 보안 그룹 취약점, 쉽게 말해 뭐가 문제인가요
보안 그룹(Security Group)은 Neutron 포트에 붙는 가상 방화벽이에요. 기본적으로 Ingress(인그레스, 외부에서 안으로 들어오는 트래픽)는 막고, Egress(이그레스, 내부에서 바깥으로 나가는 트래픽)는 허용하는 구성이 많아요. 문서 기준으로도 보안 그룹은 포트 단위로 적용되고, 여러 그룹이 붙으면 룰은 가산적(additive)으로 합쳐진답니다.
문제는 여기서 Floating IP가 끼어들 때 생겨요. Floating IP는 인스턴스 NIC에 공인 IP를 직접 꽂는 느낌이라기보다, 대개 Neutron 라우터의 NAT 경로를 통해 외부와 연결돼요. 그래서 정책을 바꿨다고 해서 이미 형성된 세션이 운영자가 기대하는 순간에 깔끔하게 정리되는 건 아닐 수 있다는 뜻이에요.
정리하면 OpenStack 보안 그룹 취약점은 단순히 “룰이 뚫린다”가 아니라, 다음처럼 여러 층에서 나타나요:
상태 기반 연결 잔존: Floating IP를 떼어도 기존 세션이 남을 수 있어요.
과도한 권한: 특정 public IP를 사용자가 직접 지정하게 두면 외부 네트워크와 충돌 가능성이 생겨요.
예외 기능 남용: allowed-address-pairs나 port_security 예외를 잘못 쓰면 정책 의미가 흐려져요.
운영 착시: 콘솔에서 “분리됨”으로 보여도 실제 통신은 곧바로 끊기지 않을 수 있어요.
3. 공식 문서 기준으로 봐야 할 핵심 포인트
항목
확인된 사실
운영 의미
OSSN-0020
Floating IP 분리 후 기존 NAT 연결이 남을 수 있음
침해 대응 시 FIP 분리만으로 종료 판단하면 위험
보안 그룹 기본 동작
포트 단위 적용, 룰은 가산적 적용
인스턴스 단위로만 생각하면 누락이 생겨요
Neutron 정책
create_floatingip:floating_ip_address 권한을 정책으로 제어 가능
특정 공인 IP 직접 지정 권한을 축소할 수 있어요
Allowed Address Pairs
특정 조건에서 원격 그룹 기반 제한을 우회할 수 있다는 경고 존재
예외 기능은 최소화해야 해요
정책 파일 형식
JSON 정책 파일은 deprecated, YAML 권장
하드닝 작업은 policy.yaml 기준으로 정리하는 게 안전해요
제가 직접 문서랑 버그 토론을 다시 읽어보니, 많은 분이 “이게 CVE냐 아니냐”에만 집중하시더라고요. 근데 운영자 입장에서는 그보다 지금 내 클라우드에서 어떤 권한과 어떤 연결이 실제로 남느냐가 훨씬 중요해요. 특히 Floating IP 보안은 네트워크 설계, 테넌트 권한, 대응 절차를 같이 봐야 실수가 줄어들거든요.
4. 실전 구현: Floating IP 보안 강화 체크리스트
4-1. 현재 노출 범위부터 확인하기
처음엔 화려한 정책부터 만지지 마시고, 현재 어떤 인스턴스가 외부로 열려 있는지부터 봐야 해요. 이 단계 건너뛰면 진짜 자주 꼬여요.
openstack floating ip list
openstack server list --long
openstack port list --server <SERVER_NAME>
openstack security group list
openstack security group rule list <SECURITY_GROUP_NAME>
여기서 확인할 건 세 가지예요:
어떤 인스턴스에 Floating IP가 붙어 있는지
해당 포트에 어떤 보안 그룹이 붙어 있는지
0.0.0.0/0 같은 광범위 Ingress 규칙이 있는지
4-2. 보안 그룹을 최소 허용(Least Privilege)으로 다시 자르기
SSH, HTTPS처럼 꼭 필요한 포트만 열고, 출발지 IP도 가능한 한 좁게 잡는 게 가장 실효성 있어요. 기본처럼 들리지만 체감 효과가 정말 크거든요.
운영 환경이면 22번도 bastion host(배스천 호스트, 점프 서버) 대역으로 더 좁히는 걸 권해요. 저도 처음엔 귀찮아서 넓게 열었다가, 나중에 로그 뒤지면서 후회했거든요.
실전 구현 단계에서 보안 그룹을 최소 허용 형태로 재구성하는 흐름을 설명하는 이미지가 들어갈 자리입니다.
4-3. 특정 Floating IP 직접 지정 권한 줄이기
Neutron 정책 문서를 보면 create_floatingip:floating_ip_address 권한을 따로 제어할 수 있어요. 이게 중요한 이유가 있거든요. Launchpad에 2022년 등록된 논의에서는, 사용자가 특정 IP를 수동 지정할 때 외부 네트워크의 게이트웨이 IP와 같은 값을 요청할 수 있는 운영 리스크가 지적됐어요. 이건 문서상 “무조건 취약점”으로 확정된 CVE는 아니지만, 운영 사고로 번질 수 있는 위험한 설계 포인트가 맞아요.
그래서 실무에서는 보통 임의의 공인 IP 지정 권한을 일반 사용자에게 열어두지 않는 쪽이 낫더라고요.
# /etc/neutron/policy.yaml
create_floatingip: "(rule:admin_only) or (role:member and project_id:%(project_id)s)"
create_floatingip:floating_ip_address: "rule:admin_only"
update_floatingip: "(rule:admin_only) or (role:member and project_id:%(project_id)s)"
delete_floatingip: "(rule:admin_only) or (role:member and project_id:%(project_id)s)"
이렇게 하면 일반 테넌트 사용자는 Floating IP 자체는 할당받되, 특정 공인 IP를 집어서 요청하는 행위는 막을 수 있어요. OpenStack 보안 강화 관점에서 생각보다 효과가 커요.
4-4. 예외 기능 점검하기: Port Security와 Allowed Address Pairs
여기서 많이 놓치는 게 Port Security(포트 보안)예요. 어떤 포트가 --disable-port-security 상태면 보안 그룹 기대치가 달라질 수 있거든요. 그리고 OpenStack API 문서에는 allowed-address-pairs를 특정 방식으로 쓰면, 같은 보안 그룹을 쓰는 포트들에 대해 source IP 제한 성격의 룰 우회가 가능하다는 경고도 있어요.
openstack port show <PORT_ID> -f yaml
openstack port list --long
openstack port set --enable-port-security <PORT_ID>
물론 실제 적용 전에는 LB(Load Balancer, 로드밸런서), VRRP, VIP 같은 예외 설계가 있는지 꼭 확인하셔야 해요. 이 부분 모르고 일괄 적용하면 서비스가 바로 흔들려요. 저도 HA 테스트하다가 VIP가 안 떠서 한참 봤던 기억이 있네요.
4-5. 침해 대응 절차는 “FIP 분리”로 끝내지 않기
이 부분이 제일 중요해요. OSSN-0020 기준으로는, Neutron L3 agent 환경에서 Floating IP를 분리해도 기존 연결이 남을 수 있거든요. 그러니까 의심 세션 차단이 목적이라면 절차를 이렇게 가져가야 한다는 뜻이에요:
인스턴스 상태 확인
필요 시 인스턴스 정지 또는 종료
그 다음 Floating IP 분리
재기동 후 필요한 보안 그룹만 재적용
openstack server stop <SERVER_NAME>
openstack server remove floating ip <SERVER_NAME> <FLOATING_IP>
openstack server start <SERVER_NAME>
환경에 따라 완전 종료 대신 격리 네트워크로 포트를 옮기는 방식도 쓰지만, 최소한 Floating IP만 떼고 끝났다 판단하는 건 위험해요.
5. ⚠️ 실제 운영에서 자주 겪는 문제와 해결법
문제 1: 보안 그룹 룰은 지웠는데 세션이 살아 있어요. 해결: 기존 연결 추적 상태를 의심해야 해요. 긴급 대응이면 인스턴스 정지/격리까지 포함해 절차를 바꾸는 게 안전해요.
문제 2: 특정 테넌트가 이상한 공인 IP를 요청해요. 해결: create_floatingip:floating_ip_address 권한을 축소하고, 직접 지정 대신 자동 할당만 허용하세요.
문제 3: 포트 보안 예외 때문에 정책 검증이 안 맞아요. 해결: port_security_enabled, allowed_address_pairs, 보안 그룹 바인딩 상태를 같이 점검하세요.
문제 4: “기본 보안 그룹이 있으니 괜찮겠지”라고 생각해요. 해결: 기본 그룹은 출발점일 뿐이에요. 워크로드별 전용 그룹으로 분리하는 게 맞아요.
혹시 이런 경험 있으신가요? 콘솔에는 아무 문제 없어 보이는데 실제 네트워크는 다르게 움직이는 상황이요. OpenStack 네트워킹은 특히 이런 “보이는 상태와 실제 데이터 플레인 상태의 차이”가 자주 나타나거든요.
6. 검증: 강화 후 무엇을 확인해야 하나요
설정하고 끝내면 안 돼요. 검증이 없으면 보안은 그냥 희망사항이거든요.
openstack floating ip list --long
openstack security group rule list web-tight
openstack port show <PORT_ID> -f yaml
openstack server show <SERVER_NAME>
Floating IP가 정말 필요한 인스턴스에만 붙어 있는지 확인하세요.
보안 그룹 Ingress 규칙이 최소 범위인지 다시 봐요.
Port Security가 예외 없이 켜져 있는지 점검해요.
의심 인스턴스는 FIP 제거 후 기존 세션이 끊겼는지 운영 절차로 검증하세요.
추가로 가능하다면 FWaaS(Firewall-as-a-Service, 서비스형 방화벽)나 외부 방화벽 계층을 같이 두는 것도 좋아요. 보안 그룹만으로 모든 걸 해결하려고 하면 경계 보안이 얇아져요. 특히 클라우드 보안은 “한 겹 더”가 생각보다 큰 차이를 낸다고 느껴봤거든요.
적용 전후로 외부 노출 범위가 어떻게 줄었는지 보여주는 결과 검증 이미지가 들어갈 자리입니다.
7. 운영 기준으로 정리하는 Floating IP 보안 원칙
원칙
권장 여부
이유
모든 VM에 Floating IP 부여
비권장
공격 표면이 불필요하게 넓어져요.
특정 공인 IP 직접 지정 허용
제한 권장
외부 네트워크와 충돌할 여지를 줄일 수 있어요.
보안 그룹 최소 허용 구성
강력 권장
실수 범위를 가장 확실하게 줄여요.
Port Security 예외 최소화
강력 권장
정책 일관성이 깨지는 걸 막아요.
침해 대응 시 인스턴스 정지 포함
권장
기존 연결 잔존 위험에 대응할 수 있어요.
제가 직접 운영하면서 느낀 건, Floating IP 보안은 네트워크 팀 일만도 아니고, 클라우드 플랫폼 팀 일만도 아니라는 거예요. 권한 정책, 라우팅/NAT 동작, 테넌트 가이드, 대응 플레이북이 같이 맞물려야 드디어 안정된다는 느낌이 들어요. 드디어 됐다 싶을 때도 꼭 한 번 더 검증하는 게 좋거든요.
8. 자주 묻는 질문과 마무리
Q1. Floating IP를 떼면 외부 접근은 즉시 끝나는 것 아닌가요?
그렇지 않아요. 최소한 OSSN-0020에서 설명된 Neutron L3 agent 동작 기준으로는 기존 연결이 남을 수 있거든요.
Q2. 이 이슈가 곧바로 최신 CVE라는 뜻인가요?
그건 아니에요. 이 글은 공식 보안 노트와 문서화된 동작, 그리고 운영상 재현 가능한 위험 지점을 분석한 글이거든요.
Q3. 가장 먼저 적용할 한 가지는 뭔가요?
제라면 특정 Floating IP 직접 지정 권한 제한과 0.0.0.0/0 Ingress 축소부터 하겠어요. 체감 효과가 정말 커요.
보안 그룹 최소 허용, 정책 권한 제한, 포트 보안 점검, 대응 절차 개선을 요약한 인포그래픽이 들어갈 자리입니다.
정리해보면, OpenStack 보안 그룹 취약점을 볼 때 핵심은 “보안 그룹 룰이 있느냐”가 아니라 “그 룰이 실제 연결 종료와 권한 통제까지 보장하느냐”예요. Floating IP는 정말 편해요. 근데 편한 만큼 공격 표면도 넓어지거든요. 이번 기회에 외부 노출 인스턴스 목록, 보안 그룹 예외, policy.yaml 권한까지 한 번에 점검해보시면 좋겠어요.
다음 글에서는 OpenStack 보안 강화 관점에서 RBAC(Role-Based Access Control, 역할 기반 접근 제어)와 프로젝트별 네트워크 분리 전략도 이어서 다뤄볼 계획이에요. 이전 글에서 다뤘던 bastion 구조와 함께 보시면 더 이해가 잘 될 겁니다.
RDO OpenStack 마이그레이션 이야기는 생각보다 많은 분들이 한 번쯤 부딪히는 주제입니다. 처음엔 DevStack(데브스택, OpenStack 개발·테스트용 빠른 배포 도구)으로 가볍게 올려 봤다가, 서비스가 붙고 VM이 늘고 네트워크가 꼬이기 시작하면 그때부터 고민이 깊어지거든요. 저도 홈랩에서 시작했다가 “이걸 계속 DevStack으로 끌고 가는 게 맞나?” 싶은 순간이 왔었습니다. 처음엔 이게 뭔가 싶었는데, 막상 하나씩 뜯어보니 핵심은 단순했습니다. 개발 편의 중심 환경을 운영형 구조로 바꾸는 일, 바로 그겁니다.
특히 DevStack 프로덕션 전환을 고민하시는 분들이라면, 단순히 설치만 다시 하는 문제가 아니라 Nova(노바, 컴퓨트 서비스), Neutron(뉴트론, 네트워크 서비스), Glance(글랜스, 이미지 서비스), Cinder(신더, 블록 스토리지) 같은 구성요소를 어떻게 옮기고 검증할지까지 같이 봐야 합니다. 여기서 중요한 포인트! RDO는 Red Hat 계열 생태계에서 OpenStack 패키지를 다루기 편하게 제공하는 배포판 계열로 많이 이야기되기 때문에, DevStack 다음 단계의 후보로 자주 검토되더라고요.
DevStack 단일 또는 소규모 테스트 환경에서 RDO 기반 역할 분리 구조로 옮겨 가는 흐름을 한눈에 보여주는 이미지입니다.
1. 왜 DevStack에서 RDO OpenStack으로 옮기게 되나
쉽게 말해 DevStack은 빨리 띄워서 기능을 확인하는 데 최적화되어 있어요. 반대로 운영 관점에서는 아쉬운 부분이 꽤 보입니다. 서비스 재기동 순서, 설정 누적 관리, 패키지 일관성, 장기 운영 시 변경 추적 같은 부분에서요. 저도 처음엔 “테스트 잘 되는데 굳이?”라고 생각했는데, 장애를 두 번 겪고 생각이 바뀌었습니다 ㅎㅎ
DevStack: 빠른 실험, API 테스트, 기능 검증에 강점
RDO: 패키지 기반 운영, 구성 관리, 역할 분리 설계에 유리
핵심 차이: 편의성 중심이냐, 운영 일관성 중심이냐죠
특히 클라우드 환경 이전에서는 “서비스가 떠 있느냐”보다 “문제가 났을 때 추적 가능한가”가 더 중요합니다. 제가 직접 해보니, 이 시점부터는 설치 속도보다 운영 구조가 훨씬 중요해지더라고요.
2. 개념부터 정리: DevStack과 RDO의 차이
혹시 이런 경험 있으신가요? DevStack으로는 금방 Horizon(호라이즌, 웹 대시보드)까지 열리는데, 며칠 지나고 설정을 다시 손보려 하면 어디서 바꿨는지 기억이 안 나는 경우요. 저도 그랬거든요. 그래서 먼저 개념을 분리해서 봐야 합니다.
OpenStack 배포판 선택에서 중요한 건 “무엇이 더 고급이냐”가 아니에요. 내 환경에서 변경 관리와 장애 대응이 가능한가, 이 질문이 더 중요합니다. 쉽게 말해 DevStack은 ‘빨리 시작하는 도구’이고, RDO는 ‘운영 구조를 갖춰 가는 출발점’에 가깝습니다.
3. 마이그레이션 전에 반드시 정리할 체크리스트
여기서 바로 설치로 들어가면 삽질 확률이 꽤 높아요. 저는 이 단계를 가볍게 봤다가 네트워크 이름하고 브리지 매핑을 뒤엎는 바람에 시간을 좀 썼습니다. 드디어 됐다 싶었는데 인스턴스가 외부 통신이 안 되더라고요.
현재 리소스 인벤토리 작성: 인스턴스, 이미지, 볼륨, 플로팅 IP, 보안그룹 목록 정리
네트워크 설계 고정: Management(관리망), Provider(프로바이더망), Tenant(테넌트망) 구분
서비스 우선순위 지정: 어떤 워크로드를 먼저 옮길지 결정
다운타임 기준 수립: 이미지 기반 재배포인지, 데이터 복제인지 미리 확정
백업 확보: DB, 설정 파일, 이미지, 중요한 볼륨 스냅샷 확보
아래처럼 최소한의 현황 수집 명령은 먼저 뽑아 두는 걸 권합니다.
openstack service list
openstack endpoint list
openstack hypervisor list
openstack server list --all-projects
openstack image list
openstack volume list --all-projects
openstack network list
openstack subnet list
openstack router list
openstack security group list
이 출력 결과를 저장해 두면, 나중에 클라우드 환경 이전 검증할 때 비교 기준이 생깁니다. 이거 진짜 편하더라고요.
4. 실전 구현 1: DevStack 환경 백업과 추출
제가 실제로 먼저 했던 건 “새 환경 설치”가 아니라 “기존 환경을 최대한 읽을 수 있게 만드는 것”이었어요. 그래야 옮긴 뒤에 빠진 걸 찾을 수 있거든요.
4-1. 설정 파일과 데이터 백업
sudo mkdir -p /backup/devstack
sudo cp -a /etc/nova /backup/devstack/
sudo cp -a /etc/neutron /backup/devstack/
sudo cp -a /etc/glance /backup/devstack/
sudo cp -a /etc/cinder /backup/devstack/
sudo mysqldump --all-databases > /backup/devstack/openstack-all.sql
물론 실제 경로와 데이터베이스 접속 방식은 환경마다 다릅니다. 중요한 건 서비스 설정과 메타데이터를 같이 남겨 두는 것이에요.
4-2. 이미지와 중요 리소스 추출
mkdir -p ~/migration/images
for id in $(openstack image list -f value -c ID); do
name=$(openstack image show "$id" -f value -c name | tr ' ' '_')
openstack image save --file ~/migration/images/${name}.qcow2 "$id"
done
볼륨 기반 워크로드는 더 신중해야 해요. 인스턴스 이미지로만 끝나는 게 아니라 애플리케이션 데이터 정합성까지 봐야 하니까요. 데이터베이스가 올라간 인스턴스라면 파일 복사 전에 서비스 정지나 스냅샷 정책을 꼭 정해 두셔야 합니다.
기존 DevStack에서 이미지, 설정, 데이터베이스 메타데이터를 백업하는 절차를 설명하는 이미지입니다.
5. 실전 구현 2: RDO 설치와 운영형 구조 맞추기
이제 RDO 설치 단계네요. 여기서는 “한 번에 완성”보다 “먼저 표준 구조를 세운다”가 중요합니다. 저는 처음에 all-in-one으로 빨리 띄우고 끝내려다가, 결국 역할 분리 구조를 다시 고민하게 됐어요. 그래서 테스트용과 운영형 설계를 분리해서 접근했습니다.
위 예시는 개념 설명용이에요. 실제 인터페이스 이름과 대역은 환경에 맞게 바꾸셔야 합니다. 저도 처음엔 브리지 이름을 대충 맞췄다가 Neutron L3 에이전트가 제대로 붙지 않아서 한참 봤습니다.
5-3. 기본 검증 명령
openstack compute service list
openstack network agent list
openstack catalog list
openstack hypervisor stats show
이 단계에서 서비스 등록과 에이전트 상태가 깔끔하게 보이면 다음으로 넘어가도 돼요. 반대로 여기서 빨간불이 보이면, 워크로드부터 옮기지 마시고 구조부터 다시 점검하세요. 경험상 이 순서가 시간을 아낍니다.
6. 주의사항과 트러블슈팅: 제가 실제로 막혔던 지점들
RDO OpenStack 마이그레이션에서 제일 많이 막히는 건 화려한 기능이 아니라 기본값 차이에요. 진짜 별거 아닌 설정 하나 때문에 반나절이 날아가더라고요.
6-1. ⚠️ Neutron 브리지 매핑 불일치
DevStack에서는 자동으로 맞아 들어가던 부분이 RDO에서는 더 명시적으로 보여요. physnet 이름, OVS(오픈 브이스위치) 브리지, NIC 매핑이 안 맞으면 외부 통신이 바로 안 됩니다.
증상: 플로팅 IP 연결은 되는데 외부 통신 실패
확인 포인트: bridge_mappings, external bridge, provider network 설정
해결: 물리 NIC와 브리지 연결을 다시 확인하고 에이전트 재기동
6-2. ⚠️ 보안그룹과 메타데이터 접근 차이
인스턴스는 떴는데 SSH가 안 붙는 경우, 의외로 보안그룹이 원인인 경우가 많아요. 메타데이터 서비스 경로도 같이 봐야 하고요.
openstack security group rule list default
openstack port list --server <SERVER_ID>
ping -c 3 <FLOATING_IP>
ssh -i ~/.ssh/id_rsa cloud-user@<FLOATING_IP>
6-3. ⚠️ 이미지 포맷과 드라이버 기대값 차이
Glance 이미지 자체는 옮겨졌는데 부팅이 실패하는 경우도 있었어요. 이럴 때는 이미지 속성, 디스크 포맷, 하이퍼바이저 기대값을 같이 확인해야 합니다.
qcow2인지 raw인지 확인
virtio 드라이버 지원 여부 확인
cloud-init(클라우드 이닛, 초기 설정 자동화) 동작 여부 확인
저도 처음엔 “이미지만 있으면 끝 아닌가?” 했는데, 실제로 써보니까 인스턴스 부팅 옵션이 미묘하게 달라서 예상 외로 시간이 걸렸어요.
RDO 환경에서 네트워크 브리지, 에이전트 상태, 서비스 정상 여부를 검증하는 장면을 보여주는 이미지입니다.
7. 검증과 결과 확인: 옮긴 뒤 무엇을 봐야 하나
운 좋게 인스턴스가 부팅됐다고 끝이 아니에요. 여기서부터가 진짜 검증입니다. 저는 아래 순서대로 확인했습니다.
서비스 상태 확인: API, 스케줄러, 네트워크 에이전트
테스트 인스턴스 생성: 신규 부팅이 되는지 확인
외부 통신 확인: 플로팅 IP, NAT, 보안그룹 확인
스토리지 검증: 볼륨 생성, 연결, 분리 테스트
이미지 재사용성 확인: 기존 백업 이미지로 재배포 테스트
openstack server create \
--flavor m1.small \
--image test-image \
--network private \
--security-group default \
test-vm
openstack server list
openstack console log show test-vm
openstack floating ip create public
검증이 끝나면 꼭 결과를 문서화해 두세요. 어떤 네트워크 이름을 썼는지, 어떤 보안그룹 규칙이 필요한지, 어떤 이미지가 정상 부팅되는지 남겨 두면 다음 노드 증설 때 훨씬 수월합니다. 이건 멘토링할 때도 늘 강조하는 부분이에요.
🎉 개인적으로 가장 큰 성과는 “문제가 나도 어디를 봐야 하는지 감이 생겼다”는 점이었어요. DevStack에서는 빠르게 실험할 수 있었고, RDO 쪽으로 오면서 운영 기준선이 생겼습니다.
인스턴스 생성, 네트워크 연결, 서비스 상태가 정상으로 확인된 결과 화면을 표현하는 이미지입니다.
8. 정리와 FAQ: DevStack 프로덕션 전환 전에 꼭 생각할 점
결론부터 말씀드리면, DevStack에서 RDO OpenStack으로 마이그레이션은 단순 재설치가 아니라 운영 철학을 바꾸는 작업에 가깝습니다. 빨리 띄우는 환경에서, 반복 가능하고 설명 가능한 환경으로 넘어가는 거죠. 저도 처음엔 헷갈렸는데, 기준을 딱 하나로 잡으니 훨씬 쉬웠어요. “이 구성이 다음 달에도 내가 설명할 수 있는가?” 바로 그 질문이에요.
다음 글에서는 이미지 카탈로그 정리, 네트워크 설계 분리, 그리고 베어메탈 자원과 연동할 때 체크할 포인트도 다뤄볼 예정입니다. 이전 글에서 다뤘던 홈랩 네트워크 설계 글과 연결해서 보시면 더 이해가 잘 되실 겁니다.
자주 묻는 질문
Q. DevStack을 그대로 운영에 써도 되나요? 짧게 말씀드리면 권장하긴 어려워요. 테스트와 학습에는 정말 좋지만, 장기 운영과 변경 관리까지 생각하면 운영형 구조 검토가 필요하더라고요.
Q. RDO만이 정답인가요? 아닙니다. 다만 Red Hat 계열 환경과 패키지 기반 운영을 선호한다면 좋은 후보가 됩니다. 결국 OpenStack 배포판 선택은 팀 역량과 운영 기준에 달렸어요.
Q. 다운타임 없이 이전할 수 있나요? 워크로드 성격에 따라 다릅니다. 상태 저장 서비스는 별도 복제 전략이 필요하고, 무상태 워크로드는 이미지 기반 재배포가 비교적 수월해요.
💡 마지막 팁 하나만 드리면, 처음부터 완벽하게 옮기려 하지 마세요. 제 경험상 제일 잘 되는 방법은 작은 서비스 하나를 끝까지 이전하고 검증한 뒤 패턴을 복제하는 방식이었어요.
DevStack과 RDO의 차이, 이전 체크리스트, 검증 포인트를 한 장으로 정리한 요약 이미지입니다.
DevStack OpenStack 연동 문제는 생각보다 자주 만납니다. 설치는 얼추 끝난 것 같은데 인스턴스가 안 뜨고, 네트워크가 안 붙고, 이미지 조회는 되는데 부팅은 실패하고, 로그를 보면 Keystone(키스톤, 인증 서비스) 쪽 인증 에러가 한 줄씩 튀어나오거든요. 저도 홈랩에서 개발 환경을 구성하면서 이런 삽질을 꽤 했더라고요. 처음엔 서비스가 각각 살아 있으면 되는 줄 알았는데, 실제로는 서비스 간 엔드포인트(endpoint, 접속 지점), 메시지 큐(message queue), 데이터베이스(database), 서비스 사용자(service user) 권한이 한 군데만 어긋나도 전체 흐름이 무너집니다.
이번 글은 제품 홍보나 이론 소개가 아니라, 제가 직접 DevStack 개발 환경에서 반복적으로 겪었던 OpenStack 서비스 연동 문제를 어떤 순서로 확인하고 풀었는지 정리한 실전형 트러블슈팅 가이드입니다. 혹시 DevStack 트러블슈팅 하다가 로그만 한참 보고 계셨다면, 이 순서대로 점검해 보시면 시간 꽤 아끼실 수 있을 겁니다.
Keystone, Nova, Neutron, Glance, Cinder가 DevStack 환경에서 어떻게 연결되는지 한눈에 보여주는 개요 이미지입니다.
1. 왜 DevStack 개발 환경에서 OpenStack 서비스 연동 문제가 자주 생길까
쉽게 말해 DevStack은 빠르게 OpenStack을 올려서 개발과 검증을 하기 위한 환경입니다. 그래서 편한 점도 많지만, 반대로 서비스가 많고 연결 지점도 많습니다. 예를 들어 Nova(노바, 컴퓨트 서비스)가 인스턴스를 띄우려면 Keystone에서 토큰 인증을 받고, Glance(글랜스, 이미지 서비스)에서 이미지를 읽고, Neutron(뉴트론, 네트워크 서비스)에서 포트를 만들고, 필요하면 Cinder(신더, 블록 스토리지)까지 붙어야 하거든요.
즉, 화면에서 보이는 실패 증상은 하나인데 원인은 여러 군데일 수 있습니다. 여기서 중요한 포인트! 증상 기준으로 보지 말고 요청 흐름 기준으로 봐야 빨리 잡힙니다. 저도 처음엔 Horizon(호라이즌, 대시보드)에서 에러만 보고 있었는데, 실제 원인은 RabbitMQ(래빗MQ, 메시지 브로커) 연결 문제였던 적도 있더라고요.
2. OpenStack 서비스 연동을 흐름으로 이해하기
OpenStack 서비스 연동을 너무 어렵게 볼 필요는 없습니다. 요청 하나가 아래처럼 지나간다고 생각하시면 됩니다.
사용자 또는 CLI가 Keystone에 인증 요청을 보냅니다.
인증이 끝나면 서비스 카탈로그(service catalog, 서비스 목록)와 토큰을 받습니다.
Nova가 Glance, Neutron, Placement 같은 다른 서비스와 통신합니다.
백엔드에서는 메시지 큐와 데이터베이스가 중간 연결을 받쳐줍니다.
문제가 생기면 API 응답, 서비스 로그, 백엔드 연결 상태 중 하나가 어긋납니다.
구성 요소
역할
연동 실패 시 흔한 증상
Keystone
인증/권한/엔드포인트 관리
401 Unauthorized, endpoint not found
Nova
가상머신 생성 및 제어
인스턴스 build 실패, scheduling 오류
Neutron
네트워크/포트/IP 관리
포트 생성 실패, floating IP 연결 불가
Glance
이미지 저장 및 조회
이미지 다운로드 실패, boot from image 오류
Cinder
볼륨 제공
볼륨 attach 실패, device not found
이 표만 머리에 넣어도 DevStack OpenStack 연동 문제를 볼 때 훨씬 덜 막막합니다. 사실 로그를 읽는 요령도 결국은 어느 서비스가 다음 서비스를 못 찾고 있는지를 보는 거거든요.
3. DevStack 트러블슈팅 전에 먼저 확인할 기본 체크리스트
본격적으로 로그 보기 전에, 저는 아래 항목부터 먼저 봅니다. 사소해 보여도 여기서 많이 걸립니다.
호스트명과 IP: 서비스가 등록된 주소와 실제 바인딩 주소가 같은지
/etc/hosts: 로컬 이름 해석이 꼬이지 않았는지
시스템 시간: 토큰 인증 문제를 만들 정도로 시간 차이가 없는지
포트 리스닝 상태: 각 API 서비스가 실제로 떠 있는지
환경 변수: admin-openrc 같은 OpenRC 파일을 제대로 불러왔는지
제가 직접 해보니, OpenRC를 안 읽은 상태에서 CLI 테스트를 해서 Keystone 문제로 착각한 경우가 제일 허무했습니다. 드디어 원인 찾았다 싶었는데 그냥 환경 변수 누락이더라고요.
cd ~/devstack
source openrc admin admin
openstack token issue
openstack service list
openstack endpoint list
위 명령이 정상 동작하면 최소한 Keystone 인증과 서비스 카탈로그 조회는 된다는 뜻입니다. 여기서부터 하나씩 좁혀가면 됩니다.
4. 실전 구현: DevStack 환경에서 서비스 연동 상태 점검 순서
4-1. DevStack 설정 파일부터 다시 봅니다
local.conf에 서비스 활성화가 빠져 있거나, 비밀번호 변수 구성이 엇갈리면 설치는 돼도 연동이 흔들립니다. 아래는 가장 기본적인 예시입니다.
여기서는 이미지 상태가 active 인지, 접근 권한 문제는 없는지, Nova가 해당 이미지를 실제 읽을 수 있는지 확인합니다.
5-4. RabbitMQ 또는 DB 연결 문제로 서비스가 간헐적으로 실패하는 경우
이건 더 골치 아픕니다. 같은 명령이 한 번은 되고 한 번은 안 되거든요. 저도 실제로 써보니까 간헐 장애는 오히려 더 찾기 어렵더라고요.
sudo systemctl status rabbitmq-server
sudo systemctl status mariadb
sudo journalctl -u rabbitmq-server -n 100 --no-pager
메시지 큐나 DB 연결이 흔들리면 각 서비스 로그에 timeout, reconnect, access denied 같은 메시지가 섞여 나옵니다. 이럴 때는 개별 서비스보다 공통 백엔드부터 의심하는 게 빠릅니다.
여러 OpenStack 서비스 로그를 비교해서 장애 지점을 추적하는 실제 운영 감각의 트러블슈팅 이미지입니다.
6. 검증: 어디까지 확인해야 진짜 해결된 걸까
로그 한 줄 없어졌다고 끝난 건 아닙니다. 저는 아래 순서가 모두 통과하면 그제야 해결로 봅니다.
토큰 발급이 정상 동작한다.
서비스 목록과 엔드포인트가 정상 조회된다.
이미지, 네트워크, 플래버 목록 조회가 된다.
테스트 네트워크와 서브넷 생성이 된다.
테스트 인스턴스가 ACTIVE 또는 기대 상태로 전환된다.
필요 시 floating IP 연결 또는 콘솔 접속이 된다.
openstack token issue
openstack endpoint list
openstack network list
openstack subnet list
openstack image list
openstack server create --flavor m1.tiny --image cirros --network demo-net test-vm
openstack server list
openstack console url show test-vm
이 단계까지 가면 DevStack OpenStack 연동 문제는 대부분 정리됩니다. 물론 테스트 이미지나 플래버는 환경에 따라 다를 수 있으니, 현재 설치 상태에 맞게 조정하시면 됩니다.
서비스 연동이 정상화된 뒤 CLI와 대시보드에서 인스턴스, 네트워크, 이미지가 모두 보이는 결과 이미지입니다.
7. 빠른 진단 기준
증상
먼저 볼 곳
우선 점검 포인트
401 인증 오류
Keystone
OpenRC, 토큰, 서비스 사용자 비밀번호
인스턴스 생성 실패
Nova
Glance/Neutron/Placement 연동
포트 생성 실패
Neutron
agent 상태, 브리지 구성, endpoint
이미지 부팅 실패
Glance
이미지 상태, 접근 권한, API 응답
간헐적 timeout
RabbitMQ/DB
공통 백엔드 연결 안정성
이 표는 제가 실제로 자주 참고하는 기준입니다. 독자분들도 로그를 보기 전에 먼저 증상별 1차 의심 지점을 잡아두면 훨씬 덜 헤매실 겁니다.
8. 자주 묻는 질문과 실무 팁
Q1. 서비스가 모두 떠 있는데도 왜 연동이 안 될까요?
A. 프로세스가 떠 있는 것과 API 호출이 성공하는 것은 다릅니다. endpoint 등록, 권한, 환경 변수, 에이전트 상태를 같이 보셔야 합니다.
Q2. DevStack을 다시 설치하는 게 더 빠를 때도 있나요?
A. 있습니다. 특히 실험을 여러 번 반복하면서 설정이 꼬였을 때는 부분 수정보다 재구성이 빠를 때가 있더라고요. 다만 그 전에 왜 꼬였는지를 한 번 정리해 두면 다음부터 훨씬 빨라집니다.
Q3. 로그는 어디부터 봐야 하나요?
A. 사용자 요청이 처음 닿는 지점부터 보는 게 좋습니다. 예를 들어 인스턴스 생성 실패면 Nova API부터 보고, 그 다음 Neutron/Glance 쪽 연동 로그를 따라가는 방식이 효율적입니다.
💡 팁: CLI 테스트는 Horizon보다 원인 분리가 쉽습니다.
💡 팁: 한 번에 여러 문제를 고치지 말고, 한 항목씩 검증하세요.
💡 팁: 변경 전 endpoint 목록과 서비스 상태를 저장해 두면 비교가 편합니다.
인증, 네트워크, 이미지, 인스턴스 생성 문제를 어떤 순서로 점검할지 한 장으로 정리한 요약 인포그래픽입니다.
9. 마무리: DevStack 트러블슈팅의 핵심은 흐름을 보는 눈입니다
이번 글에서는 DevStack OpenStack 연동 문제를 단순히 에러 메시지별로 보는 대신, 서비스 요청 흐름 기준으로 점검하는 방법을 정리해 봤습니다. 저도 처음엔 서비스 이름이 너무 많아서 겁부터 났었는데, 실제로는 Keystone, Nova, Neutron, Glance, Cinder가 어떻게 이어지는지만 잡아도 절반은 해결되더라고요.
정리하면 이렇습니다. 인증이 되는지 확인하고, 엔드포인트가 맞는지 보고, 서비스별 실제 생성 요청을 날려보고, 공통 백엔드까지 확인한다. 이 순서가 DevStack 트러블슈팅에서 꽤 강력합니다. 다음 글에서는 DevStack 환경에서 Neutron 네트워크를 조금 더 깊게 파서, 브리지 구성과 외부 네트워크 연결 쪽도 따로 다뤄볼 예정입니다. 이전 글에서 다뤘던 OpenStack 기본 구성 이해 편이 있으시다면 같이 보시면 흐름 잡는 데 더 도움이 될 겁니다.
혹시 지금 비슷한 OpenStack 서비스 연동 문제를 겪고 계시다면, 오늘 소개한 체크리스트만 따라가도 원인 범위를 꽤 빨리 좁히실 수 있을 겁니다. 드디어 됐다! 하는 순간이 분명 오거든요. 그 맛에 또 홈랩 만지게 됩니다 ㅎㅎ
![[OpenStack] OpenStack 프로젝트 테넌트 격리 전략 비교와 보안 강화](https://blog.pswq.net/wp-content/uploads/2026/08/openstack-project-tenant-isolation-security-strategies-thumbnail.jpg)
![[OpenStack] 오픈스택 운영 회고: 안정성, 비용, 그리고 인프라 관리의 핵심](https://blog.pswq.net/wp-content/uploads/2026/08/openstack-3year-operation-retrospective-lessons-thumbnail.jpg)
![[OpenStack] OpenStack 프라이빗 클라우드 보안 강화: 최신 감사 보고서 분석 및 대응 전략](https://blog.pswq.net/wp-content/uploads/2026/08/openstack-private-cloud-security-audit-analysis-thumbnail.jpg)
![[OpenStack] OpenStack 업그레이드 10가지 체크리스트: 실전 베스트 프랙티스로 성공 확률 높이기](https://blog.pswq.net/wp-content/uploads/2026/08/openstack-upgrade-checklist-best-practices-thumbnail.jpg)
![[클라우드 보안] OpenStack 보안 그룹 취약점과 Floating IP 보안 강화 전략](https://blog.pswq.net/wp-content/uploads/2026/07/openstack-security-group-vulnerability-floating-ip-thumbnail.jpg)
![[OpenStack] RDO OpenStack 마이그레이션: DevStack에서 운영형 배포로 전환하기](https://blog.pswq.net/wp-content/uploads/2026/07/devstack-rdo-openstack-migration-guide-thumbnail.jpg)
![[OpenStack] DevStack 환경에서 OpenStack 서비스 간 연동 문제 해결 가이드](https://blog.pswq.net/wp-content/uploads/2026/07/devstack-openstack-inter-service-troubleshooting-thumbnail.jpg)
