OpenStack 프로젝트 테넌트 격리 전략 비교와 보안 강화

OpenStack 프로젝트 테넌트 격리는 멀티테넌트 환경에서 가장 먼저 다져야 하는 기본기입니다. 겉으로는 프로젝트만 나누면 끝나 보이지만, 실제 운영에 들어가면 네트워크, 권한, 이미지, 볼륨, 스케줄링까지 같이 봐야 하더라고요. 저도 초반에는 프로젝트만 분리하면 충분하다고 생각했는데, 나중에 보니 공유 네트워크 하나가 경계를 흐리는 경우가 있었습니다.

이번 글에서는 OpenStack 프로젝트 테넌트 격리를 어디까지 논리적으로 나눌지, 어디서부터 물리적 성격의 분리를 추가할지 비교해보겠습니다. 체크리스트만 훑는 글이 아니라, OpenStack 보안 관점에서 무엇을 먼저 적용해야 하는지와 테넌트 분리 수준별 운영 비용까지 같이 정리해보겠습니다.

프로젝트, 네트워크, 하이퍼바이저, 스토리지 계층이 어떻게 분리되는지 한눈에 보여주는 아키텍처 이미지입니다.

왜 OpenStack 프로젝트 테넌트 격리에서 프로젝트만 나누면 끝이 아닐까

쉽게 말해 프로젝트는 행정 구역에 가깝고, 실제 경계는 따로 있습니다. 사용자는 프로젝트 기준으로 자원을 보지만, 패킷 흐름, 이미지 접근 권한, 볼륨 연결, 컴퓨트 노드 배치까지 자동으로 다 분리되지는 않거든요. 그래서 프로젝트 분리는 출발점일 뿐이고, 그 바깥 계층을 같이 설계해야 실전에서 흔들리지 않습니다.

• Identity: 누가 어떤 프로젝트에 들어갈 수 있는지 결정합니다.
• Network: 테넌트 간 동서 트래픽을 제어하는 핵심 축입니다.
• Compute: 같은 하이퍼바이저에 섞을지, 분리할지 정합니다.
• Storage: 이미지와 볼륨이 의도치 않게 공유되지 않도록 막아야 합니다.
• Policy/RBAC: 운영자 권한이 지나치게 넓으면 격리 설계가 쉽게 무너집니다.

운영해보면 사고는 화려한 기능보다 기본 설정 하나를 공유 상태로 둔 채 지나간 부분에서 더 자주 납니다. 특히 Horizon과 CLI로 만든 리소스가 섞이면 누가 무엇을 어떤 의도로 공유했는지 추적이 꽤 까다롭습니다. 이 지점이 생각보다 중요하더라고요.

OpenStack 프로젝트 테넌트 격리 전략, 4단계로 나눠서 보기

현업에서는 보통 4단계로 나눠 봅니다. 아래 표는 설계 검토할 때 바로 가져다 쓰기 좋은 기준에 가깝습니다.

핵심은 단순합니다. OpenStack 보안은 기능 하나로 끝나지 않습니다. 프로젝트 분리는 시작이고, 네트워크와 권한 모델을 어떻게 묶느냐가 실제 체감 보안을 좌우합니다.

기본 골격: 프로젝트, 사용자, 권한부터 단단하게

처음 설계할 때는 프로젝트를 조직 단위로만 나누기 쉬운데, 실제로 써보면 환경 단위(dev, stage, prod)까지 별도 프로젝트로 자르는 편이 운영이 훨씬 편합니다. 같은 팀이라도 운영 환경과 개발 환경이 섞이면 이미지 공유나 보안 그룹 재사용이 자연스럽게 생기거든요. 나중에 감사나 장애 대응 때 차이가 꽤 크게 납니다.

1. 프로젝트를 환경 또는 고객 기준으로 분리합니다.
2. 사용자는 최소 권한 원칙에 맞춰 필요한 프로젝트에만 넣습니다.
3. 운영자 계정은 범용 admin 하나로 뭉개지 말고 역할을 나눕니다.
4. 공유 리소스는 허용보다 금지를 기본값으로 잡습니다.

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 공유는 예외 승인 방식으로 돌리는 게 번거로워 보여도, 사고 예방 효과는 확실합니다.

openstack network create --project prod-team-a prod-team-a-net
openstack subnet create --project prod-team-a \
  --network prod-team-a-net \
  --subnet-range 10.10.10.0/24 \
  prod-team-a-subnet

openstack router create --project prod-team-a prod-team-a-router
openstack router add subnet prod-team-a-router prod-team-a-subnet
openstack router set --external-gateway public prod-team-a-router

openstack security group create --project prod-team-a prod-team-a-web-sg
openstack security group rule create --ingress --ethertype IPv4 \
  --protocol tcp --dst-port 22 prod-team-a-web-sg
