쿠버네티스 보안 강화: AdmissionConfiguration과 ImagePolicyWebhook 파헤치기 🛡️

안녕하세요! 쿠버네티스(Kubernetes)의 세계를 탐험 중인 여러분을 위해, 오늘은 클러스터의 보안과 안정성을 한 단계 끌어올릴 수 있는 강력한 두 가지 도구, AdmissionConfiguration과 ImagePolicyWebhook에 대해 쉽고 상세하게 설명해 드리겠습니다.

 

🚀 프롤로그: 왜 이런 게 필요할까요?

쿠버네티스 클러스터에서는 kubectl apply 같은 명령어로 정말 쉽게 애플리케이션을 배포할 수 있습니다. 정말 편리하죠! 하지만 여기서 한 가지 질문을 던져봐야 합니다.

"클러스터에 배포되는 컨테이너 이미지는 과연 모두 안전하고 신뢰할 수 있을까?" 🤔

 

만약 개발자가 실수로 검증되지 않은 외부 이미지를 사용하거나, 보안 취약점이 있는 :latest 태그 이미지를 배포한다면 어떻게 될까요? 바로 이런 문제를 사전에 차단하고, 우리 클러스터를 안전하게 지키는 문지기(Gatekeeper) 역할이 필요합니다. 오늘 소개할 기능들이 바로 그 역할을 수행합니다!

---

1. 문지기의 정체: 어드미션 컨트롤러(Admission Controller)란?

가장 먼저 이해해야 할 기본 개념은 어드미션 컨트롤러입니다. 이름 그대로 '입장(Admission)을 제어(Control)'하는 녀석이죠.

어드미션 컨트롤러는 쿠버네티스의 API 서버로 들어오는 모든 요청을 가로채서 추가적인 검증이나 변경 작업을 수행하는 플러그인입니다. 사용자가 파드(Pod)를 생성하거나 서비스를 업데이트하는 등의 모든 작업은 API 서버를 거치기 때문에, 이곳에 문지기를 두면 클러스터 내부로 들어오는 모든 것을 통제할 수 있습니다.

어드미션 컨트롤러는 크게 두 종류로 나뉩니다.

• ✍️ Mutating Admission Webhook (변경 웹훅): 들어온 요청을 수정하거나 변경합니다. 예를 들어, 특정 파드가 생성될 때 무조건 사이드카 컨테이너를 하나 추가하도록 만들 수 있습니다.
• ✅ Validating Admission Webhook (검증 웹훅): 들어온 요청을 검증하고 정책에 맞지 않으면 거부합니다. 예를 들어, 모든 파드는 반드시 owner 라벨을 포함해야 한다는 규칙을 만들 수 있죠.

오늘의 주인공인 ImagePolicyWebhook은 바로 이 Validating Admission Webhook의 한 종류입니다.

---

2. 문지기 설정 파일: AdmissionConfiguration 📜

그렇다면 이 똑똑한 문지기들(어드미션 컨트롤러)을 어떻게 설정하고 관리할까요? 바로 AdmissionConfiguration 파일이 그 역할을 합니다.

 

AdmissionConfiguration은 kube-apiserver가 어떤 어드미션 컨트롤 플러그인을, 어떤 순서로, 어떻게 사용할지를 정의하는 설정 파일입니다. 마치 클럽 문지기에게 "오늘은 이 명단에 있는 사람만 입장시켜!"라고 적어주는 지침서와 같습니다.

이 파일을 통해 우리는 기본 내장된 어드미션 컨트롤러 외에, 우리가 직접 만든 외부의 웹훅(Webhook)을 연결할 수 있습니다.

주요 구성 요소

아래는 AdmissionConfiguration 파일의 간단한 예시입니다.

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: ImagePolicyWebhook  # 사용할 어드미션 컨트롤러의 이름
    configuration:
      imagePolicy:
        kubeConfigFile: /path/to/webhook/kubeconfig.yaml # 웹훅 서버의 인증 정보
        allowTTL: 50 # 캐시 TTL (초)
        denyTTL: 50
        retryBackoff: 500 # 재시도 간격 (밀리초)
        defaultAllow: true # 웹훅 호출 실패 시 기본적으로 허용할지 여부

