etcd 를 열자 비밀번호가 평문으로 굴러 나왔다

목표

클러스터의 유일한 진실 저장소인 etcd 를 직접 열어, Secret 이 평문으로 저장돼 있음을 눈으로 확인합니다.
그리고 RBAC 가 막아 주는 것은 apiserver 를 지나는 API 경로일 뿐, etcd 에 직접 붙으면 그 경계를
우회한다는 사실을 대비해 관찰합니다.

왜 중요한가

쿠버네티스의 모든 오브젝트는 결국 etcd 에 저장됩니다. Secret 의 data 값이 base64 로 보이니 마치
가려진 듯하지만, base64 는 인코딩이지 암호화가 아닙니다. 저장소 암호화(encryption at rest)를
켜지 않으면 etcd 에 닿을 수 있는 사람은 누구나 비밀번호 원문을 그대로 읽습니다.

한편 RBAC 는 강력하지만 그 통제는 apiserver 를 지나는 요청에만 적용됩니다. 노드나 etcd 데이터
디렉터리, 혹은 인증이 걸리지 않은 etcd 포트에 직접 접근하는 경로에는 RBAC 가 개입하지 못합니다.
그래서 etcd 자체를 TLS·상호인증·저장소 암호화로 별도로 지켜야 합니다. 이 실습은 "왜 그것들이
필요한가" 를 방어가 없을 때의 모습으로 먼저 보여 줍니다.

단계

1. 네임스페이스 kcsa-etcd 를 만듭니다.
2. Secret db-cred(password)와 ConfigMap app-cfg(mode)를 만듭니다.
3. 인증서 없이 etcd 엔드포인트에 붙어 상태를 파일로 남깁니다.
4. etcd 에서 Secret 을 직접 읽어 비밀번호 원문을 파일로 뽑습니다.
5. 그 값이 암호화가 아니라 평문임을 판정해 기록합니다.
6. ConfigMap 만 읽는 최소 권한 ServiceAccount 로 RBAC 경계를 확인합니다.
7. etcd 를 지키는 세 통제(client TLS·peer TLS·저장소 암호화)를 정리합니다.
8. 관찰 결과를 /root/kcsa-etcd/report.txt 에 장부로 남깁니다.

참고

• 이 실습의 etcd 는 학습용으로 TLS·인증이 없습니다. 운영 클러스터에서는 절대 이렇게 두면 안 됩니다.
• kubectl auth can-i ... --as=system:serviceaccount:<ns>:<sa> 로 RBAC 판정을 직접 확인할 수 있습니다.
• 공식 문서: [Secret](https://kubernetes.io/docs/concepts/configuration/secret/) ·

[저장 데이터 암호화](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) ·
[클러스터 컴포넌트](https://kubernetes.io/docs/concepts/overview/components/).

단계 8개

1. 관찰 대상 네임스페이스를 연다
2. 비밀번호 하나를 클러스터에 맡긴다
3. 인증서 없이 etcd 에 그대로 닿는다
4. 저장소 바닥에서 비밀번호를 줍는다
5. 이건 암호화가 아니라고 판정한다
6. RBAC 는 API 경로만 지킨다
7. etcd 를 지키는 세 가지를 적는다
8. 무엇을 관찰했는지 장부로 남긴다