CKA-11일차

📍 CKA 11일차
📍 Udemy-Certified Kubernetes Administrator (CKA) with Practice Tests 129-143

---

129. Backup and Restore Methods

리소스 구성을 백업하는 더 나은 방법은 kube-api server를 쿼리하는 것이다.
kubectl을 이용해 kube-api server에 직접 접근함으로써 클러스터에 생성된 모든 개체에 대한 리소스 구성을 복사해 저장할 수 있다.

kubectl get all --all-namespaces -o yaml > all-deploy-services.yaml 명령어를 이용해 모든 네임스페이스에 있는 파드, 디플로이먼트, 서비스를 YAML 형식으로 파일에 추출하고 저장할 수 있다.

이는 일부 리소스 그룹을 위한 것이다. 그 외의 다른 리소스들을 고려하기 위해 HeptIO에서 VELERO라고 부르는 도구를 제공한다.

ETCD는 우리 클러스터 상태에 관한 정보를 저장한다.
클러스터 자체에 관한 정보와 노드 및 클러스터 내부에서 생성된 모든 리소스가 여기 저장된다.
그래서 리소스를 백업하는 대신 ETCD 서버 자체를 백업하는 것을 선택할 수 있다.

ETCD 클러스터는 마스터 노드에 호스트되어 있다.
ETCD 클러스터를 구성할 때 모든 데이터가 저장되는 장소(/var/lib/etcd)를 명시한다.

ETCD는 빌트인 스냅샷 솔루션도 지원한다.
etcdctl snapshot save 명령어를 이용해 데이터베이스 스냅샷을 찍을 수 있다.
스냅샷 파일은 현재 디렉터리의 이름으로 생성된다. 다른 경로에 생성하고 싶다면 전체 경로를 명시하면 된다.
etcdctl snapshot status 명령어를 이용해 백업의 상태를 볼 수 있다.

나중에 이 백업에서 클러스터를 복원하려면 먼저 kube-api server 서비스를 중단해야 한다.
복원하기 위해 ETCD 클러스터를 다시 시작해야 하는데 kube-api server가 ETCD에 의존하기 때문이다.

그런 다음 etcdctl snapshot restore 명령어에 백업 파일의 경로를 지정하여 실행하면 된다.
ETCD가 백업에서 복구할 때 새 클러스터 구성을 초기화하고 ETCD의 멤버를 새 클러스터의 새 멤버로 구성한다. 이는 새 멤버가 실수로 기존의 클러스터에 합류하는 것을 막기 위해서이다.
이 명령을 실행하면 새로운 데이터 디렉터리가 생성된다.

그런 다음 ETCD 구성 파일을 구성해 새 데이터 디렉터리를 사용한다.
그런 다음 데몬 서비스를 다시 로드하고 재시작해야 한다.
마지막으로 kube-api server 서비스를 시작해야 한다.
이제 클러스터가 원래 상태로 돌아왔을 것이다.

스냅샷을 저장할 때 명령어와 함께 '--endpoint','--cacert', '--cert', '--key' 옵션을 지정하는 것을 기억해라

결론적으로 백업을 위해 두 가지 옵션이 존재한다.
먼저, ETCD를 이용한 백업과 kube-api server 쿼리를 통한 백업이다.
둘 다 장단점이 있다.
관리되는 쿠버네티스 환경을 사용하는 경우 때로는 ETCD 클러스터에 액세스조차 안될 수도 있다. 그 경우엔 kube-api server를 쿼리하는 백업이 아마 더 나은 방법일 것이다.

---

130. Working with ETCDCTL

etcdctl은 etcd의 클라이언트를 위한 명령어이다.
우리의 실습 환경에서는 ETCD 키-값 데이터베이스가 static pod 형태로 마스터 노드에 배포되어 있다.
etcdctl을 사용해서 백업과 복구를 하기 위해서는 ETCDCTL_API의 버전을 3으로 세팅해야 한다.
ETCDCTL_API를 사용하기 전에 export ETCDCTL_API=3을 먼저 실행해야 한다.
etcdctl 명령어도 마찬가지로 '-h', '--help' 옵션을 제공한다.

---

132. Solution - Backup and Restore

export ETCDCTL_API=3를 먼저 실행해야 etcd 백업 명령어 등을 사용할 수 있다.

