[OpenStack] OpenStack Keystone 인증 시스템, 1년 운영 후기 및 보안 강화 팁

목차

• 1. 왜 Keystone이 운영에서 그렇게 중요할까요?
• 2. Keystone 핵심 개념, 쉽게 말해 이렇게 이해하면 됩니다
• 토큰 방식은 왜 신경 써야 할까요?
• 3. 제가 1년 운영하면서 정착한 기본 구성
• 4. 실전 구현: Keystone 기본 설정과 보안 초기값
• 4-1. Fernet 키 초기화
• 4-2. bootstrap 실행
• 4-3. 기본 환경 변수 설정
• 4-4. 프로젝트, 사용자, 역할 생성
• 4-5. 설정 파일에서 꼭 보는 항목
• 5. Keystone 보안, 실제로 효과 있었던 강화 팁
• 5-1. TLS 적용은 선택이 아니었습니다
• 5-2. Fernet 키 회전 자동화
• 5-3. 시간 동기화는 사소해 보여도 필수입니다
• 5-4. 서비스 카탈로그와 엔드포인트 정리
• 5-5. Application Credential 적극 활용
• 6. ⚠️ 운영 중 실제로 겪었던 문제와 해결 방법
• 6-1. 토큰이 가끔만 실패하는 문제
• 6-2. Horizon 로그인은 되는데 일부 메뉴가 비정상인 문제
• 6-3. 서비스 계정 비밀번호 변경 후 연쇄 장애
• 7. 검증: 운영 상태는 이렇게 확인했습니다
• 8. Fernet, 계정 관리, 엔드포인트 운영 기준 정리
• 9. 마무리: Keystone은 결국 운영 습관 싸움입니다
• 자주 묻는 질문
• Keystone만 안정적이면 나머지 OpenStack 서비스도 괜찮을까요?
• OpenStack 보안에서 가장 먼저 손댈 부분은 뭔가요?
• 인증 시스템 관리는 얼마나 자주 점검하면 좋을까요?

[OpenStack] OpenStack Keystone 운영 후기와 보안 강화 팁

OpenStack Keystone 운영 후기 이야기를 해보려고 합니다. 클라우드를 처음 올릴 때는 Nova(노바, 컴퓨트), Neutron(뉴트론, 네트워크), Cinder(신더, 블록 스토리지) 쪽이 더 눈에 잘 들어오는데요. 실제로 1년 정도 굴려보면 장애의 시작점이 생각보다 Keystone(키스톤, 인증 및 권한 관리 서비스)인 경우가 꽤 많습니다. 로그인은 되는데 토큰이 안 맞는다든지, 서비스 계정 권한이 꼬인다든지, 외부에 노출된 엔드포인트(endpoint, 서비스 접속 지점) 관리가 애매해진다든지요. 저도 처음엔 이게 뭔가 싶었는데, 막상 운영해보니 Keystone은 단순한 로그인 서버가 아니라 OpenStack 전체의 신뢰 기준점이더라고요.

특히 홈랩과 사내 테스트 환경을 같이 운영하면서 느낀 건, Keystone 보안과 인증 시스템 관리가 느슨하면 나머지 서비스도 같이 흔들린다는 점이었습니다. 이번 글에서는 제가 직접 겪은 OpenStack Keystone 운영 후기와 함께, 실제로 효과 있었던 OpenStack 보안 강화 팁을 정리해보겠습니다.

Keystone이 사용자, 프로젝트, 역할, 토큰, 각 OpenStack 서비스 사이에서 어떻게 동작하는지 보여주는 전체 구조 예시입니다.

1. 왜 Keystone이 운영에서 그렇게 중요할까요?

쉽게 말해 Keystone은 누가, 어디까지, 어떤 방식으로 접근할 수 있는지를 판단하는 관문입니다. 사용자는 인증(authentication, 본인 확인)을 받고, 그 다음 권한 부여(authorization, 접근 허용 범위 결정)를 통해 프로젝트(project, 테넌트 성격의 작업 공간)와 역할(role, 권한 묶음)에 맞는 작업만 하게 됩니다.

문제는 여기서 한 번 꼬이면 영향 범위가 넓다는 겁니다. 예를 들어:

