kubernetes CKA study (15) - Configure Secrets in Applications, Multi Container Pods
kubernetes CKA study
Configure Secrets in Applications
ConfigMap은 일반 텍스트 형식으로 구성 데이터를 저장하기 때문에 암호를 저장하기에는 부적절하다. 암호를 저장하기 위해 Secret이 사용된다.
Secret은 비밀번호 등 민감한 정보를 저장하는 데 사용된다.
인코딩된 형식으로 저장된다는 점만 빼면 ConfigMap과 비슷하다.
Secret 역시 두 가지 방법으로 만들 수 있다.
먼저 명령적인 방법은 '--from-literal'옵션을 통해 키 값 쌍을 지정할 수 있다.
비밀이 너무 많으면 '--from-file' 옵션을 이용해 파일로 키 값 쌍을 한번에 지정할 수 있다.
다음으로 선언적인 방법에서는 시크릿 정의 파일을 먼저 작성하고 kubectl apply -f 명령어를 통해 시크릿을 생성한다.
여기서 주의할 점은 데이터를 인코딩된 포맷으로 저장해야 한다는 것이다.
일반 형식에서 인코딩 된 형식으로 데이터를 변환하기 위해 다음과 같은 명령어를 실행하면 된다.
Secret을 확인하기 위해 다음 명령어들을 사용할 수 있다.
Secret의 데이터를 확인하기 위해서는 kubectl get secret 시크릿명 -o yaml 명령어를 사용하면 된다.
인코딩된 값을 해독하기 위해서 '--decode' 옵션을 사용하면 된다.
파드의 env로 시크릿을 사용할 수 있다. 파드 정의 파일에 환경 변수를 삽입하려면 envFrom이라는 필드를 사용하면 된다.
파드에 시크릿을 주입하는 다른 방법도 있다.
단일 환경 변수로 넣을 수 있고 볼륨으로 넣을 수도 있다.
파드의 볼륨으로 시크릿을 사용할 경우, 시크릿의 각각의 특성은 파일로 생성된다.
파일에는 암호 값이 담겨 있다.
이 경우에는 3개의 암호가 3개의 파일에 담겨 있다.
Secret을 다룰 때는 주의할 점이 있다.
우선, Secret은 암호화되어 있지 않다. 그래서 누구든 Secret 정의 파일을 볼 수 있고 Secret 개체를 얻을 수 있다. 그리고 기밀 데이터를 볼 수 있다.
따라서 주의해야 하며 RBAC(Role Based Access Control, 역할 기반 접근 제어)나 제 3자의 암호 공급자를 고려하는 것이 좋다.
A note about Secrets
Secret은 base64 형식으로 데이터를 인코딩한다. base64로 인코딩된 암호를 가진 사람은 누구나 암호를 디코딩할 수 있다. 따라서 Secret은 그다지 안전하지 않은 것으로 간주될 수 있다.
Secret은 암호 및 기타 중요한 데이터가 실수로 노출될 위험이 줄어들기 때문에 일반 텍스트로 저장하는 것보다 안전하다.
'Secret 정의 파일을 소스 코드 레포지토리에 올리지 않는다', 'ETCD에 암호화되어 저장되도록 ETCD에 저장될 때 Secret에 대한 암호화를 가능하게 한다' 등의 관행은 Secret이 더욱 안전하도록 만들어 준다.
또한 쿠버네티스는 Secret을 안전하게 처리하기 위해
-
Secret은 해당 노드의 파드에 필요한 경우에만 노드로 전송된다.
-
kubelet은 Secret이 디스크 저장소에 기록되지 않도록 Secret을 tmpfs에 저장한다.
-
Secret에 의존하는 Pod가 삭제되면 kubelet은 Secret 데이터의 로컬 복사본도 삭제한다.
그러나 Helm Secrets, HashiCorp Valut와 같은 도구를 사용하는 것과 같이 Kubernetes의 비밀번호와 같은 민감한 데이터를 처리하는 다른 더 좋은 방법이 있다.
envFrom 속성은 container 의 name 속성이 선언되고 선언되야 한다.
테스트 통과 완료
Multi Container Pods
각각 다른 기능을 대상으로 하기 때문에 각각의 컨테이너로 따로 개발하고 배포하길 원한다.
그래서 같은 수명 주기(함께 생성되고 함께 파괴된다)를 공유하는 다중 컨테이너 파드가 있는 것이다.
같은 네트워크 공간을 공유하기 때문에 서로를 localhost라고 부를 수 있다.
또한 같은 Storage Volume에도 접근할 수 있다.
이렇게 하면 파드 사이에 통신을 위해 볼륨 공유나 서비스를 설정하지 않아도 된다.
멀티 컨테이너 파드를 생성하기 위해서는 새 컨테이너 정보를 파드 정의 파일에 추가하면 된다.
테스트 통과 완료
init Containers
멀티 컨테이너 파드에서 각각의 컨테이너는 파드의 라이프 사이클을 따른다.
반면에, 하나의 프로세스를 수행하고 완료되는 컨테이너가 필요할 때도 있다.
예를 들어, 코드를 레포지토리에서 받아오는 프로세스가 있다. 이러한 작업은 파드가 생성되었을 때 한번만 수행되어야 한다. 또는 실제 애플리케이션이 실행되기 전에 서비스나 데이터가 실행될 때까지 기다리는 작업이 대표적인 예시이다.
이러한 경우 initContainer를 사용하면 된다.
initContainer는 파드 정의 파일에서 다른 컨테이너들과 비슷한 형태로 initContainer 영역에 정의된다.
파드가 처음 실행되면 initContainer가 실행되고 initContainer의 작업은 실제 컨테이너의 작업이 실행되기 전에 완료된다.
initContainer도 여러 개를 정의할 수 있다. 주의해야 할 점은 멀티 컨테이너와 달리, multi init container는 한번에 하나씩 순차적으로 실행된다.
만약 initContainer 중 일부가 실패하면 쿠버네티스는 모든 init Container들이 성공적으로 완료될 때까지 반복적으로 파드를 재시작한다.
initContainer는 아래와 같이 정의 된다.
테스트 통과 완료