ETCD 버전을 알기 위해서는 ETCD 파드의 이미지 버전을 확인하면 된다.

/etc/kubernetes/manifests 폴더에는 static pod로 배포되는 클러스터 구성 요소들의 정의 파일들이 존재한다.

etcdctl snapshot save 명령어를 사용할 때 반드시 '--endpoint','--cacert', '--cert', '--key' 옵션을 지정해야 한다.
옵션들에 대한 정보는 kubectl describe 명령을 통해 etcd 파드에서 얻어올 수 있다.

틀린 문제

데이터가 복구될 디렉토리를 '--data-dir' 옵션으로 지정해야 한다.
ls 명령어를 통해 복구된 데이터를 확인할 수 있다.
이제 etcd 정의 파일에서 볼륨 경로를 데이터가 복구된 디렉토리로 변경하고 호스트 경로와 백업 경로를 추가하는 작업이 필요하다.

etcd 정의 파일에서 표시된 두 부분은 동일한 위치(데이터가 복구된 디렉토리)를 가리켜야 한다. 이 부분들은 etcd가 재생성될 때 로컬 호스트에 있는 데이터로 간주되는 데이터의 위치를 가리킨다.

etcd 정의 파일의 내용을 변경해으면 etcd 서버가 잠시 다운되기 때문에 액세스가 잠시 중단될 것이다.
새 정보를 기반으로 새 파드를 생성한다.

만약 자동으로 etcd 파드가 재실행되지 않으면 etcd 파드를 삭제해줘야 한다.
etcd 파드가 재실행되고 매니저와 스케줄러가 재가동되면서 파드, 서비스, 디플로이먼트가 재가동되는 것을 확인할 수 있다.

---

133. Practice Tests Backup and Restore Methods 2

현재 노드에 얼마나 많은 클러스터들이 존재하는 지 확인하기 위해 kubectl config view 명령어를 사용하면 된다.

cluster1으로 변경하기 위해서 kubectl config use-context cluster1 명령어를 사용하면 된다.

etcd를 찾는 방법
1. kubectl get pods -A | grep etcd 명령어를 통해 etcd 파드를 찾는다.
2. '/etc/kubernetes/manifest' 폴더를 확인하여 static pod로 정의되어 있는지 찾는다.
3. ps -ef | grep etcd 명령어를 통해 etcd 프로세스를 찾는다.

---

138. Kubernetes Security Primitives

쿠버네티스의 원시적인 보안에 대해 살펴보자.

클러스터 자체를 형성하는 호스트부터 시작한다.
이런 호스트에 대한 모든 접근은 보안되어야 한다.
비밀번호 기반의 인증은 불가능해야 하고 SSH 키 기반의 인증만 가능해야 한다.

쿠버네티스 모든 작전의 중심에는 kube-api server가 있다.
kubectl 명령어나 API에 직접 접근함으로써 kube-api server와 상호작용할 수 있다.
그것을 통해 클러스터에서 거의 모든 작업을 수행할 수 있다. 이것이 1차 방어선이다.

kube-api server 자체에 대한 접근을 제어하는 것이다.
두 가지 유형에 대해 결정을 내려야 한다.

• 누가 클러스터에 접근할 수 있을까?
• 그들이 무엇을 할 수 있을까?
  

누가 kube-api server에 접근할 수 있는지는 인증(authentication) 메커니즘에 의해 정의된다. kube-api server에 인증할 수 있는 다양한 방법이 있다.

그들이 무엇을 할 수 있는지는 권한 부여(authorization) 메커니즘에 의해 정의된다.

클러스터의 구성 요소 간의 모든 통신은 kubelet과 kube-proxy와 같이 작업자 노드에서 실행되는 건 TLS 암호화로 보안된다.

---

139. Authentication

쿠버네티스 클러스터는 다중 노드, 다양한 구성요소로 구성되어 있다.

• 관리자 -> 관리 업무를 수행하기 위해 클러스터에 접근한다.
• 개발자 -> 앱을 테스트/배포하기 위해 클러스터에 접근한다.
• 최종 사용자 -> 클러스터에 배포된 응용 프로그램에 접근한다.
• 타사 플그램 -> 통합 용도를 위해 클러스터에 접근한다.
  

최종 사용자의 보안은 응용 프로그램 자체에 의해 내부적으로 관리된다. 그러니 이 논의에서 제외한다.