• 대시보드 Horizon(호라이즌) 로그인 실패
• CLI에서 토큰 발급 실패
• Nova나 Glance 같은 서비스 간 인증 실패
• 내부 서비스 계정 비밀번호 만료 또는 잘못된 role 할당
• 엔드포인트 URL 혼선으로 internal/public 트래픽 분리 실패

제가 실제로 써보니까, 컴퓨트 노드 한 대 죽는 것보다 Keystone 설정 하나 잘못 들어간 게 복구 피로도가 더 높을 때도 있었습니다. 왜냐하면 장애가 여러 서비스에 퍼져 보이거든요. 겉으로는 Nova 오류처럼 보여도 원인은 Keystone 토큰 검증 실패인 경우가 있었습니다.

2. Keystone 핵심 개념, 쉽게 말해 이렇게 이해하면 됩니다

처음 접하시면 용어가 좀 많습니다. 저도 처음엔 헷갈렸는데, 아래처럼 묶어서 이해하니까 훨씬 편하더라고요.

개념	영문	쉽게 말한 뜻
사용자	User	OpenStack에 로그인하거나 API를 호출하는 주체
프로젝트	Project	리소스를 묶는 작업 공간
도메인	Domain	사용자와 프로젝트를 더 큰 범위로 구분하는 단위
역할	Role	허용된 권한 세트
토큰	Token	인증 후 발급되는 일시적 접근 증표
엔드포인트	Endpoint	서비스 API가 열려 있는 주소
카탈로그	Service Catalog	사용 가능한 서비스 목록과 접속 정보

여기서 중요한 포인트가 있습니다. Keystone 보안은 단순히 비밀번호를 복잡하게 만드는 수준이 아닙니다. 토큰 수명, 키 회전(rotation), 서비스 계정 분리, TLS(전송 구간 암호화), 로그 감사(audit)까지 같이 봐야 합니다.

토큰 방식은 왜 신경 써야 할까요?

운영하면서 체감이 컸던 부분이 토큰입니다. 예전에는 UUID 토큰 이야기도 많이 나왔지만, 실제 운영에선 Fernet(퍼넷, 대칭키 기반의 서명된 토큰 포맷) 쪽이 관리 포인트를 줄이는 데 도움이 됐습니다. DB 조회 부담이 줄고, 토큰 검증 구조가 단순해지는 장점이 있거든요. 다만 그 대신 Fernet 키 관리를 제대로 해야 합니다. 키를 안 돌리면 보안상 찜찜하고, 반대로 무작정 돌리면 토큰 검증 이슈가 생길 수 있습니다.

3. 제가 1년 운영하면서 정착한 기본 구성

제 기준의 안정적인 기본 원칙은 아래였습니다.

1. 관리용 admin 접근과 일반 사용자 접근을 논리적으로 분리합니다.
2. TLS(전송 계층 보안)는 반드시 앞단 프록시나 로드밸런서에서라도 적용합니다.
3. 서비스 계정(service account)은 사람 계정과 섞지 않습니다.
4. 권한은 최소 권한(least privilege)으로 시작합니다.
5. Fernet 키 회전 주기와 시간 동기화(NTP/Chrony)를 같이 관리합니다.
6. 관리 네트워크와 외부 노출 네트워크를 분리합니다.

말은 쉬운데, 실제 운영에선 이걸 꾸준히 지키는 게 어렵습니다. 특히 테스트 환경에서 급하게 계정 하나 더 만들고, role 하나 더 붙이고, endpoint를 임시로 public에 노출해두면 나중에 꼭 빚처럼 돌아오더라고요. 삽질 좀 했습니다 ㅎㅎ

4. 실전 구현: Keystone 기본 설정과 보안 초기값

아래 예시는 배포판이나 패키지 구성에 따라 경로가 조금 다를 수 있지만, 큰 흐름은 비슷합니다. 핵심은 Fernet 초기화, 부트스트랩, 서비스 확인입니다.

4-1. Fernet 키 초기화

keystone-manage fernet_setup --keystone-user keystone --keystone-group keystone
keystone-manage credential_setup --keystone-user keystone --keystone-group keystone

