CKA-14일차

📍 CKA 14일차
📍 Udemy-Certified Kubernetes Administrator (CKA) with Practice Tests 163-173

---

164. Solution - Cluster Roles and Role Bindings

clusterroles와 clusterrolebindings 개수 세기

clusterroles는 cluster wide(클러스터 전체) 범위에 해당하기 때문에 namespace를 갖지 않는다.

주의할 점!

kubectl get clusterrolebinding 명령어는 할당된 user에 대한 정보를 알려주지 않는다.
user에 대한 정보를 알기 위해서는 kubectl describe 명령어를 사용해야 한다.

명령적인 방법을 사용해서 clusterrole과 clusterrolebinding 개체를 생성할 수 있다.

---

165. Service Accounts

Service Account의 개념은 쿠버네티스의 다른 보안 관련 개념과 연결되어 있다.

쿠버네티스 계정에는 두 가지 유형이 있다.
사용자 계정은 사람이 사용하고 서비스 계정은 컴퓨터가 사용한다.

사용자 계정의 예시) 관리 작업을 수행하기 위해 클러스터에 접근하는 Admin이 될 수 있고 응용 프로그램 배포 등을 위해 개발자가 클러스터에 접근하는 Developer가 있다.

서비스 계정의 예시) 프로메테우스 같은 모니터링 어플리케이션을 통해 쿠버네티스 API의 성능을 뽑아내는 Prometheus, 젠킨스 같은 자동화된 빌드 툴을 이용해 쿠버네티스 클러스터에 응용 프로그램을 배포하는 Jenkins

응용 프로그램이 쿠버네티스 API를 쿼리하려면 인증이 되어야 한다. 그래서 서비스 계정을 사용한다.
서비스 계정을 생성하고 조회하는 명령어는 다음과 같다.
서비스 계정이 생성되면 토큰도 자동으로 생성된다. 서비스 계정 토큰은 쿠버네티스 API에 인증하는 동안 외부 앱이 반드시 사용해야 하는 것이다.

자동으로 생성된 토큰은 Secret 객체로 저장된다. Service Account가 생성되면 먼저 Service Account개체를 생성하고 그 다음 Service Account를 위한 토큰을 생성한다. 그런 다음 Secret을 만들어 그 안에 토큰을 저장한다.

쿠버네티스 API에 대한 인증이 필요한 타사 응용 프로그램의 경우, 타사 응용 프로그램을 호스팅하는 파드 내부에 Service Account의 Secret 토큰을 볼륨으로 자동 마운트함으로써 해결할 수 있다.

쿠버네티스의 모든 네임스페이스에는 default라고 명명된 Service Account가 자동으로 생성된다.
따라서, 각 네임스페이스에는 자동으로 생성된 default Service Account가 있고 파드가 생성될 때마다 default Service Account과 토큰이 자동으로 해당 파드로 볼륨 마운트된다.

파드 정의 파일을 확인해보면 어떠한 Secret이나 볼륨 마운트를 명시하지 않았다.
하지만 kubectl describe 명령어로 파드의 상세 사항을 살펴보면 default-token이라는 Secret으로부터 볼륨이 자동으로 생성되었음을 확인할 수 있다. 그리고 default-token Secret은 Service Account를 위한 토큰을 포함하는 Secret이다.

default-token Secret의 위치가 '/var/run/secrets/kubernetes.io/serviceaccount'인 것을 확인할 수 있다. 파드 내부에서 ls 명령을 실행해서 해당 디렉토리에 존재하는 3개의 파일로 마운트된 secret을 확인할 수 있다. 실제 토큰 정보를 가지고 있는 것은 token이라는 파일이다. 해당 파일 내용을 보면 kubernetes API 접근에 사용되는 토큰을 확인할 수 있다.

default Service Account는 기본 쿠버네티스 API 쿼리를 실행하는 권한만 갖도록 제한된다.
다른 Service Account를 사용하고 싶다면 파드 정의 파일을 수정해서 serviceAccountName 필드가 새로운 Service Account의 이름을 참조하도록 해야한다.

기존 파드의 Service Account는 수정할 수 없기 때문에 파드를 삭제하고 다시 만들어야 한다.
하지만 deployment의 경우, 파드 정의 파일에 변화가 생기면 자동으로 deployment를 위해 rollout하기 때문에 새로운 Service Account으로 새 파드를 삭제하고 재생성한다.

쿠버네티스에서 아무것도 명시하지 않으면 자동으로 default Service Account를 마운트한다는 것을 명심해라!!

automountServiceAccountToken 필드를 false로 설정하면 Service Account를 자동으로 마운트하지 않는다.

릴리즈버전 1.22, 1.24에서 Service Account와 관련해 변경된 사항들을 확인해보자!

