[Kubernetes Best Practice] 4. 설정, 시크릿, RBAC

이 글은 Kubernetes Best Practice를 읽고 개인적으로 중요하다고 생각하는 부분과 잘 모르는 부분에 대해 공부한 내용을 작성한 글입니다. 모든 내용은 책에 포함되어 있는 내용을 기반으로 작성하였으며 자세한 내용이 궁금하신 분들은 책을 구매해서 읽는 것을 권장드립니다. 

최근 서비스 메시에 대해 알아보거나 쿠버네티스를 사용하고 공부하면서 가장 많이 들었던 생각은 이 방법이 최선인가? 라는 생각이었습니다. 이에 대한 궁금증을 해결하는데 도움이 될만한 책을 발견해서 읽어보고자 합니다.

---

ConfigMap & Secret

컨테이너의 높은 이식성을 뒷받침하는 특성은 애플리케이션과 환경의 분리 즉, 런타임에 설정 데이터를 환경 변수나 볼륨 마운트를 통해 주입할 수 있다는 점입니다. 쿠버네티스는 이를 달성하기 위한 리소스로 ConfigMap과 Secret을 제공합니다. ConfigMap과 Secret이 수행하는 역할은 동일하지만 중요한 차이점은 Pod이 정보를 저장하는 방식과 데이터 etcd에 저장되는 방식입니다.

Secret은 base64 방식으로 인코딩되어 표현됩니다. 하지만 암호화가 아닌 인코딩이기 때문에 Pod에 주입된 순간 일반 텍스트 형태로 보여지게 됩니다. (ConfigMap과 동일하게 암호화를 지원하지 않는다면 왜 Secret을 사용하는 것일까?라는 궁금증이 생겼는데 조대협님의 글을 참고하면 SSL 인증서와 같은 바이너리 파일의 경우에는 문자열로 저장이 불가능 하기 때문에 인코딩하여 저장할 수 있도록 지원하기 위함이라고 합니다.)

Secret이 지원하는 타입으로는 일반 파일이나 문자열 상수로 생성되는 generic 과 docker registry 인증에 필요한 신원인 docker-registry, public/private key로 생성되는 TLS Secret이 존재합니다. 이러한 방식으로 정의된 Secret은 이를 사용하는 Pod가 떠있는 Node의 tmpfs에 마운트되고 Pod이 종료되면 해당 Secret은 삭제됩니다. 하지만 etcd에는 평문으로 저장되기 때문에 보안을 위해서는 etcd 노드간 mTLS 및 데이터 저장 시 암호화를 하는 방법 등의 별도의 방안이나 Hasicorp Valut와 같은 KMS Solution을 고려해야 합니다. 

---

ConfigMap & Secret 변경

ConfigMap 및 Secret을 주입하는 방법은 환경변수를 사용하는 방법과 볼륨 마운트를 사용하는 방법이 존재합니다. 두 방법은 설정이 변경되었을 때 동작하는 방식에 있어 차이점이 존재합니다.

Volume Mount
먼저 볼륨으로 마운트 하는 방식입니다. ConfigMap/Secret의 속성 이름은 마운트 된 볼륨의 파일명이 되고, 값은 파일 내용이 됩니다. 이 방법은 설정이 변경 됐을 때 새로운 버전의 Pod을 다시 배포하지 않아도 변경을 감지하고 업데이트됩니다. 문서를 살펴보면 kubelet을 통해 동기화 작업이 수행되는 것을 알 수 있습니다.(물론 어플리케이션에서의 재시작이 필요할수도 있습니다.)  

이 방법으로 Pod이 배포되기 전에 동일한 네임스페이스 안에 ConfigMap/Secret이 존재하지 않을 경우 기본값은 Pod이 실행되지 않지만 `Optional` 필드를 사용하여 존재하지 않더라도 Pod이 시작되도록 할 수 있습니다.

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "env" ]
      env: 
        - name: OPTIONAL_ENV
          valueFrom:
            configMapKeyRef:
              name: test-cm
              key: optional.key 
              optional: true 

Admission Controller를 사용해서 특정 설정데이터가 존재하지 않는 경우 배포를 막을 수도 있습니다.
(Admission Controller란 Kubernetes API를 호출했을 때 해당 요청의 내용을 변경하거나 검증하는 플러그인의 집합으로 Istio의 Envoy Proxy Injection, ResourceQuota 등이 존재합니다. Admission Controller에 대한 자세한 내용은 공식 문서나 alice_k106님의 블로그에서 확인하실 수 있습니다.).
만약 Admission Controller를 정의하는 것이 제한된다면 LifeCycle Hook을 통해 ConfigMap/Secret의 배포 여부를 확인하는 방법도 존재합니다.

Environment Variable
다음은 환경 변수로 설정하는 방법입니다. envFrom을 통해 ConfigMap/Secret 내 모든 값들을 환경변수로 설정할 수 있고 configMapKeyRef / secretKeyRef를 통해 개별적으로 설정도 가능합니다. 개별적으로 설정하는 방법은 ConfigMap/Secret이 배포되지 않은 경우 Pod의 시작이 불가능합니다. 하지만 envFrom을 사용하는 경우에는 부적합한 값에 대해 InvalidVariableName이라는 이벤트가 발생하고 해당 값을 건너뛴 채로 Pod이 시작됩니다. 

이 방법의 경우 볼륨 마운트와는 다르게 ConfigMap/Secret을 업데이트 하는 경우 Pod 안에 값은 업데이트 되지 않습니다. 따라서 Pod의 삭제 후 재시작이나 Deployment의 업데이트를 통해 재시작하는 전략이 필요합니다. 책에서 추천하는 방법은 ConfigMap/Secret의 이름과 deployment에서 참조하고 있는 ConfigMap을 변경함으로써 자동으로 Deployment가 업데이트 되도록 설정하는 방법입니다.

---

 

리소스 접근 제한 전략

쿠버네티스에서 리소스에 대한 접근 제한을 위한 프로세스는 다음과 같습니다.

User Account, Service Account를 통해 인증된 사용자를 관리 - 인증
RBAC를 통해 인증된 사용자에게 여러 API에 대한 권한을 부여 - 인가

---

RBAC

RBAC란 규칙 기반 접근 제어를 의미합니다. 간단히 말하면 대상에 허용할 규칙을 정의함으로써 접근 권한을 제어하는 방법입니다. RBAC에 대한 자세한 설명은 따로 다루지는 않겠습니다. 내용이 궁금하신 분들은 공식 문서에서 확인하실 수 있습니다.

RBAC를 적용하면 주의해야할 점은 다음과 같습니다.

• Kubernetes API에 접근하고자 하는 상황이 발생한다면 새로운 Service Account를 만들고 최소한의 권한만을 가지는 Role을 생성하는 것이 좋습니다.
• CI/CD Tool을 사용할 떄에는 이를 위한 서비스 계정을 사용해서 오브젝트의 배포 및 삭제에 대한 감시해야 합니다.

이외에도 몇가지 권장 사항이 존재하지만 현재는 이해할 수 없는 부분이여서 이해되는 부분만 작성하였습니다.