이 단계는 토큰과 자격 증명 암호화의 기반이 됩니다. 여기서 파일 권한이 어긋나면 나중에 토큰 검증에서 조용히 말썽을 부리기도 합니다. 저는 한 번 소유권이 꼬여서 Apache(아파치, 웹 서버) 프로세스는 살아 있는데 Keystone 응답만 이상하게 나오는 상황을 겪었습니다.

4-2. bootstrap 실행

keystone-manage bootstrap \
  --bootstrap-password 'CHANGE_ME_STRONG_PASSWORD' \
  --bootstrap-admin-url https://keystone.example.internal:5000/v3/ \
  --bootstrap-internal-url https://keystone.example.internal:5000/v3/ \
  --bootstrap-public-url https://keystone.example.com:5000/v3/ \
  --bootstrap-region-id RegionOne

여기서 public/internal URL을 어떻게 나눌지 미리 정해두는 게 정말 중요합니다. 처음엔 대충 같은 주소 넣어도 되지 않나 싶었는데, 운영 환경이 커지면 인증 시스템 관리가 바로 복잡해집니다. 외부 접속용, 내부 서비스 통신용, 운영자 점검용을 구분해두면 나중에 정책 적용이 쉬워집니다.

public, internal, admin 성격의 접근 경로를 나누고 Fernet 키와 서비스 계정을 관리하는 설정 흐름 예시입니다.

4-3. 기본 환경 변수 설정

export OS_AUTH_URL=https://keystone.example.com:5000/v3
export OS_USERNAME=admin
export OS_PASSWORD='CHANGE_ME_STRONG_PASSWORD'
export OS_PROJECT_NAME=admin
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_DOMAIN_NAME=Default
export OS_IDENTITY_API_VERSION=3

운영 중에는 shell history(셸 기록)에 민감 정보가 남지 않도록 조심하셔야 합니다. 저는 실제로 테스트 서버에서 급하게 붙어 작업하다가 환경 변수 관리가 느슨해진 적이 있었는데요. 이후에는 별도 openrc 파일 권한 제한과 비밀값 주입 방식 통일로 정리했습니다.

4-4. 프로젝트, 사용자, 역할 생성

openstack project create --domain default --description "Service Project" service
openstack project create --domain default --description "Operations Project" ops
openstack user create --domain default --password 'STRONG_SERVICE_PASSWORD' glance
openstack role create reader
openstack role add --project service --user glance admin

여기서 흔히 하는 실수가 사람 계정과 서비스 계정을 같은 패턴으로 관리하는 겁니다. 저는 초반에 편하다고 운영자 계정 하나로 이것저것 테스트했었는데, 나중에 로그를 보면 누가 무슨 작업을 했는지 흐려집니다. 사람은 사람 계정, 서비스는 서비스 계정. 이 원칙이 감사(audit) 대응에도 좋았습니다.

4-5. 설정 파일에서 꼭 보는 항목

[token]
provider = fernet

[cache]
enabled = true

[security_compliance]
lockout_failure_attempts = 5
lockout_duration = 1800
unique_last_password_count = 5
password_expires_days = 90

배포판과 릴리스에 따라 지원 항목 차이가 있을 수 있으니, 실제 적용 전에는 사용 중인 문서를 꼭 확인하셔야 합니다. 다만 운영 원칙은 분명합니다. 토큰 방식 명확화, 캐시 전략 점검, 로그인 실패 잠금, 비밀번호 정책은 반드시 챙기셔야 합니다.

5. Keystone 보안, 실제로 효과 있었던 강화 팁

이 섹션은 정말 체감 위주입니다. 스펙 표보다 운영 안정성에 더 직접적인 것들만 추렸습니다.

5-1. TLS 적용은 선택이 아니었습니다

내부망이라 괜찮겠지 싶을 수 있는데, 실제로는 내부망이 제일 오래 방치됩니다. 프록시 계층에서라도 TLS를 적용하고, 인증서 갱신 주기를 운영 절차에 넣는 게 좋습니다. 특히 Horizon과 Keystone이 같이 얽혀 있을 때 mixed content나 redirect 문제도 정리되더라고요.

5-2. Fernet 키 회전 자동화

keystone-manage fernet_rotate

