벌써 열번째 시나리오입니다.

기본 k8s는 평평한 네트워크 구조를 제공한다고 설명해줍니다. namespace는 기본적으로 네트워크 보안 제한을 주지 않으며, namespace 내부의 누군가는 다른 namespace로 접근할 수 있습니다. k8s가 cache를 좋아한다는데, 다른 namespace로의 권한을 획득해봅시다.
일단 시나리오 명령어를 쳐줬습니다.

이후에 뭘 해야될 지 잘 모르겠어서 kubectl이 있길래 한번 쳐줬는데

kubectl get jobs, svc도 해봤는데 안되고,
지금 사용중인 serviceaccount가 default로 되어있어서 클러스터 기능 대부분이 사용이 안되네요.
일단 네트워크 대역폭을 확인해보겠습니다.

namespace에 따라 네트워크 격리가 이뤄지지 않으므로, 다른 namespace에 있는 redis/cache에 접근해서 flag를 읽으면 될 듯합니다.
현재 Pod ip는 10.244.0.16이고 네트워크 대역이 10.244.0.0/24이므로 해당 주소를 스캐닝 해보면 됩니다.
zmap이 설치되어 있어서 zmap을 이용하겠습니다.
cache를 찾아야하므로 redis가 유력한데, redis의 기본 포트는 6379번이므로, 6379번이 열려있는지 포트스캐닝을 해보겠습니다

결과를 보니 다음과 같이 나왔습니다.

해당 주소로 redis 접속해보겠습니다.

KEYS *로 키 값을 찾아주고 flag값을 획득하겠습니다.

엄청 짧았지만 그래도 노트북에 새로 환경 구성하고 한건데 잘 돼서 다행이네요.
k8s의 namespace는 리소스를 논리적으로 나누는 것이지 네트워크를 경리하지 않는 것임을 배웠습니다.
API 권한이 없어도 네트워크 접근이 된다는게 조심해야하는 부분 같습니다.
읽어주셔서 감사합니다
'취약점분석 (Blue Team) > Cloud' 카테고리의 다른 글
| [k8s-goat] 12. DoS the Memory/CPU resources (0) | 2026.06.27 |
|---|---|
| [k8s-goat] 11. Gaining environment information (0) | 2026.06.27 |
| [k8s-goat] 9.Analyzing crypto miner container (0) | 2026.06.25 |
| [k8s-goat] 8. NodePort exposed services (0) | 2026.06.25 |
| [k8s-goat] 7. Attacking private registry (0) | 2026.06.25 |