[Kerberos]01.개요 (용어 및 프로토콜 동작 방식)

Kerberos Overview 

개요

얘도 개요

커버로스(Kerberos)는 우리가 흔히 알고 있는 그리스 로마신화에 나오는 머리 셋 달린 댕댕이이다. 흔히들 케르베로스라고 부르는 그것. 하지만 IT용어에서 커버로스는 프로토콜을 뜻하는 말로, 사용자와 서비스에 대해서 인증과 보안을 제공하기 위한 강한 보안 솔루션이다 (참조:https://ko.wikipedia.org/wiki/커버로스)

사용자가 특정한 서비스에 접근하거나, 서비스가 다른 서비스에 접근 할 때 인증과 권한에 대한 정보를 관리하고 프로세스에 필요한 여러 기능(ticket 발생, 비밀키-대칭키를 통한 보안)들을 제공해 준다. 개인적으로 사용성이 그렇게 좋다고 생각하지 않는데 업계의 표준과도 같이 적용되는 것을 보자면 이는 강한 보안성에서부터 비롯되는게 아닌가 싶다.  

필요에 의해 오랜 기간동안 반복해서 찾아 보았는데도 머리속에 잘 남지 않아, 다시 한번 정리해야겠다는 필요성을 느껴 정리한다. 이해하기 쉽게 개념/논리적인 의역이 존재할 수도 있기 때문에 여러 전문가 분들께서 잘못된 부분이나 이해가 잘 되지 않는 부분을 가차없이 알려주시기 바란다.  

용어정리 

용어	설명
Authentication Server (AS)	principal에 대한 초기 인증 작업을 수행하고, TGT(Ticket Granting Ticket, 서비스 티켓을 발급받기 위한 티켓)을 발급한다.
Ticket Granting Server (TGS)	TGT를 바탕으로 Service Ticket을 발급한다.
Service Server(SS)	실제로 서비스를 제공하는 서버
principal	각 서비스/사용자를 정의하고 있는 unique한 이름. 서비스/사용자 별로 principal을 정의해야 특정 서비스에 대한 인증/권한을 제어할 수 있다.
Key Distribution Center (KDC)	커버로스 환경에서 인증을 위해 principal에 대한 데이터를 저장하고 있는 서비스 AS+TGS를 구현한 서비스
KDC Server	KDC를 서비스 하는 서버
Kerberos Client	KDC Server에게 인증을 요청하는 Client
Realm	커버로스 서비스를 하기 위한 네트워크 단위(Server-Client들의 집합, Domain 이름으로 구분)
KeyTab	principal들에 대한 정보와 그것들에 대한 키 값이 저장되어 있는 파일. 사용자는 ID/PW를 직접 입력할 수 있지만 서비스가 다른 서비스에 접근할 때에는 이러한 작업을 수행할 수 없다. 따라서 KeyTab 파일을 통해서 미리 이러한 정보를 정의해 놓는다.

Kerberos Protocol 동작방식 

<1> 사용자 로그인 

(1) 사용자는 특정 서비스에 접근하기 위해서 서비스의 클라이언트를 통해 접근한다. 이때 사용자는 자신의 사용자 ID/PW를 입력한다. 이 사용자(혹은 Kerberos Client)의 궁극적인 목표는 서비스를 사용하는 것이다. 그리고 그것을 위해 Kerberos Protocol에서는 서비스를 제공해주는 서버로부터 인가 받기 위한 [Service Session Key] 그리고 [Ticket]을 구해야 한다.

그리고 그 여정의 시작은 AS(Authentication) Server로부터 (1)자신을 알리고 (2)티켓을 발급 받기 위한 티켓(TGT=교환권) 을 전달 받는 것이다. 

 

<2> TGS세션키 요청

  클라이언트는 서비스를 사용하기 위해서 TGS(Ticket Granting Service)로부터 서비스에 대한 세션키(SS)와 Ticket(클라이언트 정보)을 발급받아야 한다. 그리고 그러기 위해서는 이때, (1)오직 사용자ID만을 전달하는데 그 이유는 자신의 PW가 탈취될 수도 있기 때문이다. 그리고 당연히도 ID와 PW가 모두 탈취된다면 권한이 없는 사람이 서비스를 사용할 수 있을 것이다. 

<3> 사용자 정보 확인  

 클라이언트로부터 사용자ID를 전달 받으면 AS는 자신의 DB에서 해당 사용자가 있는지 확인을 한다. 만약 해당 사용자의 정보가 DB에 존재한다면 저장된 사용자PW의 비밀키를 사용하여 TGS세션키를 암호화 한다. (AS가 이미 비밀키를 가지고 있게 된다. 이에 대한 구현 방법은 일단 무시하고 가지고 있다라고 하자) 

 AS 입장에서 사용자ID만을 전달 받았기 때문에 해당 클라이언트가 정말 그 사용자인지 확인할 방법은 없다. 따라서 AS는 클라이언트를 한번 떠본다. 마치 '네가 정말 HERRING이 맞아? 그러면 내가 알고 있는 HERRING의 비밀번호를 사용한 비밀키로 임시로 사용할 수 있는 TGS세션키를 암호화해서 줄테니까 써봐. 그리고 TGS비밀키로 네 정보를 암호화한 TGT도 줄테니 TGS에게 가서 확인받아' 라고 하듯 말이다. 

<4> 사용자PW비밀키로 암호화한 TGS세션키, TGT 전달 

따라서 AS는 아래와 같이 클라이언트에게 응답한다. 

   (1) 사용자PW 비밀키로 암호화한 ~~~ TGS세션키 
   (2) 티켓을 발급 받기 위한 티켓(TGT) = TGS비밀키로 암호화한 ~~~ 클라이언트 정보 

<5> TGS세션키 획득, Authenticator 생성 

 클라이언트는 AS로 부터 사용자PW비밀키로 암호화한 TGS세션키를 받았기 때문에, 본인이 올바른PW를 가지고 있다면 TGS세션키를 복호화해서 얻을 수 있다. (클라이언트가 TGS 세션키를 얻었다!!) 그리고 AS로부터 읽을 수 없는 TGT를 전달 받았는데 이는 TGS에게 전달하라고 받은 정보이다. 

 클라이언트는 자신이 AS로부터 인증 받았다는 것을 증명하기 위해 자신의 정보를 TGS세션키로 암호화 하여 Authenticator 를 만든다. 

<6> Authenticator, TGT 전달 

클라이언트는 자신아래와 같이 자신이 만든 Authenticator와 TGT를 전달한다. 

  (1) Authenticator = TGS세션키로 암호화한 ~~~ 클라이언트 정보 (클라이언트ID, 현재 Timestamp)
  (2) TGT = TGS비밀키로 암호화한 ~~~ 클라이언트 정보 (클라이언트ID, 주소, 유효기간, AS가 전달한 TGS세션키) 

<7> 사용자 인증 정보 확인 , Ticket발급 

 TGS는 사용자가 보낸 Authenticator와 TGT를 확인한다. Authenticator는 TGS세션키로 암호화되어 있는데 이는 AS가 임시로 발급한 것이기 때문에 이름이 무색하지만 TGS는 모른다. 대신 TGS비밀키를 복호화 할 수 있는데 그 안에서 TGS세션키를 얻을 수 있다. 이렇게 TGT와 Authenticator에서 클라이언트ID 및 유효기간을 확인해서 문제가 없는 경우  다시 TGS세션키를 사용해 SS세션키를 발급한다. 그리고 SS에게 클라이언트 정보를 전달하기 위해 SS비밀키로 암호화한 Ticket을 발행한다. 

<8> 발급한 SS세션키, Ticket 전달  

(1) 다시 TGS세션키로 암호화한 ~~~~ SS세션키
(2) Ticket = SS비밀키로 암호화한 ~~~~ 클라이언트 정보 (클라이언트ID, 주소, 유효기간, SS세션키)

<9> TGS세션키로 SS세션키 복호화 

드디어 클라이언트가 SS세션키를 받았다!! 이미 가지고 있는 TGS세션키를 가지고 SS세션키를 얻었다. SS세션키로 TGS에게 전달해줬던 것과 동일하게 SS세션키로 Authenticator를 만든다. (이때 TGS세션키를 안쓰고 왜 SS세션키를 새로 만들어서 쓸까?) 

 

<10> Authenticator, Ticket 전달 

 (1) Authenticator = SS세션키로 암호화 클라이언트 정보 (클라이언트ID, 주소, Timestamp)
 (2) Ticket = SS비밀키로 암호화한 ~~~~ 클라이언트 정보 (클라이언트ID, 주소, 유효기간, SS세션키)

 <11> 사용자 인증 정보 확인, 서비스 

  SS비밀키로 Ticket을 복호화하여 SS세션키를 얻어 클라이언트 정보를 비교하여 사용자 인증 정보 확인하고 서비스를 제공한다. 

 

커버로스 프로토콜 동작 방식 (참고 : https://www.letmecompile.com/kerberos-protocol/) 

- 커버로스는 강한 보안과 사용자 정체성idendity을 구성하는 기본으로 하둡 접근 제어하기 위한 솔루션이다. 

- 사용자는 하둡 클러스터에서 그들을 인증하는 것이 필요하다. 일단 인증이 되면 그들은  리소스에 접근할 수 있고 

맵리듀스 작업과 같이 클러스터 안에서 상호작용할 수 있다

- 게다가 사용자들은 하둡 클러스터 리소스들은 잘못된 시스템 접근이나 데이터 접근을 피하기 위해 인증작업이 필요하다 

- 하둡은 커버로스를 사용해서  사용자와 서비스들 사이의 강력한 인증 작업을 수행할 수 있도록 한다. 커버로스는 서드파티 인증 매커니즘으로 

사용자들과 서비스들은 커버로스 서버를 통해 서로 인증하게 된다. 커버로스 서버는 Key Distribution Center, KDC 라고 한다. 

- KDC는 아래와 같이 구성된다.

> principals : 사용자와 서비스 DB. 이것을 통해 커버로스 패스워드를 알 수 있다.   

> Authentication Server(AS) : 초기 인증 작업 및 Ticket Granting Ticket(TGT) 를 발급한다 

> Ticket Granting Server(TGS) : TGT에 이어지는 서비스 티켓을 발급한다.

- user principal은 AS로 부터 인증을 요청한다. AS는 user principal의 커버로스 패스워드를 이용해 TGT를 암호화 하여 발급한다. 

- 커버로스 패스워드는 AS와 user principal 이 있어야 알 수 있따. 

- user principal은 커버로스 패스워드를 사용하여 TGT를 로컬지역에서 복호화 하고, 티켓이 만료되기 전까지 티켓을 전달한다. 

- user principal은 TGS로부터 서비스 티켓을 받기 위해 TGT를 사용한다. 서비스 티켓은 principal(user/service)이 다양한 서비스를 접근할 수 있도록 한다. 

- 클러스터 리소스(host/service)가 매번 TGT를 복호화 하여 패스워드를 제공할 수 없기 때문에 keytab 이라는 특별한 파일을 만드는데, 이것은 

리소스의 principal 인증서와 같은 역할을 한다. 커버로스 서버들의 host, user, serivce 집합들은 realm 이라는 제어control을 갖는다. 

--- 정리 ---

Key Distribution Center, or KDC

The trusted source for authentication in a Kerberos-enabled environment.

Kerberos KDC Server

The machine, or server, that serves as the Key Distribution Center (KDC).

Kerberos Client

Any machine in the cluster that authenticates against the KDC.

Principal

The unique name of a user or service that authenticates against the KDC.

Keytab

A file that includes one or more principals and their keys.

Realm

The Kerberos network that includes a KDC and a number of Clients.

KDC Admin Account

An administrative account used by Ambari to create principals and generate keytabs in the KDC. 

** 커버로스 principals

- 하둡의 각각의 서비스와 그 하위의 서비스들은 반드시 그들만의 principal을 가져야 한다. 

- principal은 realm 으로 부터 주어진 이름인데 primary name + instance name 으로 구성되며, instance name은 해당 서비스의 FQDN 값이다. 

- 서비스들은 그들의 티켓을 얻기 위해 패스워드를 가지고 로그인 하지 않고, keytab 파일에 저장된 principal 을 통해 인증을 한다. 

- keytab 파일은 커버로스 DB(KDC)로부터 추출되고 각 서버의 디렉토리에 그 서버에서 수행되는 서비스 principal 값 별로 저장된다. 

- Ambari 서버를 포함한 클러스터에 포함된 서버들은 각 서버에서 수행되는 서비스 principal에 대한 keytab 파일을 가지고 있다. 

- 그리고 그 모든 principal 에 대한 정보는 KDC(커버로스DB) 에 저장되어 있다. 

  > Principals : $service_component_name/$FQDN@EXAMPLE.COM >> nn/c6401.ambari.apache.org@EXAMPLE.COM

  > Keytabs :  $service_component_abbreviation.service.keytab >> /etc/security/keytabs/nn.service.keytab

- 위에 보이는 예제들은 각 서비스 principal 에 대한 primary name을 보여주는데, primary name 이란 nn 이나 hive와 같은 것으로 각각 

NameNode와 Hive 서비스를 나타낸다. 각 primary name 뒤에 instance 명이 붙게되고 수행되는 서버의 FQDN이 붙은 것을 확인할 수 있다. 

- 이러한 규칙은 다수의 host에서 수행되는 서비스들의 principal 명을 유니크 하게 가져갈 수 있도록 한다. 이러한 특성으로 같은 primary name을 가진 

다른 서비스에게 인증을 동시에 해주지 않게 된다. 예를 들어 A서버에 있는 datanode에게 커버로스 인증을 받았다고 해서 다른 모든 서버의 datanode에게 

인증을 받은 것은 아니다. 만약 완전하게 동일한 primary name을 가진 datanode가 존재하고, 모두 동시에 namenode에 접근 하려고 한다면 커버로스 인증은 

동일한 timestamp를 부여함으로써 반복적으로 요청하는 작업을 막는다. 

@ Ambari Principals .. 

- Ambari의 principal은 하둡 서비스들에 대한 principal 외에도 ambari 자체적으로 ambari principal 집합을 갖는데, smoke check를 수행하기 위해 사용된다. 

- smoke check란 알림 상태 체크, 각 클러스터 컴포넌트들의  매트릭스 확인과 같은 관리 측면의 모니터링을 말한다. 

- Ambari principal의 Keytab 파일은 각 cluster hosts에 두는데 서비스 principal을 저장하는 keytab 파일과 유사하게 관리된다.

- Ambari principal의 구성

> Smoke and “Headless” Service users : 각 서비스 상태 모니터링 정보

> Ambari Server user :  클러스터가 커버로스로 부터 사용가능해 지면 REST 정보를 제공하는 컴포넌트( yarn timeline-server(ATS) 같은) 이 SPNEGO 인증을 요청한다. 

(SPNEGO : http 기반의 서비스를 접근할 때 일반적으로 인증이 필요하지 않은데, 커버로스 SPNEGO 를 통해 이러한 webUI 접근을 막을 수 있다) 

** 커버로스 데이터베이스 KDC 설치 (RHEL/CentOS 기준) 

- 만약 MIT KDC 가 없다면 설치한다. 만약 커버로스 client 를 ambari에서 먼저 설치 한 후 KDC 를 설치하게 되면 kr5.conf 파일을 덮어 쓰게 되므로 주의한다. 

1) 새로운 버전의 KDC 서버를 다운 받는다 

-  yum install krb5-server krb5-libs krb5-workstation

2) KDC 설정 파일을 환경에 맞게 변경한다 

