쿠버네티스 API 개념 및 보안 내용 정리

<주제 선정 이유>

 

 처음엔 개인적으로 DEVOPS 환경이 필요하기도 했고 앞으로도 쓸 생각에 젠킨스와 깃랩, SVN을 활용한 CI/CD환경을 구축하려고 했었습니다. 다만 일주일 간 블로그나 책을 보면서 구축하고 있었는데 자꾸 어디선가 에러가 나서 고치면 다른 부분이 에러가 나오는 ?? 생각보다 일이 커져서 이대로 가다간 기간에 맞출 수 없을 거 같아 갑작스럽게 주제를 [API의 개념과 보안] 으로 정하게 되었습니다. 

 중간 과제 때 대시보드를 구축하면서 보안에 대해 잘 몰라서 삽질도 많이 했기도 하고 이 기회에 조금 더 자세히 공부한 내용을 작성했습니다.

 

---

 

kube-apiserver

- 파드나 네임스페이스, 컨피그맵 그리고 이벤트 질의 및 조작 

- 이름은 거창하지만 그냥 쿠버네티스 오브젝트와의 연결을 위한 API서버이다.

 

# kubectl이 봅는 api서버 주소 확인  

 

#https를 사용하기에 별도의 인증이 필요 -> 프록시 사용을 통해 서버와 통신 가능 

 

 

#프록시 서버를 사용하면 로컬에서 인증을 관리하고 이를 api로 보내기에 토큰전달 필요x 

 리소스 타입과 버전 확인 가능 

 

#프록시란?

- proxy = 대신 , 대리 

- 보안상 문제를 방지하기 위해 직접 통신하지 않고 중계자를 거쳐서 통신

- 프록시를 한 번 거치는 것을 통해서 중요 데이터의 유출을 방지 

 

---

 

#파드 내에서 api 서버 통신 

- ubuntu 파드를 하나 생성 후 api서버의 주소와 포트 확인하기

apiVersion: v1
kind: Pod
metadata:
  name: curl
spec:
  containers:
  - name: main
    image: ubuntu
    command: ["sleep", "9999999"]

 

#curl 설치 후 동작 확인 

 

# token 파일의 내용을 Authorization HTTP 헤더에 Bearer토큰에 해당 내용을 넣어서 전달하면 인증이 가능

- 파드에 마운트된 서비스 어카운트 token을 통해 api server와 파드가 통신 

 

 

 

---

API SERVER에서 인증이란?

- API서버가 요청을 받으면 누가 요청을 받았는지 확인 후 허가를 해줌

- 인증 플러그인을 통해서 수행 

 

서비스 어카운트란? 

- 파드 내부에서 실행되는 애플리케이션 API서버에 자신을 인증하는 방법 중 하나 

- 파드에서 실행되는 프로세스를 위한 권한 

- 리소스 종류 중 하나이며 각 네임스페이스 마다 default 서비스 어카운트가 자동 생성됨 -> 그 동안 사용했던 서비스 어카운트 

- 여러 파드가 같은 서비스 어카운트를 사용 가능 

 

** 파드에 서로 다른 서비스 어카운트를 할당함으로서 리소스 제어가 가능 **

 

---

# service account 생성 

- 토큰과 시크릿이 연계됨을 확인 

 

#sa를 kikai로 쓰는 파드 생성 

apiVersion: v1
kind: Pod
metadata:
  name: curl-custom-sa
spec:
  serviceAccountName: kikai
  containers:
  - name: main
    image: ubuntu
    command: ["sleep", "9999999"]
  - name: ambassador
    image: luksa/kubectl-proxy:1.6.2

#kikai 서비스 어카운트에서 마운트 되었는지 확인

 

# 위의 컨테이너에 마운트 된 토큰과 kikai 서비스 어카운트 토큰이 동일함을 확인 

 

# kikai 서비스 어카운트로 api서버와 통신 확인 

 

** 사용자가 만든 서비스 어카운트로도 api서버에 접근해서 사용이 가능 **

 

 

---

RBAC 인가 플러그인

- 사용자가 액션 (GET , CREATE, UPDATE 등등)을 사용할 수 있는지 여부를 결정하는 요소

- USER ROLE 사용 

- 사용자에게 여러 개의 ROLE이 있는 경우 허용하는 범위내의 작업이 가능 

 

리소스

- 롤 : 수행할 작업을 정의 WHAT

- 바인딩 : 누가 수행할지  WHO

 

