[Security] TLS, HTTPS, 인증 토큰 그리고 Kafka 인증서 심화 정리
IT 보안 및 인증 핵심 정리: TLS, HTTPS, 그리고 Token
1. 기본 개념 정의 (비유)
가장 기초가 되는 3가지 요소의 역할입니다.
| 용어 | 비유 | 설명 |
|---|---|---|
| TLS (SSL) | 방음 터널 / 금고 | 도청이 불가능한 암호화된 통신 통로입니다. |
| 인증서 (Certificate) | 신분증 / 여권 | “나 진짜 네이버 서버 맞아”라고 증명하는 파일입니다. |
| CA (Certificate Authority) | 구청 / 발급 기관 | 신분증이 가짜가 아님을 보증(서명)해 주는 신뢰 기관입니다. |
핵심: 클라이언트(요청자)는 서버의 신분증을 검사하기 위해 CA Bundle(믿을 수 있는 기관 목록) 을 반드시 가지고 있어야 합니다.
2. TLS 통신 흐름 (Handshake)
TLS 통신은 “느리지만 안전한 방식” 으로 비밀번호를 공유한 뒤, “빠른 방식” 으로 데이터를 주고받습니다.
1단계: 핸드셰이크 (준비 운동)
- Client Hello: “안녕? 나랑 비밀 대화 좀 하자.”
- Server Hello & Cert: “그래. 여기 내 인증서(신분증) 받아. 내 공개키(자물쇠) 도 들어있어.”
- 검증 (Verification): 클라이언트는 서버의 인증서가 CA(발급 기관) 의 서명을 받았는지 확인합니다.
- 키 교환 (Key Exchange):
- 클라이언트는 임시 비밀번호(세션 키)를 생성합니다.
- 이 세션 키를 서버의 공개키(자물쇠) 로 잠가서 서버에게 보냅니다.
- 서버는 자신의 개인키(열쇠) 로 잠금을 풀어 세션 키를 획득합니다.
2단계: 데이터 전송 (본격 대화)
- 암호화 통신: 이제 둘 다 세션 키를 알고 있습니다. 이후 데이터는 이 키로 빠르게 암호화해서 주고받습니다.
3. HTTPS와 TLS Termination
3.1. HTTPS의 공식
HTTPS = HTTP + TLS
HTTP라는 ‘편지 내용’ 은 변하지 않습니다. 단지 TLS라는 ‘강철 금고’ 안에 편지를 넣어서 보내는 것입니다.
3.2. TLS Termination (TLS 종단)
쿠버네티스나 클라우드 환경에서 주로 사용하는 패턴입니다.
- 외부 ↔ Ingress (입구): HTTPS 통신 (보안 철저)
- Ingress ↔ 내부 파드: HTTP 통신 (보안 해제)
이유: 암호화/복호화 부하를 입구(Ingress)에서 한 번만 처리하고, 내부에서는 가볍게 통신하기 위함입니다.
4. 토큰 기반 인증 (Bearer Token)
안전한 터널(TLS)이 연결된 후에, “내가 누구인지” 증명하는 수단입니다.
4.1. Bearer Token이란?
- 의미: “이 토큰을 소지한(Bearer) 사람에게 권한을 부여한다.”
- 비유: 현금(지폐) 과 같습니다. 잃어버리면 주운 사람이 주인 행세를 할 수 있습니다.
- 주의사항: 도난당하면 끝장이므로, 반드시 TLS(HTTPS) 터널 안에서만 주고받아야 합니다.
4.2. 전송 방식 (HTTP Header)
HTTP 요청 헤더에 아래와 같이 실어서 보냅니다.
1
Authorization: Bearer <토큰문자열>
4.3. 검증 원리 (JWT 기준)
서버는 토큰을 받으면 DB를 조회하는 것이 아니라, 수학적 계산을 합니다.
- 서버만 아는 비밀키(Secret Key) 를 꺼냅니다.
- 토큰의 서명(Signature) 부분이 내 비밀키로 풀리는지 계산해 봅니다.
- 계산이 맞으면 “유효한 토큰” 으로 인정합니다. (위조 불가)
5. 요약: 누가 무엇을 가지는가?
상황: 클라이언트(나) 가 서버(상대방) 에 접속할 때
| 구분 | 클라이언트 (Client) | 서버 (Server) |
|---|---|---|
| 역할 | 서버를 의심하고 검사함 | 신분을 증명해야 함 |
| 필요한 것 | CA Bundle (검증용 도장 목록) | 인증서 + 개인키 (신분증 + 열쇠) |
| 보유 토큰 | Access Token (입장권) | Secret Key (토큰 검증용 비밀키) |
Kubernetes & Kafka(Strimzi) 인증서 심화 정리
이 문서는 쿠버네티스에서 Kafka를 운영(Strimzi)할 때 접하게 되는 복잡한 시크릿(Secret) 구조와 자동 갱신 메커니즘, 그리고 인증서 파일들의 정확한 역할을 정리한 노트입니다.
1. 시크릿(Secret) 파일 뜯어보기
1.1. kafka-clients-ca-cert (신뢰 저장소)
역할: 클라이언트가 Kafka 브로커(서버)를 믿고 접속하기 위한 “화이트리스트(CA) 목록” 입니다.
| 파일명 | 설명 | 주 사용자 |
|---|---|---|
ca.crt | 표준 인증서 파일 (PEM) | Python, Go, Node.js, curl 등 일반 클라이언트 |
ca.p12 | 암호가 걸린 바이너리 파일 (PKCS#12) | Java 애플리케이션 (Spring Boot 등) |
ca.password | ca.p12를 열기 위한 비밀번호 | Java 앱 설정 시 입력 |
2. 인증서 관리와 자동 갱신 (Auto-Renewal)
2.1. 설정 확인 (Kafka CR)
Strimzi 오퍼레이터는 별도 설정이 없으면 “자동 갱신”이 기본값(Default) 입니다.
1
2
3
4
5
spec:
clientsCa:
# 이 부분이 아예 없거나 true면 자동 갱신 켜짐!
generateCertificateAuthority: true
renewalDays: 30 # 만료 30일 전에 갱신 시작
2.2. 누가 갱신했는지 확인하기
시크릿의 메타데이터(managedFields)를 보면 범인을 알 수 있습니다.
- 자동 갱신:
manager: strimzi-cluster-operator - 수동 수정:
manager: kubectl-client-side-apply또는 사용자 ID
2.3. 만료일 확인 명령어 (One-liner)
1
2
kubectl get secret kafka-clients-ca-cert \
-o jsonpath="{.data['ca\.crt']}" | base64 -d | openssl x509 -noout -dates
3. CA 시크릿은 왜 2개로 나뉘어 있을까? (보안 원칙)
“검증용(공개)” 과 “발급용(기밀)” 을 물리적으로 분리하기 위함입니다.
| 시크릿 이름 | 포함 파일 | 비유 | 역할 | 보안 등급 |
|---|---|---|---|---|
kafka-cluster-ca-cert | ca.crt | 신분증 견본 | “쟤 진짜 우리 편 맞아?” 확인용 | 공개 (브로커, 앱 모두 가짐) |
kafka-cluster-ca | ca.key | 인감 도장 | 새로운 인증서를 발급(서명)용 | 1급 기밀 (오퍼레이터만 가짐) |
핵심: 브로커(Pod)조차도 도장(
ca.key)은 가지고 있지 않습니다. 오직 오퍼레이터만 금고에 보관합니다.
4. 최종 사용자 인증서 (tls.crt / tls.key)
CA(기관)가 아니라, 실제 통신을 하는 당사자(브로커 또는 유저) 의 신분증 세트입니다.
| 파일명 | 비유 | 역할 | 공개 여부 |
|---|---|---|---|
tls.crt | 내 여권 | “나 kafka-0 브로커야”라고 남에게 보여주는 신분증. | 공개 |
tls.key | 내 지문 | “이 여권 진짜 내 거 맞아”라고 증명하는 암호키. | 절대 비밀 |
🔗 신뢰의 사슬 (Chain of Trust)
- 오퍼레이터가
ca.key(도장)로tls.crt(여권)를 찍어줍니다. - 브로커는
tls.crt(여권)를 들고 통신을 시도합니다. - 상대방은
ca.crt(견본)를 보고 “어? 진짜 도장이 찍혀있네?” 하고 믿어줍니다.
Comments powered by Disqus.