Kerberos

Kerberos는 네트워크 상에서 사용자 및 서비스의 신원을 안전하게 인증하기 위한 프로토콜입니다. 대칭 키 암호화를 사용하여 클라이언트, 서버, 그리고 신뢰할 수 있는 제3자인 KDC(Key Distribution Center) 간의 인증을 수행합니다.

Kerberos 작동 방식

인증 요청 (Authentication Request): 클라이언트가 KDC에 인증을 요청합니다. 이 요청에는 클라이언트의 ID가 포함됩니다.
TGT 발급 (Ticket Granting Ticket): KDC는 클라이언트를 인증하고 TGT(Ticket Granting Ticket)를 발급합니다. 이 TGT는 암호화되어 있으며, 클라이언트만이 해독할 수 있습니다.
서비스 요청 (Service Request): 클라이언트는 TGT를 사용하여 특정 서비스에 대한 접근 권한을 요청합니다.
서비스 티켓 발급 (Service Ticket): KDC는 클라이언트가 요청한 서비스에 대한 서비스 티켓을 발급합니다. 이 티켓은 해당 서비스만이 해독할 수 있습니다.
서비스 접근 (Service Access): 클라이언트는 서비스 티켓을 제시하여 서비스에 접근합니다.

이런 인증과정을 일상에서 사설 수영장 강습을 듣는 과정으로 비유할 수 있습니다.

회원제 수영장에서 1달 회원권을 가입합니다.
카운터에서 회원증을 발급합니다.
강습을 듣고 싶다고 합니다.
카운터에서 강습비를 받고 강습에 등록합니다.
강습을 들으러 갑니다.

Credential Cache

세션이 유지되는 동안 유효한 TGT, service Ticket은 ccache(Creadential Cache)파일에 들어있습니다. 따라서 ccache에 인증정보가 유지되는 동안 이를 사용한다면 서비스요청시 매번 TGT, ST를 발급받는 과정을 피하고 5번 단계를 수행할 수 있습니다.
일반적으로 다음 인증 정보를 저장합니다.

service principal name
client principal name
lifetime
flags

ccache types

각 시스템별 지원되거나 기본값으로 설정된 캐시 타입이 다를 수 있습니다(linux-FILE, macOS-API)
구현하는 기능과 시스템에 맞는 캐시타입으로 인증단계를 넘어갈 필요가 있습니다.

FILE (파일 기반 캐시)
• 기본적으로 많이 사용되는 유형.
• 예: /tmp/krb5cc_100
• 여러 프로세스/스레드가 동시에 접근하면 경쟁 조건(race condition) 발생 가능.
• 단일 사용자/단일 세션 환경에서 적합.
DIR (디렉터리 기반 캐시)
• 하나의 디렉터리에 여러 개의 캐시 파일을 만들어, 여러 프로세스가 동시에 사용 가능하게 설계됨.
• 예: KRB5CCNAME=DIR:/tmp/krb5cc_dir_cache
• shared 환경, multi-thread 환경에서 추천됨. 병렬 처리에서 안전.
• Kerberos 1.11 이후 지원.
KEYRING (리눅스 keyring 기반)
• Linux의 커널 keyring 기능을 사용해서 메모리 상에 자격 증명을 저장.
• 예: KRB5CCNAME=KEYRING:persistent:1000
• 로그인 세션 간에도 유지 가능 (persistent 타입일 경우).
• 안전하고, 메모리 기반이라 빠름.
• 디스크에 저장되지 않기 때문에 보안에 유리.
MEMORY (메모리 기반 캐시)
• 캐시 내용을 RAM에만 저장함.
• 예: KRB5CCNAME=MEMORY:my_temp_cache
• 재부팅 또는 프로세스 종료 시 사라짐.
• 테스트용, 임시 세션 등에 사용.
• 프로세스 내에서만 안전하게 유지되므로 병렬 처리에는 적합하지 않음.
API (macOS, Windows 등 OS API 기반 캐시)
• OS에 내장된 인증 스토어를 활용.
• 예: macOS에서는 KRB5CCNAME=API:
• macOS 기본 동작이며 보안과 통합성에서 강점이 있음.

ccache 충돌 이슈

Kerberos ccache를 기본적인 FILE타입으로 사용시, 여러 프로세스 또는 스레드가 동시에 하나의 ccache 파일에 접근하려고 하면 경쟁 조건(race condition)이 발생할 수 있습니다. 이로 인해 인증 실패, 티켓 손상 등 예기치 않은 문제가 발생할 수 있습니다.
cache를 분리하고 KRB5CCNAME을 변경하는 방법은 다음과 같은 이점을 제공합니다:

격리 (Isolation): 각 병렬 요청이 고유한 ccache를 사용하므로, 다른 요청의 인증 정보에 영향을 주지 않습니다.
병렬 처리 (Parallelism): ccache 충돌을 방지하여 병렬 요청을 안전하게 처리할 수 있습니다.
유연성 (Flexibility): 각 요청에 대해 다른 ccache 설정을 적용할 수 있습니다.
다만, 이 방법을 사용할 때 다음과 같은 사항을 고려해야 합니다:
ccache 관리: 각 요청에 대해 생성된 ccache 파일을 적절히 관리해야 합니다. 불필요한 ccache 파일이 쌓이지 않도록, 요청 완료 후에는 해당 ccache 파일을 삭제하는 것이 좋습니다. (kdestroy 명령어 사용)
보안: ccache 파일이 저장되는 위치를 안전하게 관리해야 합니다. ccache 파일에는 민감한 정보가 포함되어 있으므로, 권한 없는 사용자가 접근할 수 없도록 적절한 접근 제어를 설정해야 합니다.

위 ccache type을 서치하면서 다시 보니 DIR 특징이 필요해 임의로 로직을 추가한 방식으로 보이네요. 시스템에서 지원한다면 DIR 타입으로 더 안정적으로 처리되는지 테스트해봐야겠습니다.

상황별 캐시타입

상황	캐시타입
다중 프로세스/스레드, 같은 principal	DIR
다중 프로세스 + 서로 다른 principa	DIR
단일 principal, 단일 프로세스, 보안 중요	KEYRING
임시 스크립트, 테스트	MEMORY

참고자료

https://web.mit.edu/kerberos/

Kerberos: The Network Authentication Protocol

web.mit.edu

https://web.mit.edu/kerberos/krb5-1.12/doc/basic/ccache_def.html?highlight=ccache

'CS' 카테고리의 다른 글

[fluent python]함수 데코레이터와 클로저 (0)	2024.04.14
[python] 일급 함수 디자인 패턴 (0)	2024.03.31
utf8 (0)	2023.12.10