Keystone

Keystone 기초 개념

• keystone 자체에는 openstack 전체와 관련하여 특정 모델 및 구현에 특화된 여러 개념이 있음
• 이런 개념은 ID 및 권한 부여와 관련있지만, keystone이 권한 부여, 접근 관리 및 검색을 구현하는 방식에 중점을 둠

프로젝트란?

• keystone에서 프로젝트는 다른 openstack 서비스가 서버, 이미지 등과 같은 리소스를 그룹화하고 격리하는 데 사용하는 추상화
• openstack 초기에는 keystone 프로젝트를 원래 테넌트라고 불렀지만, 요즘에는 프로젝트라고 부름
• keystone은 누가 해당 프로젝트에 접근 권한이 있는지 명확히 하는 것임
• 프로젝트 자체는 사용자를 소유하지 않지만, 사용자 또는 사용자 그룹은 'Role assigments' 개념을 사용해 프로젝트에 대한 접근 권한을 부여 받음
• 사용자 또는 사용자 그룹에 프로젝트에 역할이 할당되면, 해당 사용자 또는 사용자 그룹이 프로젝트 내의 리소스에 어떤 종류의 접근 권한을 가지는지 나타냄
• 즉, 권한 부여 (grant)라고도 함

도메인이란?

• 오픈스택 초기에는 프로젝트의 가시성을 다른 사용자 조직으로 제한하는 메커니즘이 없었음 
• 즉, 다른 조직 간에 프로제긑 이름 충돌이 의도치 않게 발생할 수 있었음 
  • 프로젝트 가시성: 프로젝트를 누가 볼 수 있는가를 정하는 권한이나 범위
• 사용자 이름 또한 전역 가시성을 가졌으며, 두 개의 다른 조직이 동일한 사용자 이름을 사용하는 경우 원치 않는 사용자 이름 충돌이 발생할 수 있었음
• Keystone은 프로젝트 및 사용자(그룹) 집합의 가시성을 특정 조직으로 격리할 수 있는 Domain 이라는 새로운 추상화를 추가했음
• Domain은 사용자, 그룹 및 프로젝트의 컬렉션으로 공식적으로 정의됨
• 도메인을 통해 클라우드 리소스를 특정 조직이 사용할 수 있는 사일로(silos)로 나눌 수 있으며,
• 기업 내의 다른 부분 간의 논리적 분할 역할을 하거나 완전히 분리된 기업을 나타낼 수 있음 
  • 사일로: 서로 분리되어 정보나 자원을 공유하지 않는 상태

사용자 및 사용자 그룹

• keystone 영역에서 사용자와 사용자 그룹은 도메인과 프로젝트로 격리된 리소스에 접근 권한이 부여되는 엔티티임
• 그룹은 사용자의 컬렉션이며, 사용자는 클라우드를 실제로 사용할 개인
• 역할을 할당할 때 역할이 '할당되는' 엔티티이므로 사용자 및 그룹을 엑터라고 부름
• 그래픽 표현
  • 사용자, 그룹, 프로젝트는 항상 도메인 범위(domain scoped)임
  • 즉, 사용자, 그룹, 프로젝트의 이름은 도메인 간에 공통될 수 있음 (그러나 각 엔티티는 전역적으로 고유한 식별자(UUID)를 가짐이 보장됨
  • 이는 ID만으로 리소스를 찾는 것이 가능함을 의미함 (이름만으로는 고유성 보장이 안됨)

역할 (Roles)

• 역할은 keystone에서 권한 부여 개념을 전달하는데 사용됨
• actor는 대상에 대해 여러 역할을 가질 수 있음
  • ex) admin 역할은 bob 사용자에게 dev 프로젝트에 대해 할당됨

할당 (Assignment)

• 역할 할당은 액터, 대상 및 역할의 조합인 삼중항(tirple or tenrnary)임
  •  역할을 부여할 때 "누가(액터), 무엇에(대상), 어떤 역할을" 부여받는지를 항상 세 가지 요소로 묶어서 표현한다는 뜻입