• plugins: 여기에 우리가 활성화할 어드미션 컨트롤러 목록을 정의합니다.
• name: 활성화할 플러그인의 이름을 지정합니다. 오늘의 주인공인 ImagePolicyWebhook이 보이네요.
• configuration: 해당 플러그인의 세부 설정을 정의하는 부분입니다. 웹훅 서버에 어떻게 연결할지에 대한 정보(kubeConfigFile) 등이 포함됩니다.

이 설정 파일을 kube-apiserver의 실행 인자(--admission-control-config-file)로 전달하면, API 서버는 이 파일을 읽고 지정된 웹훅을 클러스터의 '문지기'로 정식 임명하게 됩니다.

---

3. 이미지 전문가: ImagePolicyWebhook 👮‍♀️

이제 드디어 핵심인 ImagePolicyWebhook에 대해 알아볼 시간입니다!

이름에서 알 수 있듯이, 이 웹훅은 오직 컨테이너 이미지(Image)에 대한 정책을 검사하는 데 특화된 Validating Admission Webhook 입니다. 클러스터에 파드가 생성되거나 업데이트될 때, 해당 파드가 사용하려는 모든 컨테이너 이미지를 꼼꼼하게 심사하는 전문 경찰관과 같습니다.

ImagePolicyWebhook은 왜 강력할까요?

• 특정 레지스트리 강제: "우리 회사에서는 private-registry.mycorp.com에 있는 이미지만 사용할 수 있어!" 와 같이 허가된 레지스트리 사용을 강제하여 보안을 강화할 수 있습니다.
• :latest 태그 금지: 안정성을 위해 명시적인 버전 태그(예: nginx:1.21.6) 사용을 의무화하고, 예측 불가능한 :latest 태그 사용을 막을 수 있습니다.
• 이미지 서명 검증: Notary 같은 도구로 서명된 신뢰할 수 있는 이미지만 배포하도록 강제할 수 있습니다.

작동 방식 ⚙️

ImagePolicyWebhook의 작동 흐름은 다음과 같습니다.

1. 🧑‍💻 사용자 요청: 개발자가 이미지를 포함한 파드 생성 요청을 보냅니다. (kubectl apply -f my-pod.yaml)
2. ➡️ API 서버 접수: kube-apiserver가 이 요청을 받습니다.
3. 🤔 정책 확인: API 서버는 AdmissionConfiguration을 보고 "아, ImagePolicyWebhook을 호출해야겠군!"이라고 판단합니다.
4. 📞 웹훅 호출: API 서버는 검사가 필요한 이미지 정보를 ImageReview라는 객체에 담아 외부 웹훅 서버(우리가 직접 구현한 서버)로 HTTP POST 요청을 보냅니다.
5. 🧐 웹훅 서버의 심사: 웹훅 서버는 ImageReview 요청을 받고, 이미지 이름, 태그 등을 내부 정책과 비교하여 허용 여부를 결정합니다.
6. 👍/👎 결과 전송: 웹훅 서버는 심사 결과를 담아 API 서버에 응답합니다. ({"allowed": true} 또는 {"allowed": false, "reason": "오직 내부 레지스트리 이미지만 사용 가능합니다."})
7. ✅/❌ 최종 결정: API 서버는 웹훅의 응답을 보고 요청을 최종적으로 승인하거나, 사용자에게 오류 메시지와 함께 거부합니다.

---

🎬 결론: 안전한 클러스터를 위한 필수 관문

정리하자면, AdmissionConfiguration은 우리 클러스터의 문지기(어드미션 컨트롤러)들을 어떻게 배치하고 운영할지 알려주는 설정 지침서이고, ImagePolicyWebhook은 그중에서도 컨테이너 이미지만을 전문적으로 심사하여 클러스터의 보안을 책임지는 깐깐한 이미지 전문가입니다.

 

이 두 가지를 함께 사용하면, 단순히 애플리케이션을 배포하는 것을 넘어, "정해진 규칙과 정책에 따라 안전하고 신뢰할 수 있는 애플리케이션만 배포한다"는 강력한 보안 체계를 구축할 수 있습니다. 이는 안정적인 클러스터 운영과 DevSecOps 문화의 핵심적인 부분입니다.

 

이제 여러분의 클러스터에도 든든한 문지기를 세워보는 것은 어떨까요?

---

Kubernetes, AdmissionControl, ImagePolicyWebhook, Security, K8s, DevSecOps, Policy, 쿠버네티스, 보안