Voyager of Linux

쿠버네티스를 사용하면서 가장 중요하지만 잘 모르는 부분이 config 내용이다. 이 내용에 대해서 알아보자.

kubeconfig

쿠버네티스를 설치하면 다음과 같은 파일이 설치된다.

이 파일은 이제 쿠버네티스에 설정을 담은 파일이다. 이 파일에는 쿠버네티스를 사용하기 위한 kube-apiserver 접속 주소와 인증 정보를 가지고 있다.

이 파일만 있으면 어떤 계정에서도 접속하는데 사용할 수 있다.

일반 계정에서 kubectl 사용하기

kubectl 명령어는 이 파일을 참조 하는데, 일반계정에서 사용하기 위해서는 다음과 같이 해주면 된다.

로그인 시에 자동으로 적용하기 위해서 .bashrc 파일에 다음과 같이 추가해준다.

쿠버네티스 정보 확인

쿠버네티스 정보를 확인하는 방법이라고 함은 설정 정보를 확인하는 것과 같다.

위 정보는 아주 간단한 내용을 담고 있는데, 노드(Node) 는 두개의 노드로 구성되며, 하나는 Control-plane 이고 하는 worker 노드다. 컨트롤 플레인의 주소는 https://192.168.96.120:6443 인데, 이것이 api-server 주소다.

보다 자세한 정보는 다음과 같이 확인이 가능하다.

출력되는 설정 정보는 $HOME/.kube/config 파일이 내용을 보여주고 있다. 이 파일의 주요한 내용은 Clusters, Users, Contexts 세가지 섹션으로 구성된다.

Clusters (어디로 갈 것인가?)

• 접속할 쿠버네티스 클러스터 API 서버의 IP 주소 및 도메인(URL) 정보입니다.
• 보안 통신을 위한 CA 인증서 데이터(certificate-authority-data)가 포함됩니다.
• name 은 클러스터 이름 입니다.

certificate-authority-data 는 브라우저에 Root CA 인증서와 같은 기능을 한다. 서버에 접속을 하는데, 공개키가 내장되어 있는 Root CA 인증서다. 브라우저는 자체적으로 전세계 Root CA 인증서를 내장하고 있지만 kubectl 는 명령어로 인증을 받아야 해서 인자로 Root CA 인증서를 가지고 있어야 한다.

이것은 base64 로 인코딩이 된 것이라서 다음과 같이 확인을 할 수 있다.

파일 내용을 확인해보면 흥미로운 점을 확인할 수 있다.

CN(Common Name) 이 kubernetes 이다. Issuer(발급자) 와 Subject(소유자) 가 모두 CN=kubernetes 로 일치한다. 이는 다음과 같은 의미다.

• 이는 이 인증서가 다른 상위 기관(예: DigiCert 등)에서 받아온 것이 아니라, “내가 내 신원을 보증한다”라고 선언하는 Self-Signed Certificate(자체 서명 인증서, 즉 Root CA 인증서)라는 것을 명확하게 증명합니다.
• 이 클러스터 시스템 안에서 모든 인증서 체인의 최상위 뿌리가 되는 이름이 바로 kubernetes로 정의된 것입니다.

SAN 의 DNS 가 kubernetes 인 것도 흥미롭다. 이것은 쿠버네티스 내부 시스템(특히 클러스터 내부 DNS) 과 마스터 노드가 통신할 때 사용하는 아주 특수한 ‘내부용 도메인 이름’ 이다. 다음과 같은 의미가 있다.

• 쿠버네티스 내부 통신용: 쿠버네티스 클러스터 내부의 파드(Pod)들이나 내부 컴포넌트들은 API 서버를 찾아갈 때 https://kubernetes 또는 https://cluster.local이라는 주소를 사용합니다.
• 인증 실패 방지: 만약 파드가 내부에서 https://kubernetes로 API 서버에 접속했는데, API 서버가 보여준 인증서에 이 이름(kubernetes)이 등록되어 있지 않다면 “주소가 일치하지 않는다”며 보안 에러가 납니다. 이를 방지하기 위해 SAN(Subject Alternative Name)에 DNS:kubernetes를 명시해 둔 것입니다.

실제로 클러스터를 처음 구성하면 내부 default 네임스페이스에 kubernetes라는 이름의 서비스(Service)가 자동으로 생성되며, 이것이 API 서버의 IP로 연결해 주는 이정표 역할을 한다. 실제로 default 네임스페이스에 service 를 보면 다음과 같이 되어 있다.

그렇다면 Pod -> Control Plane 과 통신할때에 https://kubernetes 로 호출해서 통신을 한다는 것인데, 그러면 Pod 도 RootCA 인증서를 가지고 있어야 한다. 그 Root CA 인증서는 kube config 에 있는 위 파일 내용이다. Pod 는 자동으로 이 인증서를 받는 것인가? 아니다.