• 역할 할당은 부여되거나 취소될 수 있으며, 그룹과 사용자, 도메인과 프로젝트 간에 상속될 수 있음
• keystone은 사용자 및 그룹이 프로젝트 및 도메인에 역할을 할당받을 수 있는 할당 저장소를 제공함

대상 (Targets)

• 사용자 (사용자 그룹)은 특정 프로젝트 또는 도메인에 대한 특정 역할 값을 할당받아 해당 프로젝트 또는 도메인에 대한 접근 권한을 부여 받음
• 프로젝트와 도메인이 이러한 유사한 특성을 가지므로, 이 두 엔티티를 총칭하여 target라고 부름

토큰

• 사용자가 오픈스택 API를 호출할려면 사용자가 누구인지 증명하고, API를 호출할 권한이 있음을 증명해야함
• 이를 달성하는 방법은 API 호출에 오픈스택이 토큰을 전달하는 것이며, keystone은 이러한 토큰을 생성하는 역할을 함
• 사용자는 keystone에 대한 성공적인 인증 후에 이 토큰을 받음
• 토큰은 권한 부여 정보도 함께 포함되며, 사용자가 클라우드에서 가지고 있는 권한을 나타냄
• 토큰으 ID와 페이로드를 모두 가지고 있음 (ID는 클라우드별로 고유함)
  • 페이로드에는 사용자에 대한 데이터가 포함됨
  • 토큰 페이로드에는 토큰이 언제 생성되었는지(issued_at), 언제 만료되는지(expires_at), 어떤 사용자가 인증되었는지,
  • 어떤 프로젝트에 토큰이 유효한지, 서비스 카탈로그 정보가 포함됨
• keystone은 현재 bearer token 형식의 토큰을 사용함
  • 토큰을 소유한 사람(정상이든, 비정상이든)이 토큰을 사용하여 리소스에 인증하고 접근할 수 있음을 의미함
• 따라서 keystone을 사용할때는 토큰과 그 내용을 보호하는 것이 매우 중요함

카탈로그

• 다양한 클라우드 서비스의 URL 및 엔드포인트를 포함함
• 카탈로그가 없으면 사용자나 애플리케이션은 VM을 생성하거나 객체를 저장하기 위한 요청을 어디로 라우팅해야하는지 알 수 없음
• 서비스 카탈로그는 엔드포인트 목록으로 구성되며, 각 엔드포인트는 admin URL, internal URL, public URL로 나누어짐 (이 세 URL은 동일할 수 있음)

Idnetity (ID 관리)

• keystone의 ID 서비스는 actors를 제공함
• 클라우드 내의 ID는 SQL, LDAP, 연합 ID 공급자(Federated Idnetity Providers)등 다양한 위치에서 올 수 있음
  • SQL: 가장 기본적인 ID 저장소
    • Keystone 자체 데이터베이스(SQL—MySQL, PostgreSQL 등에 저장됨)에 사용자 정보를 직접 저장
    • OpenStack 운영자가 쉽게 계정을 만들고 관리하기 좋음
  • LDAP: 많은 기업이 기존에 사용하는 디렉토리 서비스(예: Microsoft AD, OpenLDAP)와 연동해서 인증을 할 수 있음
    • 즉, 기존 사내 계정 시스템을 그대로 활용해 OpenStack을 쓸 수 있게 해줌
  • 연합 ID 공급자(Federated Identity Provider): SAML, OpenID Connect 등 표준 프로토콜을 지원하는 외부 인증 시스템(예: 구글, 회사 내부 SSO, 다른 OpenStack 클라우드 등)과 연동할 수 있음
    • 이렇게 하면, Keystone은 외부 인증 결과만 신뢰하고, 실제 사용자 정보는 타 시스템이 관리함

SQL (Database)

