Kubernetes 시크릿 볼륨 대 변수
추천할 만한 사용법이 있나요? 환경 변수로 또는 볼륨 마운트를 사용하여 노출될 수 있습니다. 둘 중 하나가 다른 것보다 더 안전합니까?
https://www.oreilly.com/library/view/velocity-conference-2017/9781491985335/video316233.html
환경 변수에 의해 노출된 쿠버네티스 비밀은 /proc/를 통해 호스트에서 열거될 수 있다. 이 경우 볼륨 마운트를 통해 로드하는 것이 더 안전할 수 있습니다.
저는 TMC의 답변에 동의하지만, "하지만 12가지 요소는 어떨까요??". 12F는 ENV 변수로 구성을 저장해야 하는 것처럼 보이기 때문에 볼륨 장착 비밀 사용에 대한 반대 의견이 제기되기도 한다. 첫째, 이것들은 자발적이고 마일리지가 다양한 모범 사례 제안입니다. 둘째, 다음과 같은 섹션이 있습니다.
12요인 앱에서 envars는 세분화된 컨트롤로, 각각은 다른 envars와 완전히 직교한다. 이들은 "환경"으로 그룹화되지 않고 각 배포에 대해 독립적으로 관리됩니다. 이것은 앱이 수명 동안 자연스럽게 더 많은 배포로 확장됨에 따라 부드럽게 확장되는 모델입니다.
출처:
기본적으로, 나머지 설명과 함께, 나는 12F Config 관리의 지침 원칙이 다음과 같다는 것을 이해한다.
- 구성을 원본에서 벗어나게 함
- 소스 아티팩트(예: 도커 컨테이너)에 구성을 주입할 수 있습니다.
- 필요한 구성 값 집합을 세밀하게 변경할 수 있습니다.
제 겸손한 의견으로는, 볼륨 마운티드 쿠버네티스 시크릿은 당신이 어떤 종류의 시크릿 오브젝트를 만들고 그것들을 어떻게 관리하느냐에 따라 이러한 목표를 달성합니다.
탑재된 비밀이 자동으로 업데이트됨
볼륨에서 이미 사용 중인 비밀이 업데이트되면 결국 예상 키도 업데이트됩니다. 큐블릿은 매 주기적인 동기화마다 마운트된 비밀이 새로운지 확인하고 있다. 그러나 현재 Secret 값을 가져오기 위해 로컬 캐시를 사용하고 있습니다.
다중 컨테이너 포드에서, 포드 내부의 각 컨테이너는 컨테이너 내에서 볼 수 있도록 해당 볼륨의 비밀 볼륨을 요청해야 합니다. 이를 사용하여 포드 수준에서 유용한 보안 파티션을 구성할 수 있습니다.
위에 볼륨 마운트별 공식 문서 비밀이 더 나은 옵션으로 보입니다.
나는 안전성에 어떤 차이도 없다고 생각한다. 노드가 손상되면 비밀을 볼 수 있기 때문입니다.
예:
---
apiVersion: v1
kind: Secret
metadata:
name: mount
type: Opaque
data:
foo: ""
---
apiVersion: v1
kind: Secret
metadata:
name: env
type: Opaque
data:
BAR: "BAR"
---
apiVersion: v1
kind: Pod
metadata:
name: mount
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
envFrom:
- secretRef:
name: env
volumeMounts:
- name: mount
mountPath: "/opt/mount"
readOnly: true
volumes:
- name: mount
secret:
secretName: mount
$ kubectl exec mount -- ls -la /opt/mount
total 0
drwxrwxrwt 3 root root 100 Jan 8 03:00 .
drwxr-xr-x 1 root root 19 Jan 8 03:00 ..
drwxr-xr-x 2 root root 60 Jan 8 03:00 ..2020_01_08_03_00_13.066710719
lrwxrwxrwx 1 root root 31 Jan 8 03:00 ..data -> ..2020_01_08_03_00_13.066710719
lrwxrwxrwx 1 root root 10 Jan 8 03:00 foo -> ..data/foo
$ kubectl exec mount -- env | grep BAR
BAR=
$ docker ps | grep mount
8dbde26864a4 nginx "nginx -g 'daemon of…" 8 minutes ago Up 8 minutes k8s_nginx_mount_default_3438a94b-e4af-41a7-8d85-7668fcbd9928_0
$ docker inspect 8dbde26864a4 | grep -A 1 '"Env"'
"Env": [
"BAR=",
$ docker inspect 8dbde26864a4 | grep '"Source"' | grep mount
"Source": "/var/lib/kubelet/pods/3438a94b-e4af-41a7-8d85-7668fcbd9928/volumes/kubernetes.io~secret/mount"
$ ls -la /var/lib/kubelet/pods/3438a94b-e4af-41a7-8d85-7668fcbd9928/volumes/kubernetes.io~secret/mount
合計 0
drwxrwxrwt 3 root root 100 1月 8 12:00 .
drwxr-xr-x 4 root root 46 1月 8 12:00 ..
drwxr-xr-x 2 root root 60 1月 8 12:00 ..2020_01_08_03_00_13.066710719
lrwxrwxrwx 1 root root 31 1月 8 12:00 ..data -> ..2020_01_08_03_00_13.066710719
lrwxrwxrwx 1 root root 10 1月 8 12:00 foo -> ..data/foo
그리고 당신은 비밀스러운 디자인 제안을 볼 수 있다.
그것은 이렇게 쓰여 있다.
노드가 손상된 경우 잠재적으로 노출될 수 있는 유일한 비밀은 노드에 예약된 컨테이너에 속하는 비밀이어야 합니다.
그래서 나는 그 비밀이 노드가 손상되었을 때 컨테이너의 비밀을 보호한다는 보장이 되지 않는다고 생각한다.
저도 같은 질문을 받고 환경 변수 대 볼륨에 대한 최종적인 답을 찾고 있습니다. 나는 아무것도 찾을 수 없다. 쿠브렌테스 문서에는 위에서 언급한 것 외에는 이 또한 다루지 않으며, 그것조차도 약간 부족하다. 여기서 논의된 몇 가지 사항을 다루면서 저는 제 의견을 가지고 있습니다. 꼭 맞는 것은 아니지만, 제가 추측할 수 있었던 것입니다. 만약 내가 무언가를 오해하고 있다면 나는 수정을 환영한다. 제 이해는 다음과 같습니다.
- 환경 변수와 볼륨/파일 간에 보안상의 차이가 없는 것처럼 포드에 로그인하기만 하면 두 가지 모두에 쉽게 액세스할 수 있습니다.
- WRT 12 요소 앱들, 동의합니다. 저는 차이가 없다고 생각합니다. 두 경우 모두 파일이든 환경 변수로든 상관없이 정보의 원천인 비밀 사양의 일부입니다. 코드와 구성을 완전히 분리해야 하는 경우 비밀 사양(및 기타 사양)을 별도의 보고서에 넣을 수 있습니다.
- 비밀은 그렇지 않으면 안전하지 않다. 같은 다른 옵션에서 언급했듯이.
책에 따르면, 어떤 면에서 에 저장된 비밀은 에 있는 것보다 더 안전하다.
...환경 변수에 기밀을 주입하는 것은 구성 맵을 주입하는 것과 다르지 않습니다. 하지만 쿠버네티스가 이런 식으로 비밀을 폭로하는 것을 허용한다고 해도, 그것은 보안 위험을 초래할 수 있기 때문에 최선의 생각이 아닐 수 있다. 응용프로그램은 일반적으로 오류 보고서에 환경 변수를 출력하거나 시작 시 응용프로그램 로그에 기록하기도 하는데, 환경 변수에 정보를 주입하면 실수로 기밀이 노출될 수 있습니다. 또한 하위 프로세스는 상위 프로세스에서 모든 환경 변수를 상속합니다. 따라서 응용프로그램이 타사 하위 프로세스를 호출하면 비밀이 어떻게 되는지 알 수 없습니다.
