[Kubernetes] 39. Authentication - TLS Certificates (1)

 

모든 유저의 요청은 kube-apiserver를 거치고 요청을 처리하기 전에 인증(Authentication)을 거친다.

 

kube-apiserver 인증(Authentication) 메커니즘

1. static password file(v1.19부터 사용 불가)

2. static token file ( v1.19부터 사용 불가)

3. certificates

 

TLS란 무엇인가?

http로 요청 시 id/pw는 일반 텍스트로 전송됨 - 추출 용이

id: user1

password: password123

 

https로 요청하면 키/밸류 모두 암호화되어 전송됨

XCDV: DKSJKFD

LSFDLKFJDK: DLKJFADKLFJD

Symmetric encryption(대칭 암호화): 키도 함께 보내서 서버에서 암호회 된 데이터 복호화 함(단일 키)

Asymmetrci encryption(비대칭 암호화): private key(열쇠; 나만 가지고 있음) - public lock(자물쇠; 공용)

ssh-keygen
id_rsa(private 키)  id_rsa.pub(public 키)

cat ~/.ssh/authorized_keys # 파일에 공용키로 entry 추가

ssh -i id_rsa user1@server1 # ssh 명령어 사용 시 private 키 위치 추가

※ 키를 복사하여 여러 서버에 두면 여러 서버에서 공용으로 사용 가능



openssl genrsa -out my-bank.key 1024
my-bank.key(private 키)
openssl rsa -in my-bank.key -pubout > mybank.pem
my-bank.key   mybank.pem(public 키)
 
https로 접속 시 서버에서 public 키를 받음
STPS ???

브라우저가 신뢰할 웹 서버 인증서 만드는 방법?
권한 있는 사람이 서명하는 방법?

=> CA(Certificate Authority)
=> CSR(Certificate Signing Request) 생성
=> VI(Validation Information)
=> Sign and Send Certificate # 브라우저가 신뢰하는 CA가 서명한 인증서

## CSR 생성
openssl req -new -key my-bank.key -out my-bank.csr \
  -subj "/C=US/ST=CA/O=MyOrg, Inc./CN=my-bank.com"

 

공용키와 개인키로 메시지 비대칭 암호화 진행
관리자는 한 쌍의 키로 서버 SSH 연결 보안
서버는 한 쌍의 키로 STPS 트래픽 확보
(서버에서 CA에 인증서 서명 요청 CSR 보내고 CA는 개인키로 CSR 서명, 모든 사용자는 CA 공용키 복사본 가지고 있음, CA가 서명한 인증서 다시 서버로 보냄)
서버는 서명된 인증서로 웹 어플리케이션 구성
사용자가 웹에 액세스 할 때마다 서버는 먼저 공개키로 인증서를 사용자에게 보냄
사용자(브라우저)가 공개키 유효성검사를 위해 공개키 사용
사용자(브라우저)가 대칭키 생성하여 앞으로의 통신에 사용
대칭키는 서버의 공개키로 암호화되어 서버로 전송됨
서버는 개인키로 메시지 해독하고 대칭키 회수함
관리자가 SSH 보안키쌍 생성
웹 서버는 STTPS로 보안키쌍 생성
CA는 자체관리자를 생성하여 인증서에 서명
최종 사용자는 단일 대칭키만 생성, 웹 사이트 신뢰하면 아이디와 암호로 웹 서버 인증
서버의 키쌍은 사용자 인증서 유효성 확인 가능
하지만 서버는 사용자인지 확실히 모르고 이를 위해 사용자에게 인증서를 요청할 수 있음
사용자도 CA에게 인증서 서명 요청 CSR을 보내고 인증을 받음
일반적으로 웹 서버에서는 TLS 사용자 인증서 생성이 구현되지 않음

PKI(Public Key Infrastructure): 사용자, 서버, CA 등

개인키로 암호화하면 공개키를 가진 누구든 복호화할 수 있음

Certicifate(Public Key) 명명 => *.crt , *.pem

server.crt

server.pem

client.crt

client.pem

Certicifate(Private Key) 명명 => *.key , *-key.pem

server.key

server-key.pem

client.key

client-key.pem

 

1. 대칭키 암호화

• 대칭키 암호화는 하나의 키를 사용해서 데이터를 암호화하고 복호화하는 방식이야. 단순하고 속도가 빠르지만, 키가 노출되면 보안이 무너져. TLS에서는 이 대칭키를 주고받기 위한 더 안전한 방법이 필요해.

2. 비대칭키 암호화

• 비대칭키 암호화에서는 공개키와 개인키라는 두 개의 키가 사용돼.
  • 공개키는 누구나 알 수 있게 공개되지만, 이걸로 암호화된 정보는 개인키로만 풀 수 있어.
  • 개인키는 암호화와 복호화 모두에 사용될 수 있는 키지만, 소유자가 비밀로 관리해야 해.
• TLS에서는 비대칭키를 이용해 클라이언트와 서버가 안전하게 대칭키를 교환하고 나중에는 대칭키로 통신을 이어가게 돼. 이 방법을 키 교환이라고 해.

3. TLS 과정 요약

1. 핸드셰이크(Handshake) 시작
   • 클라이언트(브라우저)가 서버에 연결을 시도하면서 지원하는 암호화 방식 목록을 서버에 전달해.
2. 서버 인증 및 공개키 전달
   • 서버는 클라이언트에게 SSL 인증서를 보내. 이 인증서에는 서버의 공개키와 서버 신원을 보증하는 정보들이 들어 있어.
   • 클라이언트는 인증서의 신뢰성을 확인하기 위해, 이 인증서가 **CA(Certificate Authority)**로부터 발급되었는지 확인해.
3. 클라이언트의 비밀키 생성과 전송(CSR: Certificate Signing Request)
   • 클라이언트는 대칭키로 사용할 임시 비밀키(세션 키)를 생성하고, 서버의 공개키로 암호화해서 전송해. 이 대칭키는 핸드셰이크 이후 대칭 암호화 방식으로 데이터 통신에 쓰이게 돼.
4. 서버의 개인키로 복호화
   • 서버는 받은 대칭키 데이터를 개인키로 복호화해서 세션 키를 얻고, 이제 이 키로 데이터를 주고받아. 이렇게 해서 암호화된 세션이 시작되는 거야.

4. TLS 관련 개념

• CA (Certificate Authority): 신뢰할 수 있는 기관으로, 특정 서버나 도메인이 진짜인지 검증해서 인증서를 발급해. 클라이언트는 CA를 통해 인증서의 신뢰성을 검증할 수 있어.
• CSR (Certificate Signing Request): 공개키와 개인키를 생성한 후, 공개키와 서버 정보를 포함한 요청서를 CA에 보내는 것. 이 요청을 통해 인증서를 발급받아야 해.

 

 

4. identity service(타사 인증프로토콜 ex. LDAP)