# 간단히 롤 바인딩을 통해 검정색 사람들을 지정하고 롤을 통해 사과는 먹을 수 있고 피자는 먹을 수 없다 라는 식으로 역할을 정해서 관리함

 

역할 부여를 위해 네임스페이스 생성 및 kubectl-proxy 기반 컨테이너 실행 

 

 

 

#kikai라는 네임스페이스에 있는 컨테이너에서 API연결 시 default 서비스 어카운트를 사용했기 때문에 kikai라는 네임스페이스 내용이 확인 불가 

 

** 서비스 어카운트 기본 권한으로 리소스 나열 및 수정 불가 **

 

# 롤 정의 

- kikai 네임스페이스에 생성되는 role 

- 각 네임스페이스에 맞도록 설정 후 배포 

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: kikai
  name: service-reader
rules:
- apiGroups: [""]
  verbs: ["get", "list"]
  resources: ["services"]

 

 

# 서비스 어카운트에 롤 바인딩 

kubectl create rolebinding test --role=service-reader --serviceaccount=kikai:default -n kikai

- role은 service-reader 참조 

- kikai ns에 있는 default 서비스 어카운트 바인딩 

- 네임스페이스 kikai의 파드가 실행중인 서비스 어카운트에 바인딩 했기 때문에 권한 인증을 통해 파드내에 서비스 나열 및 수정 가능 

 

# 롤 바인딩에서 다른 네임스페이스의 서비스 어카운트 추가 

- kikai를 darbo로 변경 

\

 

# darbo 네임스페이스에 있는 test 컨테이너에서 api서버 요청 

- kikai 네임스페이스 서비스는 권한 수정을 통해 열람 및 수정 가능 

- darbo 네임스페이스 경우 권한이 없어서 응답 불가 

 

 

 

클러스터 롤과 클러스터 바인딩 

- 클러스터 수준의 RBAC  리소스 

- 다른 네임스페이스의 리소스 접근시 롤마다 위와 같은 작업을 해야하니까 매우 귀찮.. -> 클러스터 롤을 통해 클러스터 수준으로 범위를 확장시켜 개별 네임스페이스에 바인딩하여 공통적인 롤로 사용할 수 있게 변경 가능 

 

# 클러스터 롤 생성 

 

# 권한 확인

- default 서비스 어카운트로 나열 불가  

 

#클러스터 롤 바인딩 

kubectl create clusterrolebinding pv-test --clusterrole=pv-reader --serviceaccount=kikai:default

 

 # 클러스터롤 바인딩 전 

 

 

# 클러스터 롤 바인딩을 통해 파드의 서비스 어카운트에 바인딩

kubectl create clusterrolebinding view-test --clusterrole=view --serviceaccount=kikai:default

 

 

#kikai 네임스페이스 쪽 파드 나열 

# darbo 네임스페이스 쪽 파드 나열 

# 모든 네임스페이스의 파드 나열 

 

 

kikai 네임스페이스의 default sa는 클러스터 롤 바인딩을 통해 모든 네임스페이스의 파드를 볼 수가 있음

 

---

<후기> 

 

KNAS 스터디를 통해서 시야가 더 넓어졌음을 체감했습니다.

스터디에 참여한 여러 분들의 역량과 스터디를 이끌어 가시는 가시다님의 설명을 들으면서 얼마나 우물 안의 개구리였는지 깨달을 수 있는 기간이 아니었나 싶습니다. 그저 개념만 슥슥 익혔던 저는 이 스터디를 통해 쿠버네티스를 공부하는 방법과 네트워크에 대해 조금 더 자세하게 알 수 있는 기회가 되었습니다.

다른 분들에 비해 많이 부족해서 발표나 도움을 할 수 없어서 아쉬웠지만 다음엔 다른 사람에게 도움이 될 수 있는 사람이 되는 걸 목표로 열심히 해보겠습니다!

---

< 참고 자료 >

 

https://coffeewhale.com/apiserver

쿠버네티스 API서버는 정말 그냥 API서버라구욧

https://iforint.tistory.com/145

Proxy 프록시란?

https://kubernetes.io/ko/docs/reference/access-authn-authz/_print/

API 접근 제어

https://kubernetes.io/ko/docs/reference/access-authn-authz/service-accounts-admin/

서비스 어카운트 관리하기

 

http://www.yes24.com/Product/Goods/89607047

쿠버네티스 인 액션 - YES24