OpenStack KeyStone

1). 사전 지식

오픈 스택에서 제공하는 여러가지 서비스(Nova, Cinder, Switf 등)은 모두 독립적인 서비스를 제공하고 있습니다.

 

- 각 서비스를 이용하려면 인증/인가 과정을 다시 확인하게 됩니다.

---

2). 인증 과정

[현실 세계에서의 예시]

[전제 조건] : 홍길동은 음식점에서 항상 음주를 하기 때문에 신분증 검사를 합니다.

[음식점 A, 음식점 B, 음식점 C] : OpenStack 각각 독립적인 서비스(Cinder, Glance 등)
[신분증] : 인증 토큰
[현재 환경의 특징] : 음식점 C의 주류는 음식점 B에서 제공받고 있습니다.

 

1). 홍길동이 음식점 A에 방문하여 신분증 검사를 하였습니다.

2). 홍길동이 음식점 B에 방문하여 신분증 검사를 하였습니다.

3). 홍길동이 음식점 C에 방문하여 신분증 검사를 하였습니다.

4). 음식점 B는 주류를 제공할 때 올바른 고객에게 가는 지 확인하기 위해서 홍길동의 신분증을 다시 검사합니다.

5). 음식점 C는 홍길동의 신분증을 통해 검사를 통과하여 주류를 받았습니다.

[오픈 스택 서비스간 통신]

사용자가 Horizon으로 인스턴스 생성 요청을 하는 상황(사용자가 인증으로 얻은 Token으로 horizon의 요청)

1. 사용자에게 받은 ‘X-Auth-Token’을 Keystone을 통해 검증합니다.
2. Horizon에서는 Nova에게 VM 생성 요청 통신을 위해 Keystone에서 토큰 발급을 진행합니다.
3. 발급된 토큰으로 Horizon이 Nova에게 요청을 진행합니다.
4. Nova에서는 Horizon에게 받은 토큰을 KeyStone을 통해 검증합니다.
5. Nova는 VM을 생성하기 위해서 Image을 가져오기 위해 Glance에게 요청을 위한 Token을 Keystone에게 발급받습니다.
6. 발급받은 Token으로 Nova는 Glance에게 이미지 조회를 요청합니다.
7. ….

위에 설명처럼 오픈 스택은 독립적인 각 서비스가 인증을 하기 위해서 KeyStone과 통신을 하고 있습니다.

 

즉, Keystone에서 OpenStack User 인증/인가 및 역할 정보를 관리하고 있습니다.

---

---

2. Keystone

1). 용어

Keystone에서는 사용자 정보에 대한 핵심 용어로는 Domain, Project, Role, User, Group, EndPoint 이 있습니다.

 

용어	설명
Domain	OpenStack에서 사용자, 프로젝트, 리소스를 관리하는 최상위 관리 단위 - AWS Root 계정 유사 - 각 Domain은 독립적인 관계
Project	OpenStack에서 리소스를 격리하고 관리하는 단위 - AWS VPC 유사 - 각 서비스(Nova, Cinder 등)의 리소스를 관리하는 경계 역할
User	OpenStack에서 리소스를 관리하고 액세스하는 개별 사용자 - AWS IAM 유사 - 여러 Project에 속할 수 있으며, 각 Project에서 다른 Role을 가질 수 있다.
UserGroup	여러 User를 묶어 관리할 수 있는 개념으로, 사용자 집합을 관리하는 단위 - AWS IAM 사용자 그룹 유사 - Domain 내에서 관리 - Role은 그 그룹에 속한 모든 User에게 적용
Role	Domain 또는 Project 내에서 수행할 수 있는 작업의 범위 - ADMIN(관리자 역할), MEMBER(일반 사용자 역할)..
Endpoint	서비스를 이용을 위한 연결정보를 제공 - 접근 가능한 네트워크 주소, URL(IP, PortNumber, version) 사용

 

2). 역할 기반 액세스 제어

 

역할 기반 액세스 제어 (RBAC, Role Based Access Control) 제공

'역할'을 할당하여 사용자 권한을 역할에 맞게 부여하여 이를 수행하도록 합니다.

OpenStack에서 각 서비스가 독립적이기 때문에 역할에 대한 정책도 서비스가 직접 관리하게 됩니다.

→ 각 서비스는 policy.json 파일을 통해서 역할과 정책을 매핑하여 사용자가 해당 서비스에 정책적으로 허용 여부를 결정하게 됩니다.

 

[Nova 예제 Policy.json]

 

(Role : member, man, woman)

{
  "compute:create": "role:woman",
  "compute:delete": "role:woman",
  "compute:start": "role:man",
  "compute:stop": "role:man",
  "compute:reboot": "role:man",
  "compute:show": "role:member",
  "compute:list": "role:member"
  ...
}

 

역할	정책
woman	compute create/delete
man	compute start/stop/reboot
member	compute show/list

 

현실 세계에서의 예시를 다시 살펴보면

[음식점 A, 음식점 B, 음식점 C] : OpenStack 각각 독립적인 서비스(Cinder, Glance 등)

[홍길동 역할 : 성인_23살] : OpenStack 역할

[22세 이상, 20세 이상, 25세 이상] : 역할에 대한 정책

 

홍길동 → 음식점 A : 신분증 인증 후 주류 정책(22세 이상)까지 통과!

홍길동 → 음식점 B : 신분증 인증 후 주류 정책(20세 이상)까지 통과!

홍길동 → 음식점 C : 신분증 인증 후 주류 정책(25세 이상) 통과 실패, 주류 섭취 불가!

 

3). 각 서비스 정책 정의

 

아래 그림은 각 서비스마다 Policy.json 파일을 통해서 역할에 대한 정책을 정의하는 것을 표현한 그림입니다.

---

[부록]

Keystone API 명세서

Identity API v3 (CURRENT) — keystone documentation