- vi /etc/krb5.conf

- realms 섹션 변경

> FQDN 변경 (kerberos.example.com -> 클러스터 도메인) 

> kdc 와 admin_server 도 FQDN 으로 변경 

[realms]

 EXAMPLE.COM = {

   kdc = my.kdc.server

   admin_server = my.kdc.server

}

3) Hue와 같이 티켓을 새로 발급 받을 수 있는 컴포넌트들은 libdefaults 변경 

- vi /etc/krb5.conf

> renew_lifetime = 7d

4) 커버로스 DB 생성 

- kdb5_util create -s

5) KDC 수행 / 서비스 등록 

- centos6

> /etc/rc.d/init.d/krb5kdc start

> /etc/rc.d/init.d/kadmin start

- centos7

> systemctl start krb5kdc

> systemctl start kadmin

6) 반드시 서비스 등록을 하여 서버 기동시 동작할 수 있도록 한다.

- centos6

> chkconfig krb5kdc on

> chkconfig kadmin on

- centos7

> systemctl enable krb5kdc

> systemctl enable kadmin

7) 커버로스 Admin 생성 

- 커버로스 principals 은 admin principal를 사용하여 KDC 의 서버 내에 또는 network 를 통해 생성된다. 

-  다음 명령어는 KDC 서버와 kadmin.local 이라는 관리 도구를 사용하는 것인데, kadmin.local은 KDC 서버가 