모든 네임스페이스에는 default Service Account이 있고 그 Service Account에는 관련된 token이 있는 Secret이 있다. 파드가 생성되면 자동으로 Service Account와 파드를 연결하고 파드 내 잘 알려진 위치로 토큰을 마운트한다.
이 경우엔 'var/run/secrets/kubernetes.io/serviceaccount'이다.

토큰을 jwt 웹사이트에서 해독해볼 수 있다.

해독해봤듯이 토큰에 만료일자가 없다. 그래서 서비스 계정이 존재하는 한 토큰은 유효하다.
더구나 각 JWT는 서비스 당 개별 Secret 개체를 요구한다. 그 결과 확장성 문제가 발생한다.
버전1.22에서 TokenRequestAPI는 쿠버네티스 개선 제안서1205의 일부로 API를 통해 더 안전하고 확장성 있게 쿠버네티스 서비스 계정 토큰을 프로비저닝하는 메커니즘을 도입했다.
TokenRequestAPI에서 생성된 토큰은 Audience Bound, Time Bound, Object Bound로 인해 더 안전하다.

버전 1.22 이후로 새로운 파드가 생성되면 더 이상 Service Account의 Secret token에 의존하지 않는다.
대신 TokenRequestAPI를 통해 정해진 만료일자를 가진 토큰이 생성되고 파드에 volume으로 탑재된다.

버전 1.24에서는 더 이상 자동으로 Secret이나 Secret Token이 생성되지 않도록 변경되었다.
따라서, kubectl create 명령어로 필요한 토큰을 생성해야 한다. 이때, 서비스 계정 이름을 입력해 필요한 서비스 계정을 위한 토큰을 생성하도록 해야 한다.

생성한 토큰을 해독해보면 시간 'exp' 만료 날짜가 정의되어 있다. 시간 제한을 명시하지 않았다면 보통 1시간으로 제한한다. 명령에 추가 옵션을 전달해 토큰의 만료 기간을 늘릴 수도 있다.

버전 1.24에서 옛날 방식으로 Secret token을 이용한 service account를 만들고 싶다면 Secret 정의 파일을 통해 만들 수 있다. kind 필드를 'kubernetes.io/service-account-token'으로 지정해야 한다. 그리고 metadata 영역에 kubernetes.io/service-account.name 필드에 service account의 이름을 명시해야 한다.
서비스 계정을 먼저 생성하고 그 다음에 Secret을 생성하기 때문에 secret 개체가 특정 service account와 연결되는 것이다.
그래서 service-account-token 타입으로 secret을 만들면 service account와 관련된 secret 개체에 만료되지 않는 토큰을 생성할 것이다.

공식 문서에 명시된 Service account token Secrets에 대한 내용은 다음과 같다.

---

166. Practice Test Service Accounts

pod에 service account를 변경하는 방법 2가지

---

167. Image Security

파드 정의 파일에서 컨테이너 이미지 이름은 Docker의 이미지 명명 규칙을 따른 것이다.
nginx는 이미지 혹은 저장소 이름이다.
이미지 이름의 앞 부분은 사용자 또는 계정 이름이다. 그래서 사용자나 계정 이름을 제공하지 않으면 library라고 인식한다. library는 docker의 공식 이미지가 저장된는 기본 계정의 이름이다.

사용자 이름의 앞 부분은 레지스트리 이름이다. 레지스트리 이름이 지정되지 않았다면 Docker의 기본값 레지스트리인 Docker Hub로 추정된다.
Docker Hub의 DNS 이름은 docker.io이다.

레지스트리는 모든 이미지를 저장하는 곳이다.
새 이미지를 생성하거나 이미지를 업데이트할 때마다 레지스트리에 푸시(push)하면 누군가 이 응용 프로그램을 배포할 때마다 레지스트리에서 끌어온다(pull).

Docker hub 이 외에도 구글의 gcr 등 유명한 레지스트리들이 많다.

일반인에게 공개되어서는 안되는 응용 프로그램이 있을 경우 private registry를 사용하면 된다.
private registry에 접근하기 위해서는 자격 증명이 필요하다.

파드 정의 파일에서 개인 레지스트리에 있는 이미지를 사용할 수 있다.
이런 경우, 개인 레지스트리에 접근하기 위한 자격 증명을 포함하는 Secret 개체를 생성하고 파드 정의 파일에서 imagePullSecrets 필드로 Secret 개체를 참조하게 함으로써 인증과정을 해결할 수 있다.

---

169. Solution - Image Security

kubectl create secret docker-registry 명령어를 사용하여 private registry에 대한 secret을 생성할 수 있다. 잘 모르겠다면 '-h' 옵션을 사용하자!

imagePullSecret을 pod 정의 파일에 명시하기

---

