[CKA] Kubernetes TLS

Kubernetes TLS

SSL TLS 인증서에 대해 알아보자. 우선 TLS는 SSL의 업데이트 버전이며 명칭만 다르다. TLS 인증서가 무엇인지, 왜 필요한지, 인증서 구성 방법이 뭔지 알아보자. TLS 인증서는 SSH 또는 웹 서버를 보호한다. 인증서는 거래중 두 당사자 사이의 신뢰를 보장하는데 사용된다.사용자가 웹 서버에 액세스하려고 할 때 TLS 인증서는 사용자와 서버 간의 통신이 암호화되고 서버가 자신의 이름임을 보장한다.

예를 들어보면 보안 연결이 없으면 사용자가 은행 홈페이지에 들어가 ID와 Passwd를 입력하면 일단 텍스트 형식(id:daaa055501 passwd:3281378!@#) 으로 은행 서버에 전송이 된다. 이 경우 네트워크 트래픽을 스니핑하는 해커는 쉽게 자격증명 데이터를 가져갈 수 있다. 이렇게 사용자의 은행 계좌를 해킹한다. 이런 방식은 안전하지 않다. 그래서 사용자가 은행서버에 데이터를 보낼 때 전송되는 데이터를 암호화 키를 사용하여 암호화 해야한다. 데이터는 기본적으로 임의의 숫자와 알파벳의 집합인 키를 사용하여 암호화된다. 데이터에 난수를 추가하고 인식할 수 없는 형식(djskjs:dshj2dsd324nqkdn dm5skdjs:andjk2343asfanfjf)으로 암호화한다. 그런 다음 데이터가 서버로 전송된다. 해커는 데이터를 얻을 수 있지만 데이터가 어떤 데이터인지 알 수 없다.

해커도 데이터를 읽지 못하지만 은행 서버도 데이터를 읽지 못한다. 키 없이는 데이터를 해독할 수 없다. 따라서 은행서버가 암호를 해독하고 메시지를 읽을 수 있도록 키의 복사본도 서버로 전송해야 한다. 이를 대칭키(symmetric encryption)라고 한다. 안전한 암호화 방식이지만 동일한 키를 사용해 데이터를 암호화하고 암호를 해독하기 때문에 와 수신자 간에 키를 교환해야 한다. 하지만 키도 같은 네트워크를 통해 전송이되기 때문에 해커는 그것을 스니핑 해서 키에 접근해 데이터를 해독할 위험이 있다.

그래서 비대칭 키(asymmetric encryption)를 사용한다. 비대칭 키는 대칭 키와 같이 단일 키를 사용하여 데이터를 암호화하고 해독하는 대신 키 쌍을 사용한다. 개인 키(프라이빗 키, private key) 및 공용 키(퍼블릭 키, public key)를 사용한다. 일반적으로 개인 키(private key)와 공용 키(public key)라고 부르지만 이해하기 쉽게 그것을 개인 키와 공용 잠금이라고 생각해보자. 열쇠와 자물쇠 쌍으로 생각해보면 나만 가지고 있는 비공개 키, 누구나 접근할 수 있는 공개된 자물쇠이다. 여기서 중요한 점은 자물쇠로 데이터를 암호화하거나 잠그면 관련 키로만 열 수 있다는 것이다. 따라서 키는 항상 안전해야 하며 다른 사람과 공유해서는 안된다. 자물쇠 공개되어 있어 누구나 자물쇠로 데이터를 잠글 수 있지만, 그 잠금을 해제하려면 개인 키로만 잠금을 해제할 수 있다. 

키 쌍을 사용하여 서버에 대한 SSH 액세스를 보호하는 사례를 살펴보자. 사용자 환경에 액세스해야 하는 서버가 있다. 암호는 너무 위험하기 때문에 키 쌍을 사용하려고 한다. 공용 및 개인 키 쌍을 생성한다.

$ ssh-keygen
id_rsa   id_rsa.pub

$ cat ~/.ssh/authorized_keys
ssh-rsa AAKFdsfjsklgdgklsgjdlglsdgjdkgsmfld;mfcls;cvjosvmdlmvclsc
dkfadajdjsdkjsdkjsdnjkand24435dmksda user1

ssh-keygen 명령어를 사용하여 두개의 파일을 생성한다. id_rsa 는 개인키이고 id_rsa.pub는 자물쇠(공개키)이다. 그런 다음 공용 키가 있는 항목을 서버의 SSH authorized_keys 파일에 추가하여 즉, 자물쇠를 사용하여 서버의 문을 잠궈 모든 접근을 차단하여 서버를 보호한다. 자물쇠가 공개되어 있고 누구나 들어올 수 있지만 안전한 개인 키가 없다면 서버에 접근할 수 없다.

$ ssh -i id_rsa user1@server1
Successfully Logged In!

SSH를 시도할 때 SSH 명령에서 개인 키의 위치를 지정한다. 사용자 환경에 다른 서버가 있는 경우 어떻게 해야 할까? 키 쌍으로 둘 이상의 서버를 어떻게 보호할까? 같은 공개키를 다른 서버에 복사하여 원하는 서버에 배치하면 된다. 그러면 동일한 개인키를 사용할 수 있게된다. 그럼 모든 서버에 안전하게 SSH로 연결할 수 있다. 다른 사용자가 서버에 접근해야하는 경우 어떻게 해야할까? 다른 사용자도 똑같이 ssh-keygen 명령어를 사용하여 키 쌍을 생성하면 된다.

 

이번엔 웹서버 예제를 살펴보자. 아까 대칭 암호화의 문제는 데이터를 암호화하는 데 사용된 키가 암호화된 데이터와 함께 네트워크를 통해 서버로 전송되어야 한다는 것이다. 따라서 해커가 데이터를 해독하기 위한 키를 얻을 위험이 있다.

어떻게든 서버의 열쇠를 안전하게 얻을 수 있다면 어떨까? 일단 키가 서버에 안전하게 사용 가능하게 되면, 서버와 클라이언트는 대칭 암호화를 사용하여 서로 안전하게 통신을 계속할 수 있다. 대칭 키를 클라이언트에서 서버로 안전하게 전송하기 위해 비대칭 키를 사용한다.

$ openssl genrsa -oyt my-bank.key 1024
my-bank.key
$ openssl rsa -in my-bank.key -pubout > mybank.pem
my-bank.key mybank.pem

 

ssh-keygen 명령은 이전에 SSH 목적으로 키 쌍을 만드는 데 사용되었기 때문에 형식이 약간 다르다. 여기서는 open SSL 명령을 사용하여 개인 키와 공용 키 쌍을 생성한다.

사용자가 HTTPS를 사용하여 웹 서버에 처음 액세스할 때 서버에서 공용 키를 얻는데, 해커가 모든 트래픽을 탐지하고 있기 때문에, 그도 공용 키의 복사본을 얻었다고 가정해보자. 그리고 사용자는 서버에서 제공한 공개키를 사용하여 대칭키를 암호화한다. 이제 대칭키는 안전하다. 그런 다음 가용자는 이것을 서버로 보낸다. 해커도 사본을 얻는다. 서버는 개인키를 사용하여 메세지를 해독한다. 그러나 해커는 대인키를 가지고 있지 않다. 그래서 해커는 암호를 해독할 수 없다. 대칭키는 이제 서버와 사용자가 안전하게 사용할 수 있다. 이제 대칭 키를 사용하여 데이터를 암호화하고 서로 전송할 수 있다.  동일한 대칭 키를 사용하여 데이터를 해독하고 정보를 검색할 수 있다.
해커는 어떤 데이터도 해독할 수 없는 암호화된 메시지와 공개 키를 가지고 있다. 비대칭 암호화를 통해 사용자에서 서버로 대칭 키를 성공적으로 전송했으며, 대칭 암호화를 통해 향후 사용자 간의 모든 통신을 안전하게 보호했다.

해커는 또 우리의 계정을 해킹할 새로운 방법을 찾는다. 우리가 이용하는 웹사이트와 동일한 가짜 웹사이트를 만들어 자신의 서버에서 웹사이트를 호스팅한다. 해커는 당신도 그것이 안전하다고 생각하기를 원하기 때문에 그는 자신만의 공개 및 개인 키 쌍을 생성하고 그것들을 자신의 웹 서버에서 구성한다. 그리고 마지막으로, 그는 어떻게든 사용자의 환경이나 당신의 네트워크를 수정하여 사용자가 은행 웹사이트를 들어갔을때 해커의 서버로 들어가지게 한다.   브라우저를 열고 웹 사이트 주소를 입력하면 익숙한 은행의 로그 페이지가 표시되므로 사용자 이름과 암호를 입력한다. 통신이 안전하고 암호화되었는지 확인하기위해 URL에 HTTPS를 입력해야 하고 브라우저가 키를 수신하고 암호화된 대칭 키를 보낸 다음 키로 암호화된 자격 증명을 전송하면 수신기가 동일한 대칭 키로 자격 증명을 해독한다. 해커의 서버와 암호화된 방식으로 안전하게 통신하고 있다. 안전하게 보이지만 해킹된것이다.

만약 사용자가 서버로부터 받은 키를 보고 그것이 진짜 은행 서버로부터 받은 합법적인 키라고 알 수 있다면 어떨까? 서버가 키를 보낼 때 키만 보내지 않고 키가 포함된 있는 인증서를 보낸다. 인증서를 자세히 살펴보면 실제 인증서와 비슷하지만 디지털 형식임을 알 수 있다.

인증서가 발급되는 대상, 서버의 공용 키, 서버 위치 등에 대한 정보가 있다. 오른쪽에는 실제 인증서의 출력이 표시된다. 모든 인증서에는 이름이 있다. 인증서가 발급된 사람이나 주체는 ID를 확인하는 데 도움이 되는 필드이기 때문에 매우 중요하다. 웹 서버용인 경우, 사용자가 브라우저의 URL에 입력한 내용과 일치해야 한다. 은행이 다른 이름으로 알려져 있고 사용자가 자신의 응용프로그램에 액세스하기를 원하는 경우 다른 이름과 함께, 이 모든 이름은 제목 아래의 이 인증서에 네이티브 이름 섹션으로 지정되어야 한다.

하지만 보다시피, 누구나 이런 인증서를 생성할 수 있다. 당신은 당신이 구글이라고 말하는 것을 스스로 생성할 수 있고, 그것이 해커가 이 사건에서 한 것이다. 그는 당신의 은행 웹사이트라는 인증서를 생성한다.

그렇다면 인증서를 어떻게 보고 합법적인지 확인할 수 있을까? 그것이 인증서의 가장 중요한 부분이다. 누가 서명하고 증명서를 발급했을까? 인증서를 생성한 경우 직접 서명해야 한다. 이를 자체 서명 인증서라고 한다. 생성한 인증서를 보는 모든 사용자는 사용자가 서명했기 때문에 안전한 인증서가 아니라는 것을 즉시 알 수 있다. 해커로부터 받은 증명서를 자세히 보면 당신은 해커가 직접 서명한 가짜 인증서라는 것을 알아차렸을 것이다.

 

모든 웹 브라우저에는 인증서 유효성 검사 메커니즘이 내장되어 있으며, 브라우저 텍스트에서는 인증서가 서버로부터 수신되고 인증서가 합법적인지 확인한다. 고정 인증서로 식별되면 실제로 경고한다.

 

그러면 어떻게 합법적인 인증서를 만들 수 있을까? 권한이 있는 사람이 서명한 인증서를 받으려면 어떻게 해야 할까? 그것이 인증 기관이나 CA가 필요한 부분이다. 인증서에 서명하고 확인할 수 있는 잘 알려진 조직이다. 잘 알려진 것들로는 Symantec, DigiCert, Comodo, GlobalSign 등이 있다. 이 방법은 이전에 생성한 키와 웹 사이트의 도메인 이름을 사용하여 요청 또는 CSR에 서명하는 인증서를 생성하는 것이다. open SSL 명령을 사용하여 이 작업을 다시 수행할 수 있다.

서명을 위해 CA로 보내야 하는 인증서 서명 요청인 CSR 파일. 인증 기관은 사용자의 세부 정보를 확인하고 체크아웃되면 인증서에 서명한 후 사용자에게 다시 보냅니다. 이제 브라우저가 신뢰하는 CA에서 서명한 인증서가 있습니다. 해커가 동일한 방법으로 인증서에 서명하려고 하면 유효성 검사 단계에서 실패하고 CA에서 인증서를 거부한다. 그래서 그가 호스팅하는 웹사이트는 유효한 인증서를 가지고 있지 않을 것이다. CA는 사용자가 해당 도메인의 실제 소유자인지 확인하기 위해 다양한 기술을 사용한다. 이제 브라우저가 신뢰하는 CA에서 서명한 인증서가 있다. 그러나 브라우저는 CA 자체가 합법적이었다는 것을 어떻게 알 수 있을까?

예를 들어 인증서가 가짜 CA에 의해 서명된 경우, 이 경우 우리 인증서는 Symantec에 의해 서명되었다. 브라우저가 Symantec이 유효한 CA인지 어떻게 알 수 있을까? 인증서가 Symantec이라고 말하는 사람이 아니라 Symantec이 서명한 것일까? CA 자체에는 공용 및 개인 키 쌍이 있다. CA는 개인 키를 사용하여 인증서에 서명한다. 모든 CA의 공용 키는 브라우저에 내장되어 있다.

브라우저는 CA의 공용 키를 사용하여 인증서가 실제로 CA 자신에 의해 서명되었는지 확인한다. 인증서는 웹 브라우저의 인증서 설정에서 볼 수 있으며 신뢰할 수 있는 CA 탭에서 볼 수 있다. 우리가 방문하는 은행, 이메일 등과 같은 공공 웹사이트가 합법적인지 확인하는 데 도움을 주는 공공 CA입니다.

그러나 조직 내에서 개인적으로 호스팅되는 사이트의 유효성을 검사하는 데는 도움이 되지 않는다. 예를 들어 급여 또는 내부 전자 메일 응용 프로그램에 액세스하는 데 사용된다. 이를 위해 개인 CA를 호스팅할 수 있다.

여기에 나열된 대부분의 회사는 회사 내에서 내부적으로 배포할 수 있는 CA 서버인 자체 서비스의 프라이빗 오퍼링을 보유하고 있다. 그런 다음 내부 CA 서버의 공용 키를 모든 직원 브라우저에 설치하고 조직 내 보안 연결을 설정할 수 있다.

그럼 간단히 요약해보면, 네트워크를 통해 전송되는 메시지를 암호화하려는 이유를 확인했다. 메시지를 암호화하기 위해 공용 키와 개인 키 쌍으로 비대칭 암호화를 사용한다. 관리자는 키 쌍을 사용한다. 서버에 대한 SSH 연결을 보호한다. 서버는 한 쌍의 키를 사용하여 트래픽을 보호한다. 그러나 이를 위해 서버는 먼저 인증서 서명 요청을 CA로 보내고, CA는 개인 키를 사용하여 CSR에 서명한다. 모든 사용자는 CA 공개 키의 복사본을 가지고 있다. 그런 다음 서명된 인증서가 서버로 다시 전송된다. 서버는 서명된 인증서로 웹 응용프로그램을 구성한다.

사용자가 웹 응용프로그램에 액세스할 때마다 서버는 먼저 공용 키와 함께 인증서를 발송한다. 사용자 또는 사용자의 브라우저가 인증서를 읽고 CA의 공용 키를 사용하여 서버의 공용 키를 확인하고 검색한다. 그런 다음 대칭 키를 생성한다. 대칭 키는 서버의 공용 키를 사용하여 암호화된 후 서버로 다시 전송된다.

서버는 개인 키를 사용하여 메시지의 암호를 해독하고 대칭 키를 검색한다. 대칭 키는 앞으로의 통신에 사용된다. 따라서 관리자는 SSH 보안을 위한 키 쌍을 생성한다. 웹 서버는 HTTPS로 웹 사이트를 보호하기 위한 키 쌍을 생성한다. 인증 기관은 인증서에 서명하기 위한 자체 키퍼 세트를 생성한다. 그러나 최종 사용자는 단일 대칭 키만 생성한다.

 

 

출처:

https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14296090#announcements