처음에 별도의 admin principal 생성 없이 principal 을 만들 수 있도록 해준다. 

- 그리고 커버로스 설정을 하기 위해서는 ambari 관리자로 접속해야 한다. 그래야 ambari가 KDC에 접속해 clutser principal과 keytab 을 만든다 

- admin principal 생성을 통해 KDC admin 생성 

>kadmin.local -q "addprinc admin/admin"

- admin principal 권한 관리 (KDC ACL 편집) 

> vi /var/kerberos/krb5kdc/kadm5.acl

- KDC ACL 파일은 admin principal 이 KDC 에 설정된 특정 realm 을 관리하기 위한 정보를 가지고 있다. 

위에서 생성한 KDC admin 정보와 FQDN 을 이용해 다음과 같이 값을 추가한다. 

> */admin@HADOOP.COM *

- kadm5.acl 파일 편집 저장 후 kadmin 을 재시작 한다. 

> /etc/rc.d/init.d/kadmin restart

** 커버로스 수동설치 

1) 사전요구사항 

- 클러스터 호스트들이 KDC에 접근 가능해야 함 

- 클러스터 모든 host에 커버로스 client가 설치되어야 함 

- JCE (Java Cryptography Extensions) 이 암바리 서버와 모든 호스트에 설치되어야 함 