쿠버네티스는 사용자 계정을 직접 관리하지 않는다. 그래서 사용자 세부 정보가 담긴 파일이나 인증서 또는 타사 ID 서비스와 같은 외부 소스에 의존한다.
그래서 쿠버네티스 클러스터에선 사용자를 생성할 수 없고 사용자 리스트도 볼 수 없다.

하지만 서비스 계정의 경우 쿠버네티스가 관리할 수 있다.
쿠버네티스 API를 이용해 서비스 계정을 생성하고 관리할 수 있으며 서비스 계정에 대한 독점적인 섹션도 있다.

모든 사용자의 접근은 kube-api server에 의해 관리된다.
kubectl 툴을 통해 클러스터에 접근하든 API를 직접 사용하든 상관없다.
모든 요청은 kube-api server로 간다. kube-api server는 요청을 처리하기 전에 먼저 인증을 한다.

고정 암호 파일, 고정 토큰 파일, 인증서, 타사 인증 프로토콜 등 다양한 인증 메커니즘이 있다.

고정 암호 파일의 경우, csv 파일에 사용자 목록과 암호를 만들 수 있다. 그리고 이것을 사용자 정보의 소스로 사용한다.
파일 이름을 kube-api server의 옵션으로 지정한 다음 kube-api server를 재시작해야 한다.

만약 클러스터를 kubeadm 도구를 사용해 설정했다면 kube-api server 파드 정의 파일을 수정해야 한다.

또는 사용자 및 암호를 '-u' 옵션을 통해 지정할 수 있다.

정적 토큰 파일의 경우, 옵션만 암호 파일과 다르게 설정해주면 된다.

고정 파일에 사용자 이름, 암호, 토큰을 저장하는 이 인증 메커니즘은 불안정하기 때문에 권장하지 않는다.

---

143. TLS Basics

인증서는 거래 도중 상호 신뢰를 보장하기 위해 사용된다.
가령, 사용자가 웹 서버에 접근하려고 할 때 TLS 인증서는 사용자와 서버 사이의 통신이 암호화되도록 한다.

• 대칭키 암호화(Symmetric Encryption)
  • 데이터를 암호화하고 해독하는 데 같은 키를 사용한다.
  • 키를 수신기와 교환해야 하기 때문에 해커가 키에 접근해 데이터를 해독할 위험이 있다.
• 비대칭키 암호화(Asymmetric Encryption)
  • 한 쌍의 키와 개인키, 공용키를 사용한다.
  • 개인키는 비공개되어있고 개인키로 데이터를 해독할 수 있다.
  • 공용키는 공개되어있고 다른 사람과 공유할 수 있다. 공용키로 데이터를 암호화할 수 있다.
    

앞서, 대칭키의 문제점은 데이터를 암호화하는 데 사용된 키가 암호화된 데이터 네트워크를 통해 서버로 전송되기 때문에 해커가 키를 입수해 데이터를 해독할 위험이 있다는 점이다.

그래서 대칭키를 옮기기 위해 비대칭키 암호화를 사용한다. 서버에 공용과 개인 키 쌍을 생성하는 것이다.

1. openssl 명령어를 이용해 개인키와 공용키 쌍을 생성한다.
2. 사용자가 https를 이용해 웹서버에 처음 접근하면 서버에서 공개 키를 받는다. 해커가 모든 네트워크를 엿보고 있으니 해커도 개인키와 공용키의 사본을 받았다고 가정하자.
3. 그럼 사용자의 브라우저가 서버가 제공한 공용키를 이용해 대칭키를 암호화한다.
4. 그리고 사용자는 공용키로 암호화된 대칭키를 서버로 보낸다. 해커도 사본을 받는다.
5. 서버는 개인 키로 메시지를 해독하고 대칭키를 회수한다. 해커에겐 암호를 해독할 개인키가 없고, 공개키만 갖고 있기 때문에 메시지에서 대칭키를 되찾을 수 없다.
6. 이제 클라이언트와 서버는 대칭키로 데이터를 암호화해서 서로에게 보낼 수 있다. 상대방은 암호화된 데이터를 대칭키를 통해 해독할 수 있다.

하지만 해커가 서버인척 악의적으로 비슷한 서버를 만들 수도 있다.
따라서, 서버에서 나온 합법적인 키인지 확인이 필요하다.
서버가 키를 보낼 때 키 대신 키를 가진 인증서를 보낸다.