• keystone은 사용자와 그룹을 sql에 저장하는 옵션을 포함하고 있으며,
• MySQL, PostgreSQL, DB2와 같은 DB를 지원함
• 데이터베이스 설정은 keystone의 설정 파일에 명시해야 함
• 이 경우 keystone이 ID 공급자 역할을 하게 되는데, 이런 방법은 기업 고객에게는 최선의 방법이 아님
  • 즉, keystone이 ID 공급자 역할을 하는 것은 바람직하지 않음
  • 비밀번호 순환 및 복구 기능이 없음
  • 대부분의 기업은 이미 사용할 LDAP 서버를 가지고 있음
  • 소규모 사용자 그룹에게 적합함

LDAP

• keystone은 사용자와 그룹을 LDAP에서 가져오고 저장하는 옵션을 가지고 있음
• keystone은 LDAP를 다른 애플리케이션(시스템 로그인, 이메일, 웹 애플리케이션 등..)과 동일하게 접근함
• LDAP 연결 설정은 keystone의 설정 파일에 명시되며, keystone이 LDAP에 쓰기 작업을 할 수 있는지 또는 단순히 읽기만 할 수 있는지 여부도 포함됨
• 이상적으로는 LDAP는 사용자 및 그룹 조회(검색을 통해..) 및 인증 (바인드를 통해..)과 같은 읽기 작업만 수행해야함
• LDAP를 읽기 전용 ID 백엔드로 사용하는 경우, keystone은 LDAP를 사용하기 위해 최소한의 권한만 필요함
• ex) keystone.conf에 정의된 사용자 및 그룹 속성에 대한 읽기 접근 권한, 비특권 계정, 비밀번호 해시에 대한 접근 권한은 필요하지 않음
  • 읽기 전용 LDAP 백엔드란?
    Keystone에서 사용자의 인증 정보(아이디, 그룹, 상태 등)를 직접 생성·수정·삭제하지 않고, 이미 LDAP에 저장되어 있는 정보를 읽어서 인증만 한다는 의미임
  • 최소한의 권한만 필요
    • Keystone이 LDAP으로부터 사용자 및 그룹 정보를 읽으려면,
    • keystone.conf에 정의된 사용자 및 그룹 속성(예: 이름, 이메일, 속성 등) 에 대한 읽기 권한만 있으면 충분함
    • 즉, 특별하거나 관리자 권한이 필요하지 않고, 매우 제한적이고 안전한(비특권) 계정으로 LDAP에 접근해도 된다는 의미임
  • 비밀번호 해시 접근 권한은 필요하지 않음
    • 인증 처리는 보통 Keystone이 LDAP에 “바인드”하여 직접 비밀번호를 확인하기 때문에,
    • 사용자의 비밀번호 해시 자체를 읽거나 저장할 필요가 없음
• 장점
  • 사용자 계정 사본을 유지할 필요가 없음
  • keystone이 ID 공급자 역할을 하지 않음
  • 비즈니스에 이미 LDAP가 구축되어 있는 경우에 사용됨
  • 필요한 서비스 계정을 LDAP에 생성할 수 있는 경우에만 단일 LDAP 사용이 권장됨
• 단점
  • 서비스 계정은 여전히 어딘가에 저장되야함
  • keystone은 인증 요청에 비밀번호가 포함되어 있으므로 여전히 사용자 비밀번호를 바라봄
  • 이상적으로는 바라보지 않는 것이 좋음

Multiple Backends

• keystone은 여러 ID 백엔드를 지원함
• 즉, 배포 환경에서 keystone 도메인당 하나의 ID 소스(백엔드)를 가질 수 있음을 의미함
• default domain은 일반적으로 SQL 백엔드이며 서비스 계정(다른 OpenStack 서비스가 Keystone과 상호 작용하는 데 사용하는 계정)을 호스팅하는데 사용함
• 여러 ID 백엔드를 지원하는 이유
  • 기업 환경에서 LDAP 관리자가 openstack 배포 팀과 동일한 조직이 아닐 수 있기 때문임
  • 즉, LDAP관리자외에 다른 조직에서 서비스 계정을 생성하는 것이 매우 어렵게 됨