- 설치 위자드가 끝나기 전에 서비스와 암바리 principal이 KDC 안에 수동으로 생성되어야 한다. 

- keytab 파일들이 설치 위자드가 끝나기 전에 생성 및 모든 서버에 배포되어야 한다. 

2) 커버로스 security 사용

- 수동으로 커버로스를 설치하는 경우를 위해 설치 위자드가 제공된다. 하지만 위자드 실행 전에 선행되어야 할 작업이 있다. 

- JCE 설치 

> 만약 Oracle JDK를 사용하고 있다면 JCE를 모든 서버에 설치, 배포 해야 한다. 그리고 JCE 설치 후 ambari-server를 재시작 해야 한다. 

> 만약 OpenJDK를 사용하고 있다면 JCE 설치가 필요하지 않다. 

> http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html 다운로드

> unzip -o -j -q jce_policy-8.zip -d /usr/jdk64/jdk1.8.0_60/jre/lib/security/

> ambari-server 재시작 

3) 설치 위자드 실행 

- 설치 위자드 실행전에 MIT KDC가 있거나 커버로스 principal/keytabs 이 수동으로 관리되어야 한다. 

- KDC가 설치되어 있다면 위자드 실행 후 KDC 관련 정보를 입력해야 한다. 정보가 제공되면 암바리는 자동으로 principals를 만들고 