170. Pre-requisite - Security in Docker

docker에 설치된 호스트에는 다수의 운영 체제 프로세스나 deamon, ssh 서버 등으로 실행되는 프로세스의 집합을 가지고 있다. 가상머신과 달리 컨테이너는 호스트로부터 완전히 격리되어 있지 않다. 그래서 컨테이너와 호스트가 같은 커널을 공유한다.
컨테이너는 리눅스에서 namespace를 이용해 격리된다. 컨테이너에 의해 실행되는 모든 프로세스는 호스트 자체에서 실행되지만 고유의 네임스페이스에서 실행된다.

고유의 네임스페이스에 있어 고유의 프로세스만 볼 수 있다. 바깥이나 다른 네임스페이스에서는 볼 수 없다.

sleep 3600 명령어를 수행하는 docker conatainer 내에서 ps aux 명령어로 docker contaner 내의 프로세스를 나열하면 PID 1로 sleep 3600 프로세스를 볼 수 있다.

호스트에서 ps aux 명령어로 호스트 내의 프로세스를 나열하면 sleep 3600를 실행 중인 다른 PID를 확인할 수 있다.
이는 프로세스가 다른 네임스페이스에서 다른 PID를 가질 수 있기 때문이다. 이것이 docker가 시스템 내에서 컨테이너를 격리하는 방식이다.

docker 호스트는 루트 유저 한 명과 다수의 비루트 유저로 이루어진 사용자 집합을 갖고 있다.
기본값으로 docker는 루트 사용자로서 컨테이너 내의 프로세스를 실행한다. 컨테이너 안과 밖의 모든 프로세스는 루트 사용자로 실행된다.

컨테이너 내의 프로세스가 루트 사용자로 실행되길 원하지 않는다면 docker run 명령 안에서 '--user' 옵션을 사용해 사용자를 설정하고 새 사용자 ID를 명시하면 된다. 명시된 USER ID로 프로세스가 실행되는 것을 확인할 수 있다.

사용자 보안을 실행하는 또 다른 방법은 Dockerfile에서 USER를 지정하는 것이다.

docker는 컨테이너 내 루트 사용자의 능력을 제한하는 보안 기능을 제공한다.
컨테이너 안의 루트 사용자는 호스트의 루트 사용자와는 다르다.
docker는 이것을 구현하기 위해 리눅스 기능을 사용한다.

루트 사용자는 시스템에서 가장 강력한 사용자이다. 루트 사용자는 뭐든 할 수 있고 루트 사용자에 의한 프로세스도 마찬가지로 시스템의 제한 없이 접근할 수 있다. '/usr/include/linux/capability.h'에서 루트 사용자가 할 수 있는 기능의 리스트를 확인할 수 있다.

기본값으로 docker는 컨테이너의 기능을 제한한다.
호스트를 재부팅하거나 같은 호스트에서 실행되는 호스트나 다른 컨테이너를 방해할 수 없다.
이 동작을 재정의하고 추가적인 특권을 제공하고 싶다면 docker run 명령에 '--cap-add [추가할 권한]' 옵션을 추가하면 된다.
드롭 특권을 사용하고 싶다면 '--cap-drop [제거할 권한]' 옵션을 사용하면 된다.
모든 권한이 활성화된 컨테이너를 실행하고 싶다면 '--previleged' 옵션을 사용하면 된다.

---

171. Security Contexts

지난 강의에서 봤듯이 docker 컨테이너를 실행할 때 보안 표준 집합을 정의할 옵션이 있다.

쿠버네티스에서도 설정할 수 있다.
쿠버네티스에서는 컨테이너를 파드에 넣어 보관한다. 그래서 컨테이너 수준이나 파드 수준에서 보안 설정을 선택할 수 있다.
파드 수준으로 설정하면 파드 내 모든 컨테이너에 설정값이 전달된다.

파드 정의 파일에서 securityContext 영역을 통해 파드 수준의 보안 설정을 할 수 있다.
runAsUser 필드으로 파드 사용자 ID를 설정한다.

컨테이너 수준에서 보안을 설정하려면 containers 영역에 securityContext 영역을 추가하면 된다.
그리고 capabilities 영역에 추가할 기능 목록을 명시하면 된다. capabilities 영역은 컨테이너 수준에서만 지정 가능하다!

---

173. Solution - Security Contexts

파드 수준에서 보안 설정을 해야하지 않나...? 왜 컨테이너 수준에서 보안 설정을 하는 거지...?😟

그리고 왜 파드 수준에서 설정하면 edit되지 않을까???

파드 실행자를 지정한 것이기 때문에 파드의 실행자를 변경하기 위해서는 파드를 삭제하고 재생성해야 한다.

파드 레벨과 컨테이너 레벨 보안 설정 예시