하지만 이런 인증서는 누구나 만들 수 있다.
그래서, 인증서를 생성했다면 직접 '서명'해야한다.
브라우저는 서버에서 받은 인증서가 합법적인지 유효성을 확인하고 고정된 인증서라면 우리에게 경고를 준다.

그러면 웹 브라우저가 신뢰할만한 합법적인 웹 서버 인증서는 어떻게 만들어질까?
그래서 CA(Certificate Authority)가 나선다.

CA는 우리를 위해 인증서에 서명하고 유효성을 확인해주는 잘 알려진 기관이다.

먼저, 생성한 키와 우리의 웹사이트 도메인 이름을 이용해서 CSR(Certificate Signing Request) 파일을 생성한다. (openssl 명령어 사용) CSR 파일은 인증서 서명 요청으로, CA로 보내져 서명을 받아야 한다. 인증서 관계자가 상세 사항을 확인하고 일단 확인되면 인증서에 서명해서 다시 보내준다.

해커도 같은 방법으로 인증서에 서명을 받으려 하면 인증서 유효성 검사 단계에서 실패할 것이다.
그가 호스팅하는 웹사이트엔 유효한 인증서가 없기 때문에 회사가 인증서를 거부할 것이기 때문이다.

그러면 합법적인 CA가 서명했다는 것을 어떻게 알 수 있을까?

CA들은 개인키와 공용키 쌍을 갖고 있다. CA가 인증서에 서명할 때 개인키를 사용한다. 모든 CA의 공개키는 브라우저에 기본으로 제공되기 때문에 브라우저는 CA의 공개키를 이용해 CA가 직접 서명한 인증서임을 확인한다. -> 일반적인 개인키-공용키와 반대로 공용키가 암호 해독에 사용된다.❗

요약해보자.
메시지를 암호화하려면 공용키와 개인키로 비대칭 암호화를 해야 한다.

서버는 먼저 CA에 CSR(인증서 서명 요청)을 보낸다. CA는 개인키로 CSR에 서명한다. 모든 사용자는 CA의 공용키를 갖고 있다.
서명된 인증서는 서버로 다시 보내진다. 서버는 서명된 인증서로 웹 응용 프로그램을 구성한다.
사용자가 웹 응용 프로그램에 접근할 때마다 서버는 먼저 인증서(공개키)를 보낸다.
사용자, 정확히는 사용자의 브라우저가 인증서를 읽고 서버의 공개 키를 유효성 검사하고 회수하기 위해 CA의 공용키를 사용한다.
그런 다음 대칭키를 생성해 모든 통신에 사용하려고 한다. 대칭키는 서버의 공개키로 암호화되어 서버로 전송된다.
서버는 개인키로 메시지를 해독하고 대칭키를 회수한다.
대칭키는 앞으로 통신을 위해 사용된다.

관리자가 SSH 보안 키 쌍을 생성한다. 웹 서버는 HTTPS로 웹사이트를 보호할 키 쌍을 생성한다. 인증서 기관은 자체 관리자를 생성해 인증서에 서명한다.
하지만 최종 사용자는 단일 대칭키만 생성한다.

클라이언트는 서버의 유효성을 확인할 수 있지만 서버는 클라이언트인지 확실히 알 수 없다.
클라이언트가 진짜인지 확인하기 위해 서버는 클라이언트에게 인증서를 요청할 수 있다.
그래서 클라이언트는 한 쌍의 키와 유효한 CA로부터 서명된 인증서를 생성해야 한다. 그리고 클라이언트는 인증서를 서버로 보낸다.

이 전체 인프라는 PKI(Public Key Infrastructure)라 알려져 있다.

마지막으로 한 가지만 확실히 해두자.
공개키와 개인키는 연관이 있거나 짝을 이루는 키이다. 데이터 암호화와 해독은 하나의 키로 할 수 없다.
따라서 데이터를 암호화할 때는 신중해야 한다. 개인 키로 데이터를 암호화하면 공개 키를 가진 사람이 누구든 암호를 풀고 메시지를 읽을 수 있다.

공용키가 있는 인증서는 보통 .crt나 .pem 확장자를 갖는다.
개인키는 보통 .key나 -key.pem 확장자를 갖는다. 즉, 단어나 확장자에 'key'가 들어가는 것은 개인키이다.