openstack security group rule create --ingress --ethertype IPv4 \
  --protocol tcp --dst-port 443 prod-team-a-web-sg

openstack network rbac list
openstack security group rule list prod-team-a-web-sg

이 구간에서 자주 나오는 실수도 비슷합니다. 외부 게이트웨이만 다르면 충분하다고 생각하거나, 보안 그룹 규칙을 여러 프로젝트에서 관성적으로 복사해 쓰는 경우죠. 처음엔 편한데 규칙이 커질수록 누가 왜 열었는지 설명이 안 됩니다.

각 프로젝트가 독립된 네트워크와 라우터를 가지며, 외부망은 공용이더라도 내부 통신 경계는 분리되는 구조를 보여주는 이미지입니다.

운영하다 보면 테스트 서버 때문에 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 프로젝트 테넌트 격리가 잘 됐는지 보려면 리소스가 생성됐는지만 보면 부족합니다. 다른 프로젝트 사용자 입장에서 안 보여야 할 것이 정말 안 보이는지, 붙으면 안 되는 네트워크가 실제로 안 붙는지까지 확인해야 합니다. 결국 중요한 건 설정값이 아니라 경계가 의도대로 작동하는지입니다.

1. 프로젝트 A 계정으로 로그인해 프로젝트 B의 네트워크, 인스턴스, 볼륨이 보이는지 확인합니다.
2. RBAC 목록에서 예상하지 못한 공유 규칙이 없는지 확인합니다.
3. 공개 이미지와 공유 이미지 목록을 각각 점검합니다.
4. 보안 그룹 규칙에 과도한 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 규칙, 공개 이미지 수를 점검하는 운영 검증 화면을 표현한 이미지입니다.

비교해보면, 어떤 전략을 선택해야 할까

이쯤 되면 선택 기준이 조금 선명해집니다. 모든 환경에 최고 강도의 분리를 넣는다고 꼭 좋은 건 아닙니다. 운영 복잡도가 확 올라가거든요. 반대로 고객 서비스나 민감 데이터 환경인데 기본 논리 분리만 두는 것도 위험합니다.

이 표는 정답표라기보다, 실제 운영에서 어디까지 해야 충분한지 가늠하는 기준점에 가깝습니다. 저도 가벼운 실험 환경에서는 단순하게 갔지만, 운영 환경으로 갈수록 네트워크와 권한 모델을 먼저 단단히 다지는 쪽이 결과가 좋았습니다.

FAQ: OpenStack 프로젝트 테넌트 격리에서 헷갈리는 포인트

프로젝트만 나누면 테넌트 분리가 끝난 건가요?

아닙니다. 프로젝트는 시작점입니다. 네트워크 공유, 이미지 공개 또는 공유, 운영자 권한 범위가 남아 있으면 경계가 충분하지 않을 수 있습니다.

보안 그룹만 잘 쓰면 되지 않나요?

보안 그룹은 중요하지만 전부가 아닙니다. 라우터, RBAC, 이미지 접근, 컴퓨트 배치까지 같이 봐야 진짜 클라우드 보안이 됩니다.

가용 영역 분리는 언제 필요할까요?

고객별 워크로드 분리, 규제 대응, 성능 간섭 완화가 필요할 때 고려합니다. 다만 운영 복잡도가 올라가니 일반 개발 환경에는 과할 수 있습니다.

현업 기준으로 권고를 딱 정리하면

팀 내부 개발 환경이라면 프로젝트 분리, 프로젝트별 네트워크, 최소 권한 모델까지만 해도 효과가 큽니다. 이 조합이 운영 부담 대비 효율이 가장 좋습니다. 반면 외부 고객이 함께 쓰는 멀티테넌트 클라우드라면 여기서 멈추기 아쉽습니다. 그 경우에는 네트워크 공유 금지, 이미지 공개 최소화, AZ 또는 Host Aggregate 기반 배치 분리까지 넣는 편이 맞습니다.

민감 데이터가 있는 서비스라면 더 분명합니다. 스토리지 암호화와 볼륨 타입 분리까지 포함해 전 계층으로 끌고 가는 게 낫습니다. 운영은 조금 복잡해져도, 사고 이후 설명 비용보다 훨씬 싸게 먹힙니다. 다음 글에서는 Keystone 역할 설계와 서비스 계정 분리 패턴도 다뤄보겠습니다. 이전 글의 보안 그룹 운영 기준과 함께 보면 흐름이 더 잘 잡힐 겁니다.

개발, 운영, 외부 고객, 민감 정보 환경별로 어떤 격리 전략을 선택해야 하는지 요약한 인포그래픽 이미지입니다.