오늘은 k8s Resource Manifests에 대해 알아보겠습니다.
저번 시나리오를 할 때

해당 구조에서 API서버를 거쳐서 pod이 생성되고, 설정되는 걸 확인했었습니다.
또 악분님 깃허브에서

이런 yaml형태의 웹훅을 다운로드 받아서 api서버로 보냈었습니다.
이렇게 구체적인 설정 정보를 manifest file이라고 합니다.

이런걸 저희가 받았을 때, 혹은 작성하는 법을 알면 도움이 될 것 같습니다.

가장 기본 구성은 4가지로 되어있습니다.
① apiVersion : 어떤 api 버전을 쓸지 (보통 v1)
② kind : 생성할 리소스의 종류 (Pod, Deployment 등등)
③ metadata : 리소스의 부가 정보, name, namespace, labels 등
④ spec : 오프젝트의 상태, 예를 들어 Pod이라면 어떤 컨테이너를 실행할지, deployment라면 pod을 몇 개 유지할지, Service라면 어떤 pod으로 트래픽을 보낼지
예시입니다
pod을 생성하는 manifest입니다
metadata에 namespace는 default, labels에 app:nginx가 눈에 띕니다
deployment를 생성하는 manifest입니다.
metadata까지는 쉬운데, spec부분에 좀 많습니다.
replicas는 pod을 항상 3개 유지하라는 뜻입니다.
selector는 어떤 Pod를 관리 대상으로 볼지 정하는 부분이고, app: nginx 라벨이 붙은 Pod을 관리한다는 뜻입니다.
templete는 실제로 생성할 Pod에 관한 정보가 들어있으며 여기에 있는 부분은 Pod생성과 구조가 동일합니다/
Service는 Pod에 접근할 수 있는 고정된 네트워크 주소를 만들어주는 리소스입니다.
여기서 type:ClusterIP는 클러스터 내부에서만 접근 가능한 서비스를 만든다는 뜻입니다.
클러스터 안의 다른 Pod이 nginx-service:80으로 접근할 수 있게 해줍니다.
targetPort는 실제 Pod 컨테이너로 전달할 port입니다.
아까 4번이 spec이었는데 spec대신에 data를 사용하는 manifests도 있습니다.
ConfigMap은 애플리케이션 설정값을 저장하는 리소스입니다.
Ingress는 외부 HTTP/HTTPS 요청을 내부 Service로 연결해주는 리소스입니다.
nginx.local/로 들어온 요청을 nginx-service의 80번 포트로 전달한다는 뜻입니다.
Ingress는 Manifest외에 클러스터에 Ingress Controller가 있어야 합니다.
일단 간단하게만 manifests에 대해 살펴봤습니다.
다음 포스팅부터는 kubernetes-goat에 대해 살펴볼 예정입니다.
읽어주셔서 감사합니다
'취약점분석 (Blue Team) > Cloud' 카테고리의 다른 글
| [k8s-goat] 3.SSRF in the Kubernetes (K8S) world (0) | 2026.06.23 |
|---|---|
| [k8s-goat] 1.Sensitive keys in codebases (0) | 2026.06.23 |
| [Cloud] Kubernetes 보안 실습 시나리오 2 ( Mutating Admission Webhook ) (0) | 2026.06.17 |
| [Cloud] OWASP Kubernetes Top 10 (0) | 2026.06.17 |
| [Cloud] Kubernetes 보안 실습 시나리오 1 ( RCE후 Pod 생성 ) (1) | 2026.06.16 |