• ID 백엔드와 도메인 간의 논리적 분할의 이점
  • 여러 LDAP를 사용할 수 있음
  • ex) 회사 합병시 다른 부서가 다른 LDAP를 사용하는 경우에도 동일한 기업을 표현할 수 있음
• 장점
  • 다양한 사용자 계정을 위한 여러 LDAP와 서비스 계정을 위한 SQL 백엔드를 동시에 지원할 수 있음
  • 기존 ID LDAP를 활용하면서도 영향을 주지 않음
  • 대부분의 기업에 선호되는 접근 방식

 

ID 공급자 (Identity Providers)

• ID 공급자(IdP): 사용자의 신원을 증명하고 인증을 수행하는 외부 서비스
  • 이는 기업의 LDAP이나 Active Directory(AD)일 수도 있고, Google, Facebook 같은 소셜 로그인 서비스일 수도 있음
• 연합 인증(Federated Authentication): 여러 서비스(예: OpenStack과 Google)가 사용자의 인증 정보를 공유하여, 사용자가 한 번의 로그인(싱글 사인온, SSO)으로 여러 서비스에 접근할 수 있게 하는 기술

작동 방식

1. 인증 오프로드: Keystone은 사용자의 비밀번호를 직접 저장하거나 처리하지 않음
2. 외부 위임: 대신, 사용자가 로그인하면 Keystone은 인증 요청을 외부의 신뢰할 수 있는 ID 공급자에게 넘김
3. 정보 전달: ID 공급자는 사용자를 인증한 후, SAML(Security Assertion Markup Language) 또는 OpenID Connect와 같은 표준 프로토콜을 통해 사용자의 속성(예: 그룹 정보)을 Keystone에 전달함
4. 일시적 사용자: Keystone은 이 정보를 바탕으로 사용자를 Keystone 내부에 저장하지 않고 "일시적(ephemeral)"으로 처리하며, 그룹 기반 역할 할당을 통해 권한을 부여함

주요 장점

• 기존 인프라 활용: 기업의 기존 ID 관리 시스템(LDAP, AD 등)을 그대로 활용하여 사용자 인증을 처리할 수 있음
• 보안성 강화: Keystone이 사용자의 비밀번호를 전혀 보지 않기 때문에 보안성이 높아짐
• 새로운 기능 확장: 싱글 사인온(SSO)과 같은 연합 ID 기능을 통해 사용자 편의성을 높이고, 하이브리드 클라우드와 같은 새로운 환경으로 확장할 수 있음

주요 단점

• 복잡한 설정: 여러 ID 소스를 연동하는 방식 중 설정이 가장 복잡함
• 비브라우저 인증 문제: 대부분의 소셜 로그인 서비스는 "Resource Owner Password Credential" 방식을 비활성화하여, API 호출과 같은 비브라우저 기반 인증이 어려울 수 있음

ID 백엔드 사용 사례 (Use cases for Identity Backends)

• 각 ID 소스의 일반적인 사용 사례를 알아보자
  • SQL: openstack을 테스트하거나 개발할 때, 소규모 사용자 그룹, openstack 서비스 계정용
  • LDAP: 비즈니스에 이미 LDAP가 구축되어 있는 경우, 필요한 서비스 계정을 LDAP에 생성할 수 있는 경우에만 단일 LDAP 사용 권장
  • 다중(multiple) 백엔드: 대부분의 기업에 선호되는 접근 방식, 서비스 사용자가 LDAP에 허용되지 않는 경우
  • ID 공급자: 새로운 연합 ID 메커니즘을 활용하고자 할때, 이미 ID 공급자가 존재하는 경우, keystone이 LDAP에 접근할 수 없거나 LDAP가 아닌 다른 ID 소스를 사용할 때 

---

Authentication(인증)

• keystone 서비스에 인증하는 방법은 다양하지만, 가장 일반적인 두 가지 방법은 비밀번호를 제공하거나 토큰을 사용하는 것임

password