이 명령 자체는 단순합니다. 문제는 언제, 어떤 순서로, 몇 개의 키를 유지할지입니다. 제가 운영하면서 얻은 교훈은, 키 회전은 cron만 걸어두고 끝낼 일이 아니라는 점이었습니다. 여러 컨트롤러 노드가 있다면 키 동기화 순서와 배포 타이밍을 같이 관리해야 합니다.

5-3. 시간 동기화는 사소해 보여도 필수입니다

토큰이 유효한데도 간헐적으로 인증이 튀는 경우가 있었습니다. 처음엔 Keystone 자체 문제인 줄 알았는데, 알고 보니 노드 간 시간이 조금씩 어긋나 있었어요. 이거 진짜 흔합니다. chrony(크로니, 시간 동기화 도구)나 NTP 상태를 같이 점검하세요.

5-4. 서비스 카탈로그와 엔드포인트 정리

OpenStack 보안을 이야기할 때 의외로 자주 놓치는 게 endpoint 정리입니다. 안 쓰는 public endpoint를 남겨두면 관리 부담이 생기고, 내부 서비스가 public URL을 타기 시작하면 네트워크 정책도 꼬입니다.

openstack endpoint list
openstack service list

분기마다 한 번씩이라도 정리해보세요. 저는 운영 6개월 차쯤부터 정기 점검 항목으로 넣었습니다.

5-5. Application Credential 적극 활용

자동화 스크립트나 CI에서 사람 계정 비밀번호를 직접 쓰는 건 피하시는 게 좋습니다. 가능하면 Application Credential(애플리케이션 자격 증명) 같은 방식을 고려해 분리하세요. 스크립트 유출 범위를 줄이는 데 도움이 됩니다.

6. ⚠️ 운영 중 실제로 겪었던 문제와 해결 방법

여기서부터는 OpenStack Keystone 운영 후기다운 내용입니다. 책에는 짧게 나오는데, 현장에서는 꽤 귀찮은 문제들입니다.

6-1. 토큰이 가끔만 실패하는 문제

증상: 어떤 요청은 되고, 어떤 요청은 401이 나옵니다.

원인: 시간 동기화 불일치, 캐시 반영 지연, 다중 노드 환경에서 키 동기화 문제.

해결:

1. 컨트롤러 노드 시간 차이 확인
2. Fernet 키 디렉터리 소유권과 동기화 상태 확인
3. 웹 서버 재로드 전후 캐시 반영 점검

처음엔 네트워크 문제로 의심했는데, 결국 시계가 문제였던 적이 있었습니다. 정말 허탈하더라고요.

6-2. Horizon 로그인은 되는데 일부 메뉴가 비정상인 문제

증상: 로그인은 되는데 프로젝트 리소스가 안 보이거나 API 호출이 실패합니다.

원인: role 할당 누락, project scope 설정 문제, endpoint 카탈로그 불일치.

해결:

openstack token issue
openstack role assignment list --user admin --names
openstack catalog list

이 세 개를 같이 보면 방향이 잡히는 경우가 많았습니다. 특히 토큰 발급은 되는데 scope가 예상과 다르면, 사용자 입장에서는 그냥 고장처럼 보이거든요.

6-3. 서비스 계정 비밀번호 변경 후 연쇄 장애

Glance, Nova, Neutron 같은 서비스 설정 파일에 들어간 자격 증명을 한쪽만 바꾸면 바로 연쇄적으로 인증 실패가 납니다. 이건 진짜 조심하셔야 합니다. 제가 한 번 maintenance window(점검 시간) 없이 낮에 바꿨다가 로그 쫓아다니느라 고생했습니다.

팁: 비밀번호 변경은 다음 순서를 추천합니다.

1. Keystone에서 사용자 비밀번호 변경
2. 각 서비스 설정 파일 동시 반영
3. 서비스 재시작 또는 재로드
4. 토큰 발급과 서비스 API 호출 검증

7. 검증: 운영 상태는 이렇게 확인했습니다

설정을 바꿨으면 반드시 검증해야 합니다. 저는 아래 체크리스트를 반복적으로 썼습니다.

1. 관리자 토큰 발급이 되는지 확인
2. 일반 사용자 계정도 동일하게 인증되는지 확인
3. 서비스 계정으로 API 인증이 되는지 확인
4. public/internal endpoint가 의도대로 동작하는지 확인
5. 로그에 경고나 반복 실패가 없는지 확인