keytab을 모든 서버들에 생성 배포할 것이다. 서비스들은 커버로스를 위해 설정 변경되어야 하며, KDC로 인증 후 재시작 해야 한다. 이러한 작업은 

자동화 되어 있다. 

...계속 

https://docs.hortonworks.com/HDPDocuments/Ambari-2.5.0.3/bk_ambari-security/content/launching_the_kerberos_wizard_automated_setup.html

 

** SPNEGO 설정 방법(HDFS, Yarn, Mapred2, HBase, Oozie, Falcon and Storm)

1) 인증토큰을 위한 secret key를 생성한다. 이러한 파일은 반드시 임의의 데이터와 클러스터의 모든 호스트 정보들이 있어야 한다.

또한 hdfs 사용자와 hadoop group 에 대한 정보도 포함해야 한다. Permission은 반드시 440 으로 설정되어야 한다. 

-  예시 

> dd if=/dev/urandom of=/etc/security/http_secret bs=1024 count=1

> chown hdfs:hadoop /etc/security/http_secret

> chmod 440 /etc/security/http_secret

2) Ambari HDFS 설정에서 다음 값들로 수정한다 

hadoop.http.authentication.simple.anonymous.allowed = false

hadoop.http.authentication.signature.secret.file = /etc/security/http_secret

hadoop.http.authentication.type = kerberos

hadoop.http.authentication.kerberos.keytab = /etc/security/keytabs/spnego.service.keytab

hadoop.http.authentication.kerberos.principal = HTTP/_HOST@EXAMPLE.COM 

hadoop.http.filter.initializers = org.apache.hadoop.security.AuthenticationFilterInitializer

hadoop.http.authentication.cookie.domain = hortonworks.local (반드시 네임노드 도메인) 

> 참조 : 각 환경에 맞게 변경해야 함

 

3) 설정을 저장하고 restart the affected service 수행