대칭키와 비대칭키 - Kubernetes 인증 이해를 위한 기초

Kubernetes 의 인증 방식을 이해하기 위해 암호화의 기본 개념인 대칭키와 비대칭키에 대해 알아봅니다.

암호화 기본 개념

평문 (Plaintext) → [암호화] → 암호문 (Ciphertext)
암호문 (Ciphertext) → [복호화] → 평문 (Plaintext)

• 평문: 암호화되지 않은 원본 데이터
• 암호문: 암호화된 데이터
• 키 (Key): 암호화/복호화에 사용되는 비밀 값

대칭키 암호화 (Symmetric Key Encryption)

개념

    flowchart LR
    subgraph "송신자"
    P1["평문"]
    end
    
    subgraph "수신자"
    P2["평문"]
    end

    subgraph "암호화/복호화 과정"
    E["암호화 Encrypt"]
    D["복호화 Decrypt"]
    K(("대칭키 Secret"))
    end

    P1 --> E
    E -- "암호문" --> D
    D --> P2
    K -.-> E
    K -.-> D
  

핵심: 암호화와 복호화에 동일한 키 사용

특징

대표 알고리즘

예시: AES-256

# 의사코드 예시
key = "0123456789abcdef0123456789abcdef"  # 256 비트 (32 바이트)
plaintext = "Hello, Kubernetes!"

# 암호화
ciphertext = AES_Encrypt(key, plaintext)
# 결과: "a1b2c3d4e5f6..." (암호문)

# 복호화
decrypted = AES_Decrypt(key, ciphertext)
# 결과: "Hello, Kubernetes!" (원본 복원)

대칭키의 문제점: 키 배포

    sequenceDiagram
    participant A as Alice
    participant B as Bob
    Note over A,B: 키를 어떻게 전달할까?
    A->>B: 대칭키 (Secret Key) 전송?
    Note right of B: 문제: 탈취 위험!
    Note over A,B: n 명이 통신하려면 n(n-1)/2 개의 키 필요
  

키 배포 문제의 본질

“키 배송의 역설”

상황: Alice 가 Bob 에게 비밀 메시지를 보내고 싶음

문제:

1. 메시지를 암호화하려면 공통의 키가 필요함
2. 하지만 키를 안전하게 전달할 방법이 없음
3. 키를 보내다가 해커에게 탈취당하면 모든 통신 노출!

역설: “보안 통신을 하려면 안전한 키 배송이 필요하지만, 안전한 키 배송을 하려면 이미 보안 통신이 필요하다.”

키 배포 시나리오

키 관리 복잡성

n 명이 상호 통신할 때 필요한 키 수: n(n-1)/2

비대칭키가 해결한 문제: 키 배포

비대칭키의 핵심 아이디어

    sequenceDiagram
    participant A as Alice
    participant B as Bob
    Note over B: 1. 키 쌍 생성 (공개키/개인키)
    B->>A: 2. 공개키 배포 (누구나 접근 가능)
    Note over A: 3. Bob의 공개키로 메시지 암호화
    A->>B: 암호문 전송
    Note over B: 4. 자신의 개인키로 복호화 (나만 가능)
  

공개키 배포 방법

1. 웹사이트 게시: https://bob.com/public-key.pem 등 누구나 다운로드 가능하게 게시
2. 공개 키 디렉토리: 키 서버(keys.openpgp.org 등)에 등록하여 검색 가능하게 함
3. 디지털 인증서 (CA): 신뢰할 수 있는 기관(CA)이 소유자 정보와 공개키를 묶어 서명한 인증서 형태

비대칭키의 장점/단점

비대칭키 암호화 (Asymmetric Key Encryption)

개념

    flowchart TD
    subgraph "송신자"
    P1["평문"] --> E["암호화 Encrypt"]
    end
    
    subgraph "수신자"
    D["복호화 Decrypt"] --> P2["평문"]
    end

    E -- "암호문" --> D
    
    K1["수신자의 공개키 Public"] -.-> E
    K2["수신자의 개인키 Private"] -.-> D
  

두 가지 사용 방식

1. 기밀성 (Confidentiality) - 암호화

• 방법: 수신자의 공개키로 암호화 → 수신자의 개인키로 복호화
• 결과: 수신자 본인만 읽을 수 있는 보안 통신 보장

2. 인증 (Authentication) - 디지털 서명

• 방법: 송신자의 개인키로 서명 → 송신자의 공개키로 검증
• 결과: 송신자의 신원 확인 및 데이터 위변조 방지 (부인 방지)

하이브리드 방식: TLS/SSL

현대 암호화 통신은 대칭키와 비대칭키의 장점을 결합하여 사용합니다.

TLS 핸드셰이크 흐름 (간략화)

    sequenceDiagram
    participant C as 클라이언트
    participant S as 서버
    
    C->>S: 1. ClientHello (지원 목록 전달)
    S->>C: 2. ServerHello + 인증서 (서버 공개키 포함)
    Note over C: 3. 인증서 검증 및 프리마스터 시크릿 생성
    C->>S: 4. 서버 공개키로 암호화된 프리마스터 시크릿 전송
    Note over S: 5. 개인키로 복호화하여 시크릿 획득
    Note over C,S: 6. 양쪽에서 동일한 세션 키 (대칭키) 생성
    C<->>S: 7. 생성된 대칭키로 고속 암호화 통신 시작
  

💡 참고: 위 흐름은 단순화한 것으로 고전적인 RSA 키 교환(TLS 1.2 이하)을 따릅니다. TLS 1.3 에서는 임시 ECDHE 교환으로 세션 키를 유도하고, 서버 인증서의 키는 핸드셰이크 서명에만 사용됩니다.

Kubernetes 와의 연관성

Kubernetes 내부의 다양한 보안 영역에서 이 메커니즘들이 활용됩니다.

1. API Server TLS: 서버/클라이언트 인증서(비대칭키)와 실제 데이터 통신(대칭키) 결합
2. ServiceAccount: 개인키로 토큰에 서명하고, 공개키로 위변조 여부 검증
3. Secret 암호화: etcd 저장 시 AES(대칭키) 사용, 키 관리는 KMS(비대칭키/KMS) 연동 가능

요약

대칭키와 비대칭키의 하이브리드 운영 원리를 이해하는 것이 Kubernetes 보안의 시작입니다.