쿠버네티스가 파드(Pod)를 생성할 때, 마스터 노드가 가지고 있는 Root CA 인증서를 파드 내부의 특정 경로에 자동으로 넣어준다(주입해 준다). 파드가 직접 어딘가에서 다운로드해 오는 것이 아니라, 쿠버네티스가 파드를 만들면서 미리 가방에 넣어 배송해 주는 방식이다. 다음과 같은 과정으로 이루어진다.

• 비밀의 열쇠: Service Account (서비스 어카운트)

쿠버네티스에서 실행되는 모든 파드는 기본적으로 ServiceAccount(서비스 계정)라는 신분증을 하나씩 할당받는다. 우리가 파드를 만들 때 특별히 지정하지 않으면, 자동으로 default라는 이름의 서비스 계정이 부여된다.

쿠버네티스는 파드를 띄울 때 이 서비스 계정과 연결된 인증 정보들을 파드 내부의 파일 시스템에 볼륨 마운트(Volume Mount) 형식으로 밀어 넣는다.

• 파드 내부의 어느 경로에 들어 가나?

파드 내부에 들어가 보면 아래의 고정된 경로에 인증서와 토큰이 항상 준비되어 있다:
경로: /var/run/secrets/kubernetes.io/serviceaccount/

이 디렉토리를 열어보면 정확히 3개의 파일이 들어있습니다:

1. ca.crt: 바로 이것이 우리가 앞서 보았던 그 Root CA 인증서!
2. token: 파드가 API 서버에 로그인할 때 쓸 일회용 암호문(JWT 토큰).
3.namespace: 이 파드가 속한 네임스페이스 이름이 적힌 텍스트.

• 실제 통신이 일어나는 전체 시나리오

파드 안에서 돌아가는 애플리케이션(예: 쿠버네티스 오픈소스 도구, 컨테이너 내부 스크립트 등)이 API 서버에 요청을 보낼 때의 과정이다.

1. 탐색: 애플리케이션이 https://kubernetes 주소로 요청을 보냄

2. 비교: API 서버가 자신의 신분증을 보여주면, 애플리케이션은 자동으로 파드 내부의 /var/run/secrets/kubernetes.io/serviceaccount/ca.crt 파일을 읽어와 서버의 신원을 검증합니다. (Root CA 인증서 획득 성공!)

3. 인증: 서버 검증이 끝나면, 파드는 같은 경로에 있는 token 파일을 꺼내 API 서버에게 던지며 “나 default 권한 가진 파드인데, 정보 좀 줘!” 하고 자신을 증명함.

토큰은 https 를 통해서 다음과 같이 자신의 신원을 증명하는데 쓰인다. 이것은 JWT 방식을 이용하는데, 이 JWT 는 비밀키로 암호화를 하게 된다. 이때 쓰이는 비밀키, 공개키가 있어야 하는데, 다음과 같은 디렉토리에 두개의 파일을 사용하게 된다.

즉 , JWT 토큰의 암복화는 쿠버네티스의 Service Account 의 비밀키, 공개키를 가지고 하게 되는데, 그 과정은 다음과 같다.

1. 토큰을 만들 때 (발급 과정)

쿠버네티스 마스터 노드(정확히는 kube-controller-manager)가 새로운 서비스 어카운트용 토큰을 구워낼 때, 쿠버네티스 서비스 어카운트 전용 비밀키(sa.key)를 사용해 토큰에 디지털 도장(서명)을 찍는다.

• 비밀키의 역할: “이 토큰은 정식 쿠버네티스 마스터가 발행한 진짜 토큰이다”라는 것을 증명하는 마스터 도장.
• 만약 이 비밀키가 없다면, 해커가 토큰을 마음대로 위조해서 “나 관리자 토큰인데?” 하고 클러스터를 해킹할 수 있기 때문에 반드시 이 키로 암호화 서명을 해야 한다.

2. 토큰을 쓸 때 (검증 과정)

파드가 이 토큰을 들고 API 서버(kube-apiserver)로 가서 “정보 좀 주세요”라고 요청하면, API 서버는 서비스 어카운트 공개키(sa.pub)를 꺼내 토큰의 도장을 확인한다.

• 공개키의 역할: 마스터가 찍은 도장이 진짜인지 가짜인지 검사하는 돋보기 역할을 한다.
• 도장이 진짜로 확인되면, API 서버는 비로소 파드의 신원을 믿고 요청을 승인한다.