openstack token issue
openstack endpoint list
openstack catalog list
openstack user list
journalctl -u apache2 -n 100 --no-pager

배포판에 따라 웹 서버 서비스명이 `httpd`일 수도 있습니다. 중요한 건 CLI 성공 여부와 서버 로그를 같이 보는 겁니다. 둘 중 하나만 보면 놓치는 게 생깁니다.

토큰 발급, 서비스 카탈로그, 엔드포인트 점검 결과를 한눈에 확인하는 운영 검증 예시입니다.

1년 정도 운영하고 나니 확실히 느낀 점이 있습니다. Keystone은 화려한 서비스는 아니지만, 안정적으로 굴러가면 전체 OpenStack이 훨씬 단정해집니다. 반대로 인증 시스템 관리가 흐트러지면 장애 분석 시간도 길어지고, 보안 리스크도 조용히 쌓입니다.

8. Fernet, 계정 관리, 엔드포인트 운영 기준 정리

항목	권장 운영 방식	이유
토큰	Fernet 사용, 키 회전 자동화	검증 구조 단순화와 보안성 확보
계정	사람/서비스 계정 분리	감사 추적과 사고 범위 축소
권한	최소 권한 부여	오남용 방지
엔드포인트	public/internal 역할 분리	네트워크 정책 단순화
시간	모든 노드 동기화	토큰 오류 예방
전송 보안	TLS 적용	자격 증명 노출 방지

9. 마무리: Keystone은 결국 운영 습관 싸움입니다

정리해보면, OpenStack Keystone 운영 후기에서 가장 크게 남은 건 기술보다 습관이었습니다. 처음엔 설정만 맞으면 끝이라고 생각했는데, 실제로는 키 회전, 시간 동기화, 계정 분리, 엔드포인트 정리, 로그 확인을 꾸준히 반복해야 하더라고요. 드디어 됐다 싶어도 몇 달 지나면 또 운영 기준이 흐트러집니다. 그래서 체크리스트와 주기 작업이 중요합니다.

혹시 지금 Keystone을 막 구축하셨거나, 이미 돌아가는 환경인데 어딘가 불안하신가요? 그럴 땐 거창한 개편보다 아래 5가지만 먼저 점검해보세요.

• Fernet 키 회전이 되고 있는가
• 시간 동기화가 정확한가
• 서비스 계정과 사람 계정이 분리되어 있는가
• 안 쓰는 public endpoint가 남아 있지 않은가
• 토큰 발급 검증을 정기적으로 하고 있는가

이 다섯 가지만 잡아도 체감이 꽤 큽니다. 다음 글에서는 Horizon과 Keystone 연동 시 세션/쿠키 문제, 또는 OpenStack 보안 관점에서 서비스 계정 순환(rotation) 자동화를 다뤄볼 예정입니다. 이전 글에서 다룬 네트워크 분리와 reverse proxy 구성이 있다면 같이 참고하시면 흐름이 더 잘 잡히실 겁니다.

Fernet 키 회전, 최소 권한, TLS, 시간 동기화, 엔드포인트 정리를 요약한 운영 체크리스트입니다.

자주 묻는 질문

Keystone만 안정적이면 나머지 OpenStack 서비스도 괜찮을까요?

완전히 그렇진 않지만, 최소한 인증 관련 장애 분석 범위를 크게 줄일 수 있습니다. 운영 체감상 출발점이 훨씬 깔끔해집니다.

OpenStack 보안에서 가장 먼저 손댈 부분은 뭔가요?

제가 직접 해보니 TLS, 계정 분리, Fernet 키 회전, 시간 동기화 이 네 가지가 우선순위가 높았습니다.

인증 시스템 관리는 얼마나 자주 점검하면 좋을까요?

주간 점검으로 토큰 발급과 로그 확인, 월간 점검으로 endpoint/role/서비스 계정 상태를 보는 식이 현실적이었습니다.

📚 함께 읽으면 좋은 글

• OpenStack Ironic으로 베어메탈 서버 자동 프로비저닝 실전 사례
• OpenStack Swift vs Ceph 선택 기준 심층 비교
• 오픈스택 플레이버 최적화로 유휴 자원 줄이기