개요

이전에 구현한 라즈베리 파이 클러스터에서 Harbor를 배포하는 과정중에 인증서 관련 이슈가 있었다.. Harbor Helm Chart를 배포하고나면 (로드밸런서 장비가 없기 때문에 MetalLB로 Private IP 대역중 하나의 주소를 LoadBalancer의 External IP로 할당해주고 있는데) Nginx의 LoadBalancer 타입의 Service로 브라우저에서 접속은 가능하나, docker 명령어를 통해 로그인 및 이미지를 푸시하는 과정에서 인증서 이슈가 발생했다..

사실 솔직하게 얘기하면 HTTPS나 TLS에 관련된 내용을 대강 통신중에 암호화하는 정도로만 이해를 했지, 실제로 딥다이브를 해본적이 없어서 정리해보려고 한다. 쿠버네티스에서 인증체계 관련 내용도 볼때 인증기관(CA), X509 인증서 같은 단어들이 나올때마다 항상 어지러웠다..

 

 

대칭키와 비대칭키

인증서 이야기를 하기 전에 대칭키와 비대칭키에 대한 이야기를 빼놓을 수 없어서 정리하려고 한다.. 쉽게 얘기하면 클라이언트와 서버간 통신 혹은 데이터 암호화를 동일한 키로 할 것이냐, 혹은 다른 키로 할 것이냐는 이야기다.

  • 대칭키 (Symmetric Key) : 클라이언트가 자신의 데이터를 서버에 전송하는 과정중에 공격자가 스니핑과 같은 탈취적 행위를 하게 될 경우에 대비하여 데이터를 암호화 해야한다. 이때 암복호화에 사용하는 동일한 키를 대칭키라고 한다.
  • 비대칭키 (Asymmetric Key) : 비대칭키는 암호화와 복호화에 사용되는 키를 서로 다른 퍼블릭 키(Public Key)와 프라이빗 키(Private Key)로 나눠둔 것이다. 클라이언트가 퍼블릭 키를 통해 암호화한 데이터를 서버는 프라이빗 키를 통해 복호화한다.

 

 

SSL/TLS 인증서

  • 비대칭 키 방식을 사용하더라도 해커가 위조된 웹 사이트를 통해 클라이언트를 유인하여 자신이 만든 퍼블릭 키, 프라이빗 키를 통해 클라이언트의 데이터를 탈취할 수 있다.
  • 고로, 클라이언트는 서버의 퍼블릭 키가 신뢰가능한 것인지를 판단할 수단이 필요하다. 이를 인증해주는 것이 인증서(Certificate)이다.
  • 인증서가 만들어지고 인증되는 과정은 크게 두 단계로 나뉘어진다.
    • Signing
      • 서버(혹은 기업)은 자신의 퍼블릭 키(와 도메인)를 인증 기관(CA, Certificate Authority)에 제출한다.
      • 인증 기관은 SHA256과 같은 해시 알고리즘을 통해 서버의 퍼블릭 키를 해시값으로 변환한다.
      • 인증 기관은 자신들의 새로운 퍼블릭 키와 프라이빗 키를 생성하고, 프라이빗 키를 통해 해시값을 암호화한다. 암호화된 해시값을 서명(Signature)라고 한다.
      • 인증서에 서버의 퍼블릭 키와 Signature를 결합하여 서명된 인증서를 생성한다.
    • Verification
      • 클라이언트는 서버에게 믿을 수 있는 서버인지 확인하기 위해 인증서를 요구한다.
      • 클라이언트는 인증서에 포함된 서버의 퍼블릭 키를 해시 함수를 통해 해시값 1로 변환한다.
      • 인증서에 포함된 Signatrue를 인증 기관의 퍼블릭 키로 복호화하여 해시값 2를 얻는다.
      • 해시값1과 해시값2를 비교하여 해당 서버의 퍼블릭 키가 신뢰할 수 있는지 판단한다.
  • 멀티 도메인을 단일 인증서로 관리하고 싶으면 SAN(Subject Alternative Name)으로 여러 도메인 및 호스트를 추가시킬 수 있다.

 

'[CS] - Network' 카테고리의 다른 글

네트워크와 IP 주소  (0) 2025.09.25

티스토리툴바