Node - Control Plane Communication
컨트롤 플레인-노드 간 통신
쿠버네티스 공식 문서의 클러스터 아키텍처를 차례대로 읽어가며 정리한 내용입니다.
이번에는 컨트롤 플레인-노드 간 통신에 대해 알아봅니다.
쿠버네티스는 API 서버와 쿠버네티스 클러스터 사이에 대한 통신 경로를 제공한다.
- 이는 사용자가 신뢰할 수 없는 네트워크 또는 클라우드 공급자의 완전한 퍼블릭 IP에서 클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다.
이전 글에서 Node의 개념과 관리에 대해 살펴보았습니다.
이번 글에선 컨트롤 플레인과 노드 사이의 통신 경로가 어떻게 구성되고 보호되는지 정확히 살펴보도록 하겠습니다.
쿠버네티스 클러스터에서 통신은 양방향으로 이루어집니다.
노드에서 컨트롤 플레인으로 가는 방향과, 컨트롤 플레인에서 노드로 가는 방향이 있으며, 각각 다른 보안 메커니즘과 통신 패턴을 사용합니다.
노드에서 컨트롤 플레인으로의 통신
쿠버네티스는 "허브 앤 스포크(hub-and-spoke)" API 패턴을 가지고 있다.
- 노드(또는 노드에서 실행되는 파드들)의 모든 API 사용은 API 서버에서 종료된다.
- 다른 컨트롤 플레인 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다.
- API 서버는 하나 이상의 클라이언트 인증 형식이 활성화된 보안 HTTPS 포트(일반적으로 443)에서 원격 연결을 수신하도록 구성된다.
허브 앤 스포크hub-and-spoke 패턴은 쿠버네티스 아키텍처의 핵심이라고 합니다. 모든 통신이 중앙의 API 서버를 거쳐가도록 설계되어 있어, 보안 정책을 일관되게 적용할 수 있고 중앙 집중식 관리가 가능합니다.
노드의 API 서버 연결
노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록 클러스터에 대한 공개 루트 인증서root certificate로 프로비전되어야 한다고 합니다.
프로비전provisioning: 리소스를 사용 가능한 상태로 준비하고 제공하는 과정.
여기서는 노드가 API 서버와 안전하게 통신할 수 있도록 필요한 인증서와 설정을 미리 준비하여 제공하는 것을 의미합니다.
프로비전에 대해서, 전에 작성한 글을 첨부합니다: https://wiki.leetekwoo.com/docs/docker/%08vagrant-provision
- 클라이언트 인증서client certificate 형식으로
kubelet의 클라이언트 자격 증명을 사용하는 것이 권장됩니다. kubelet클라이언트 인증서의 자동 프로비저닝은 kubelet TLS 부트스트랩을 참고하면 됩니다.
파드의 API 서버 연결
API 서버에 연결하려는 파드는 서비스 어카운트Service Account를 활용하여 안전하게 연결할 수 있습니다.
쿠버네티스는 다음을 자동으로 수행합니다:
- 공개 루트 인증서root certificate를 파드에 자동으로 주입
- 유효한 베어러 토큰bearer token을 파드가 인스턴스화될 때 자동으로 주입
참고로 kubernetes 서비스(default 네임스페이스)는 API 서버의 HTTPS 엔드포인트로 리디렉션되는 가상 IP 주소(kube-proxy를 통해)로 구성되어 있습니다.
컨트롤 플레인 컴포넌트 역시 보안 포트를 통해 클러스터 API 서버와 통신합니다.
결과적으로, 노드 및 노드에서 실행되는 파드에서 컨트롤 플레인으로 연결하기 위한 기본 작동 모드는 기본적으로 보호되며 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행될 수 있습니다.
컨트롤 플레인에서 노드로의 통신
컨트롤 플레인(API 서버)에서 노드로는 두 가지 기본 통신 경로가 있다.
- API 서버에서 클러스터의 각 노드에서 실행되는 kubelet 프로세스
- API 서버의 프록시 기능을 통해 API 서버에서 모든 노드, 파드 또는 서비스에 이르는 것
노드에서 컨트롤 플레인으로의 통신이 기본적으로 안전한 것과 달리, 컨트롤 플레인에서 노드로의 통신은 추가적인 보안 설정이 필요합니다.
API 서버에서 kubelet으로의 통신
API 서버에서 kubelet으로의 연결은 다음의 용도로 사용됩니다:
- 파드에 대한 로그를 가져온다
- 실행 중인 파드에 (보통의 경우
kubectl을 통해) 연결한다 kubelet의 포트-포워딩 기능을 제공한다
이러한 연결은 kubelet의 HTTPS 엔드포인트에서 종료됩니다.
문제는, 기본적으로 API 서버는 kubelet의 제공serving 인증서를 확인하지 않는다는 것입니다.
주의:
이는 연결이 중간자 공격man-in-the-middle에 시달리게 하며, 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 안전하지 않다.
보안 강화 방법
이 연결을 확인하려면, --kubelet-certificate-authority 플래그를 사용하여 API 서버에 kubelet의 제공serving 인증서를 확인하는데 사용할 루트 인증서 번들을 제공해야 합니다.
# API 서버에 kubelet 인증서 검증 플래그 설정
--kubelet-certificate-authority=/path/to/ca-bundle.crt
이것이 가능하지 않은 경우, 신뢰할 수 없는 네트워크 또는 공용 네트워크를 통한 연결을 피하기 위해 필요한 경우, API 서버와 kubelet 간 SSH 터널링을 사용할 수 있습니다.
마지막으로, kubelet API를 보호하려면 Kubelet 인증 및/또는 인가를 활성화해야 합니다.
API 서버에서 노드, 파드 및 서비스로의 통신
API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로 일반 HTTP 연결로 연결되므로 인증되거나 암호화되지 않습니다.
URL에 https: 접두어를 붙여 보안 HTTPS 연결이 되도록 실행할 수 있지만, 다음과 같은 한계가 있습니다:
- HTTPS 엔드포인트가 제공한 인증서의 유효성을 검증하지 않음
- 클라이언트 자격 증명도 제공하지 않음
결과적으로 연결이 암호화되는 동안 그 어떤 무결성도 보장되지 않습니다. 이러한 연결은 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 현재는 안전하지 않습니다.
SSH 터널
쿠버네티스는 SSH 터널을 지원하여 컨트롤 플레인에서 노드로의 통신 경로를 보호합니다.
SSH 터널 구성에서:
- API 서버는 클러스터의 각 노드에 SSH 터널을 시작
- 포트 22에서 수신 대기하는 ssh 서버에 연결
- 터널을 통해
kubelet, 노드, 파드 또는 서비스로 향하는 모든 트래픽을 전달 - 이 터널은 노드가 실행 중인 네트워크의 외부로 트래픽이 노출되지 않도록 함
참고:
SSH 터널은 현재 더 이상 사용되지 않으므로, 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안 된다.
Konnectivity 서비스가 SSH 통신 채널을 대체한다.
SSH 터널이 deprecated 된 것은 보안과 성능 측면에서 더 나은 대안이 등장했기 때문입니다. Konnectivity 서비스가 그 대안입니다.
Konnectivity 서비스
기능 상태: Kubernetes v1.18 [beta]
Konnectivity 서비스는 컨트롤 플레인과 클러스터 간 통신에 TCP 레벨 프록시를 제공한다.
SSH 터널을 대체하는 Konnectivity 서비스는 두 부분으로 구성됩니다:
- Konnectivity 서버 - 컨트롤 플레인 네트워크에 위치
- Konnectivity 에이전트 - 노드 네트워크에 위치
동작 방식
- Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작
- 네트워크 연결을 유지
- Konnectivity 서비스를 활성화한 후, 모든 컨트롤 플레인에서 노드로의 트래픽은 이 연결을 통과
Konnectivity 서비스 태스크를 따라 클러스터에서 Konnectivity 서비스를 설정할 수 있습니다.
이 방식의 장점은 다음과 같습니다:
- 에이전트가 연결을 시작하므로, 노드가 방화벽 뒤에 있어도 작동
- TCP 레벨에서 동작하여 더 안정적이고 효율적
- SSH 터널보다 더 나은 보안성과 관리 용이성 제공