이제 어떻게 동작하는지를 전체적으로 알게 되었다. 지금까지 논의는 파드 -> 컨트롤 플레인에 어떻게 데이터 통신을 하는지에 대한 것이다.

• https://kubernetes 로 연결 이때 Root CA 를 이용해 접속을 요청.
• 토큰을 이용해서 자격을 증명한다. 이는 http 헤더에 Authorization: Bearer eyJhbGci0i…. 형식으로 보내게 되는데, 이 토콘은 서비스 어카운트 비밀키로 암호화 된것이며 서버에서는 서비스 어카운트 공개키로 해독을 해서 판독한다.

JWT 안에는 다음과 같은 내용들이 들어 있다.

Users (누가 갈 것인가?)

• 클러스터에 인증(Authentication)할 사용자 정보와 자격 증명입니다.
• 클라이언트 인증서 키 데이터, 토큰(Token), 또는 ID/비밀번호 등이 들어있습니다.
• name 은 user 이름이다.

이 내용은 관리자가 박에서 PC 를 켜고 kubectl 명령어를 칠때 토큰 외에 또 하나의 강력한 인증수단 ‘클라이언트 인증서’를 사용한다.

name: kubernetes-admin 이라고 되어 있는데, 이것이 일종의 kubernetes 내에 계정이라고 보면된다. 그런데, 우리가 알고 있는 계정이라고 하면 계정을 가지고 있는 데이터베이스가 따로 있지만 쿠버네티스에서는 그러한 사용자를 관리하는 데이터베이스가 따로 없고 클라이언트 인증서에 사용자 계정 정보를 담게 된다.

Subject: O=kubeadm:cluster-admins, CN=kubernetes-admin 이것이 계정 정보다. 다음과 같은 의미를 가진다.

• CN(Common Name) = kubernetes-admin: 쿠버네티스가 인식하는 이 사용자의 진짜 계정 ID
• O(Organization) = kubeadm:cluster-admins: 이 사용자가 속한 그룹(Group) 이름입니다.
• 권한의 비밀: 쿠버네티스 안에는 “만약 어떤 유저가 kubeadm:cluster-admins 그룹 소속이라면, 클러스터 전체를 마음대로 제어하는 관리자 권한(cluster-admin)을 준다”라는 **RBAC 규칙(ClusterRoleBinding)**이 기본적으로 설치되어 있다. 이 글자 덕분에 전지전능한 최고 관리자 권한을 누릴 수 있는 것.

또, Issuer: CN=kubernetes 라고 되어 있는데, 그 의미는 다음과 같다.

• 이 인증서를 누가 도장 찍어 발급해 주었는지(Issuer)를 보니 **CN=kubernetes**
• 바로 이전 단계에서 우리가 분석했던 그 10년짜리 Root CA 인증서의 이름(Subject: CN=kubernetes)과 정확히 일치한다. 즉, 마스터 노드의 Root CA가 본인의 비밀키로 이 유저 신분증을 직접 서명해 준 정식 인증서라는 것을 뜻한다.

kubeadm:cluster-admins 그룹은 쿠버네티스에 클러스터 역할 바인딩(ClusterRoleBinding) 에 정의 되어 있다. 다음과 같이 확인할 수 있다.

그렇다면 cluster-admin 은 어떤 권한을 가지고 있을까? 다음과 같이 확인할 수 있다.

모든게 와일드 카드로 되어 있다. 모든 것을 할 수 있는 권한을 가지고 있어서 결국에는 관리자 권한을 가진것과 같다.

여기서 중요한게 Users 의 인증서는 클라이언트 인증서라는 것이다. 클라이언트 인증서는 서버의 RootCA 의 비밀키로 서명을 해준 인증서가 된다. 그리고 인증은 클라이언트가 서버를 서버가 클라이언트를 서로 인증하는 mTLS 방식이다.

Contexts (어떤 계정으로 어느 클러스터에 갈 것인가?)

• ‘Cluster’와 ‘User’를 하나로 묶어주는 연결 고리입니다.
• “나는 developer 계정(User)을 가지고 production-cluster(Cluster)에 접속하겠다”와 같은 맵핑 정보를 정의합니다.
• 특정 네임스페이스(Namespace)를 기본값으로 지정할 수도 있습니다.

이것은 일종의 프로필과 같다. AWS Configure 할때에 프로필을 만드는 것과 같다고 보면 된다. 앞서 설명한 Cluster, User 를 name을 붙여서 만들어 준다.

$HOME/.kube/config 파일에 대해서 알아 봤다. 이 파일을 잘 뜯아보면 쿠버네티스가 어떻게 동작하는지, 기초적인 인증에 대해서 다 알게 된다. 중요한 내용임에도 잘 모르는 사람들이 많아서 정리해봤다.