• 요청 페이로드에는 사용자의 존재 위치를 찾고(사용자 인증), 선택적으로 사용자의 권한에 기반한 서비스 카탈로그를 검색하기 위한 충분한 정보가 포함되야 함
• 다중 도메인 배포 환경에서는 동일한 이름을 가진 여러 사용자가 존재할 수 있으므로, 들어오는 사용자를 식별하는 user 섹션에는 도메인 정보(도메인 이름 또는 ID)가 포함되어야 함
  • 전역적으로 고유한 사용자 ID를 사용하는 경우에는 도메인 정보가 필요하지 않음
• scope 섹션은 선택 사항이지만 자주 사용됨
  • 범위가 없으면 사용자는 서비스 카탈로그를 검색할 수 없음
  • scope는 사용자가 작업하고자 하는 프로젝트를 나타내는 데 사용됨
  • 사용자가 해당 프로젝트에 대한 역할이 없으면 요청은 거부됨

token

• 사용자는 현재 토큰을 제공하여 새로운 토큰을 요청할 수도 있음
• 토큰을 사용하여 다른 토큰을 검색하는 이유는 다양함
  • 만료될 토큰을 새로 고치거나(refresh),
  • 범위가 지정되지 않은 토큰을 범위가 지정된(scoped) 토큰으로 변경하는 경우가 있음
• 비밀번호보다는 요청이 훨씬 간결함

Access Management and Authorization

• keystone이 오픈스택에 필수적인 핵심 이유
  •  사용자가 어떤 API를 사용할 수 있는지 접근을 관리하고 권한을 부여하는 기능이기 때문
  • Keystone은 각 퍼블릭 API 엔드포인트에 적용되는 역할 기반 접근 제어(RBAC) 정책을 생성하는 접근 방식을 사용함
  • 이러한 정책은 일반적으로 policy.json이라는 파일에 저장됨
• policy.json은 타킷과 규칙으로 구성됨
  • targets: 파일 상단에서 adminm owner 등과 같은 다른 target 평가에 사용될 target이 설정됨
  • rules: identity:로 시작하고 보호된 컨트롤러를 지정하는 각 규칙은 API를 관리함
    • 이미 설정된 타겟을 사용하여 이러한 새로운 타겟을 보호함

 

---

Keystone 기초 명령어

• 환경 변수 설정

source ~/admin-openrc.sh
cat ~/admin-openrc.sh

 

• 토큰 가져오기

source ~/admin-openrc.sh
openstack token issue

 

• cURL을 사용할려면 사용자 및 프로젝트에 대한 정보를 포함하는 인증 요청 페이로드를 post 요청으로 전송해야 함
• 토큰 값은 응답 헤더의 X-Subject-Token에 설정됨

 

• 사용자 목록 보기

openstack user list

cURL을 사용하려면 토큰을 사용하여 /v3/users API 엔드포인트에 액세스해야함

 

• 프로젝트 목록 보기

openstack project list

 

 

• 역할 목록 보기

openstack role list

 

 

새 도메인 생성

openstack domain create testDomain

 

• 도메인 내 프로젝트 생성

openstack project create --domain default --description "Default Cookbook Tenant" cookbook

•  openstack project create <프로젝트 이름> --domain <도메인 이름> --description "<설명>"
• 우리는 이미 cookbook 프로젝트는 있으니깐 넘어가자

 

• 도메인 내 사용자 생성

openstack user create --domain default --project cookbook --password 'openstack' --email demo@localhost demo

• 새 도메인 내에 사용자를 생성하려면 openstack user create <사용자 이름> --email <이메일> --domain <도메인 이름> --description "<설명> --password <비밀번호>" 명령으로 도메인을 지정

 

프로젝트에 사용자 역할 할당

openstack role add --user demo --project cookbook member

 

새 사용자로 인증

• 새 사용자로 인증할려면 새 터미널 세션을 시작하고, 사용자 이름, 비밀번호, 프로젝트, 도메인 정보 등 새로운 환경 변수를 설정해야 함
• 이후 오픈스택 token issue 명령어를 통해 토큰을 검색하여 성공적인 인증을 확인함
• cURL로는 업데이트된 값을 포함하는 인증 요청 페이로드를 post 요청으로 전송함