시스템 취약점 진단: 로컬 vs AKS 클러스터, 어디서 수행해야 할까?
보안팀에서 시스템 취약점 진단을 수행하려고 할 때, 가장 먼저 부딪히는 질문이 있습니다.
“로컬에서 스캔해야 하나요, 아니면 운영 중인 AKS 클러스터 내부에서 수행해야 하나요?”
결론부터 말씀드리면, 보안팀의 시스템 진단 목적이라면 AKS 클러스터(Cloud) 환경에서 수행하는 것이 정답입니다. 이 글에서는 그 이유와 구체적인 수행 방법을 정리합니다.
1. 로컬 vs 클라우드: 목적에 따른 선택
| 구분 | 로컬 (Local / CI) | 클라우드 (AKS Cluster) |
|---|---|---|
| 주체 | 개발자 (Developer) | 보안팀 (Security Team) |
| 목적 | 배포 전 차단 (Prevention) | 운영 상태 진단 (Diagnosis) |
| 대상 | 컨테이너 이미지 (정적 파일) | 실행 중인 팟(Pod) + 노드(Node) + 설정(Config) |
| 시점 | 빌드/배포 단계 (Shift-Left) | 런타임 (Runtime) |
왜 보안팀은 AKS 내부에서 진단해야 할까?
- 실행 중인 실체(Reality) 확인: 이미지 빌드 시점과 실제 실행 시점 사이에는 차이가 발생할 수 있습니다 (e.g.,
latest태그 사용, 동적 설정 주입). 클러스터 내부에서 진단해야 현재 서비스되고 있는 정확한 버전을 알 수 있습니다. - 인프라 설정(Misconfiguration) 진단: Trivy는 단순 이미지 취약점뿐만 아니라, 쿠버네티스 설정 결함(RBAC 권한 과다, Privileged 컨테이너 여부 등)도 진단합니다. 이는 로컬 이미지 파일만으로는 알 수 없습니다.
- 지속적인 모니터링: 취약점은 매일 새로 발견됩니다. 배포 당시에는 안전했던 이미지라도, 일주일 뒤에는 위험한 이미지가 될 수 있습니다. 운영 환경에서 주기적으로 스캔해야 ‘현재의 위험’을 파악할 수 있습니다.
2. AKS 환경에서 Trivy로 진단하는 방법
AKS 환경에서 Trivy를 사용하는 방법은 크게 두 가지가 있습니다.
방법 A: Trivy K8s CLI (Ad-hoc 진단)
보안 담당자가 필요할 때마다 명령어를 실행하여 현재 상태를 점검하는 방식입니다. 별도의 설치 없이 로컬 머신에서 kubectl 권한만 있으면 바로 실행 가능합니다.
1
2
3
4
5
# 전체 클러스터 스캔 및 리포트 생성
trivy k8s --report summary cluster
# 특정 네임스페이스의 취약점 상세 확인
trivy k8s -n prod --report all all
- 장점: 설치 불필요, 즉시 실행 가능.
- 단점: 주기적인 자동화가 어렵고, 지속적인 모니터링이 아님.
방법 B: Trivy Operator (권장)
클러스터 내부에 Trivy Operator를 설치하여 실시간으로 취약점을 모니터링하는 방식입니다. 보안팀에게 가장 권장되는 방식입니다.
- 새로운 파드가 생성될 때마다 자동으로 스캔합니다.
- 결과를 쿠버네티스 리소스(CRD)로 저장하므로, 대시보드(Prometheus/Grafana)와 연동하기 쉽습니다.
설치 방법 (Helm)
1
2
3
4
5
6
7
8
9
10
# Helm 리포지토리 추가
helm repo add aqua https://aquasecurity.github.io/helm-charts
helm repo update
# Trivy Operator 설치 (trivy-system 네임스페이스)
helm install trivy-operator aqua/trivy-operator \
--namespace trivy-system \
--create-namespace \
--set="trivy.ignoreUnfixed=true" \
--version 0.24.1
진단 결과 확인
설치 후에는 자동으로 클러스터 내부의 리소스들을 스캔하고 리포트를 생성합니다.
1
2
# 생성된 취약점 리포트 확인
kubectl get vulnerabilityreports -n prod
3. 요약: 보안팀의 Action Item
- 단발성 점검: 지금 당장 현황 파악이 필요하다면
trivy k8s명령어를 사용하세요. - 상시 모니터링 체계 구축: Trivy Operator를 운영 클러스터(AKS)에 설치하세요. 이것이 시스템 취약점 진단의 자동화된 기반이 됩니다.
- 보고서 작성: Operator가 생성한 CRD 데이터나 CLI 결과를 바탕으로 정기 보안 보고서를 작성하세요.
4. [Q&A] 클라우드 인증과 AI 활용
Q1. 클라우드 환경에서 API 키(비밀번호) 관리는 어떻게 하나요?
과거에는 docker login을 위해 ID/Password를 쿠버네티스 Secret으로 만들어 사용했습니다. 하지만 이는 보안상 매우 취약합니다(키 유출 위험, 주기적 교체 번거로움).
AKS 환경에서는 Workload Identity(워크로드 아이덴티티) 사용이 표준입니다.
- 기존 방식 (Legacy):
ImagePullSecrets에 레지스트리 아이디/비번을 하드코딩. - 권장 방식 (Modern): Workload Identity를 사용.
- Trivy 파드(ServiceAccount)에 “ACR Pull” 권한이 있는 Azure Managed Identity를 매핑합니다.
- 장점: 별도의 비밀번호(API Key)를 관리할 필요가 전혀 없습니다(Passwordless).
1
2
3
4
5
6
7
# ServiceAccount 예시 (Azure Identity와 매핑됨)
apiVersion: v1
kind: ServiceAccount
metadata:
name: trivy-sa
annotations:
azure.workload.identity/client-id: "YOUR_CLIENT_ID"
Q2. AI를 활용할 수 있나요?
네, 매우 적극적으로 활용할 수 있으며 최근 트렌드이기도 합니다. Trivy가 찾아낸 수백 개의 취약점 중에서 “진짜 위험한 것”을 선별하는 데 AI가 탁월한 성능을 발휘합니다.
활용 시나리오
- False Positive 제거: “이 취약점은 리눅스 커널 모듈에 대한 것인데, 우리 컨테이너는 해당 모듈을 사용하지 않으므로 무시해도 됨”과 같은 판단을 AI에게 맡길 수 있습니다.
- 보안 조치 가이드: 단순히 “CVE-2023-1234 있음”이라고 알려주는 대신, AI가 “현재 사용 중인
nginx:1.19버전을1.21로 올리면 해결됩니다.”라고 구체적인 해결책을 제시해줄 수 있습니다.
추천 도구: K8sGPT
K8sGPT는 쿠버네티스 클러스터의 문제를 진단하고 AI(OpenAI 등)로 분석해주는 도구입니다. Trivy와 연동하면, Trivy가 찾은 취약점을 AI가 분석하여 “알기 쉬운 문장”으로 설명해줍니다.
1
2
# K8sGPT로 Trivy 결과 분석 예시
k8sgpt analyze --filter VulnerabilityReport --explain
결과 예시 (AI 출력):
“치명적인 취약점(Critical)이
frontend파드에서 발견되었습니다.openssl라이브러리 버전이 낮아 원격 코드 실행(RCE) 위험이 있습니다. 즉시 이미지를v2.0이상으로 업데이트하는 것을 권장합니다.”
5. ISMS 인증 심사 시나리오: AKS 기술영역 진단
ISMS 인증 심사에서 기술적 취약점 진단(기술영역)은 필수 항목입니다. AKS 환경에서는 기존 서버 진단과는 다른 접근이 필요합니다. 아래는 심사 대응을 위한 실전 시나리오입니다.
5.1. 진단 범위 정의
ISMS 기술영역 진단 시, AKS 환경은 4가지 레이어로 분리하여 접근해야 합니다.
| 레이어 | 진단 대상 | 진단 도구 | ISMS 관련 항목 |
|---|---|---|---|
| ① 컨테이너 이미지 | OS/라이브러리 CVE | Trivy (image scan) | 2.10.1 보안 패치 관리 |
| ② 쿠버네티스 설정 | RBAC, NetworkPolicy, PodSecurity | Trivy (config scan), kube-bench | 2.6.1 접근권한 관리 |
| ③ 클러스터 인프라 | AKS 노드, API Server 설정 | kube-bench (CIS Benchmark) | 2.9.1 시스템 보안 |
| ④ 워크로드 런타임 | 실행 중 이상행위, 권한 상승 | Falco | 2.11.1 사고 예방 및 대응 |
5.2. 심사 대응 시나리오 (Step-by-Step)
1
2
3
4
5
6
7
8
9
10
11
12
13
[1단계: 사전 준비] ─── 진단 범위·대상 자산 식별
│
▼
[2단계: 이미지 진단] ── Trivy로 운영 이미지 전수 스캔
│ → JSON 리포트 생성 (증적)
▼
[3단계: 설정 진단] ─── Trivy misconfig + kube-bench
│ → CIS Benchmark 결과 리포트 (증적)
▼
[4단계: 결과 분석] ─── Critical/High 취약점 분류
│ → 조치 계획 수립 (보완조치 이행계획서)
▼
[5단계: 증적 제출] ─── 스캔 결과 + 조치 이력 + 재스캔 결과
5.3. 증적 자료 생성 명령어
심사 시 제출할 증적 자료를 생성하는 실전 명령어입니다.
1
2
3
4
5
6
7
8
9
10
11
# ① 이미지 취약점 스캔 결과 (JSON 증적)
trivy k8s -n prod --report all all \
--format json --output trivy-k8s-report.json
# ② CIS Benchmark 설정 진단 결과
trivy k8s --compliance k8s-cis-1.23 \
--report summary > cis-benchmark-report.txt
# ③ RBAC 권한 분석
trivy k8s --scanners rbac --report all all \
--format json --output rbac-report.json
심사 TIP: 심사관은 “진단을 했다”는 사실보다, “진단 결과를 바탕으로 조치를 했고, 재검증까지 완료했다”는 흐름을 봅니다. 취약점 발견 → 조치 → 재스캔의 3단계 증적을 반드시 준비하세요.
6. UI 대시보드: CLI 없이 시각적으로 관리하기
CLI만으로는 보안팀 전체가 활용하기 어렵습니다. 아래 UI 도구들을 활용하면 웹 브라우저에서 취약점 현황을 한눈에 파악할 수 있습니다.
6.1. Trivy Operator + Grafana (오픈소스, 권장)
Trivy Operator가 생성한 CRD 데이터를 Prometheus로 수집하고, Grafana 대시보드로 시각화하는 방식입니다.
구성 흐름:
1
2
3
4
5
Trivy Operator → CRD (VulnerabilityReport)
↓
Prometheus (메트릭 수집)
↓
Grafana Dashboard (시각화)
Grafana에서 볼 수 있는 정보:
- 네임스페이스별 취약점 수 (Critical / High / Medium / Low)
- 이미지별 취약점 현황
- 시간대별 취약점 추이 (트렌드)
Aqua Security에서 공식 Trivy Grafana Dashboard를 제공하고 있어, Dashboard JSON을 Import하면 바로 사용할 수 있습니다.
6.2. Lens (쿠버네티스 IDE)
Lens는 쿠버네티스 클러스터를 데스크톱 앱에서 관리할 수 있는 GUI 도구입니다. Trivy Operator가 설치되어 있으면 VulnerabilityReport CRD를 Lens에서 직접 조회할 수 있습니다.
6.3. Microsoft Defender for Cloud (Azure 네이티브)
Azure 포탈에서 별도 설치 없이 사용할 수 있는 유료 서비스입니다. ACR 이미지 스캔 + AKS 런타임 보안을 통합 대시보드에서 관리할 수 있으며, ISMS 심사 증적으로도 활용 가능합니다.
| 도구 | 비용 | 설치 난이도 | 특징 |
|---|---|---|---|
| Grafana + Prometheus | 무료 (OSS) | 중간 | 커스터마이징 자유도 높음 |
| Lens | 무료/유료 | 낮음 | 데스크톱 앱, 즉시 사용 |
| Defender for Cloud | 유료 | 매우 낮음 | Azure 네이티브 통합 |
7. AKS 취약점 진단 체크리스트
ISMS 심사 및 정기 보안 진단에 활용할 수 있는 실전 체크리스트입니다.
7.1. 컨테이너 이미지 보안
| # | 점검 항목 | 진단 방법 | 상태 |
|---|---|---|---|
| 1-1 | 베이스 이미지에 Critical/High CVE가 없는가? | trivy image <이미지명> | ☐ |
| 1-2 | 불필요한 패키지가 설치되어 있지 않은가? (최소 이미지 사용) | Dockerfile 검토 | ☐ |
| 1-3 | 컨테이너가 root 유저로 실행되고 있지 않은가? | trivy config / PodSpec 확인 | ☐ |
| 1-4 | 이미지 태그에 latest가 아닌 특정 버전이 명시되어 있는가? | PodSpec 확인 | ☐ |
| 1-5 | 신뢰할 수 있는 레지스트리(ACR 등)에서만 이미지를 가져오는가? | Admission Policy 확인 | ☐ |
7.2. 쿠버네티스 설정 보안
| # | 점검 항목 | 진단 방법 | 상태 |
|---|---|---|---|
| 2-1 | RBAC 최소 권한 원칙이 적용되어 있는가? | trivy k8s --scanners rbac | ☐ |
| 2-2 | NetworkPolicy가 기본 적용(Default Deny)되어 있는가? | kubectl get networkpolicy -A | ☐ |
| 2-3 | Pod Security Standards/Admission이 적용되어 있는가? | 네임스페이스 라벨 확인 | ☐ |
| 2-4 | Secret이 평문으로 저장되지 않고 암호화되어 있는가? | etcd 암호화 설정 확인 | ☐ |
| 2-5 | 불필요한 ClusterRoleBinding이 없는가? | kubectl get clusterrolebinding | ☐ |
7.3. 클러스터 인프라 보안
| # | 점검 항목 | 진단 방법 | 상태 |
|---|---|---|---|
| 3-1 | CIS Kubernetes Benchmark를 준수하는가? | trivy k8s --compliance k8s-cis | ☐ |
| 3-2 | API Server 접근이 Private Endpoint로 제한되어 있는가? | AKS 설정 확인 | ☐ |
| 3-3 | 노드 OS(Ubuntu/Mariner)의 보안 패치가 최신인가? | Azure Portal / az aks nodepool | ☐ |
| 3-4 | 로깅(Audit Log)이 활성화되어 있는가? | Azure Monitor / Diagnostic Settings | ☐ |
| 3-5 | 노드풀 오토스케일링 시 보안 정책이 유지되는가? | 신규 노드 대상 재진단 | ☐ |
7.4. 운영/모니터링
| # | 점검 항목 | 진단 방법 | 상태 |
|---|---|---|---|
| 4-1 | Trivy Operator가 클러스터에 설치/운영 중인가? | kubectl get pods -n trivy-system | ☐ |
| 4-2 | 취약점 스캔이 주기적(최소 주 1회)으로 수행되고 있는가? | CronJob / Operator 로그 확인 | ☐ |
| 4-3 | Critical 취약점 발견 시 알림(Slack/Teams)이 설정되어 있는가? | AlertManager 연동 확인 | ☐ |
| 4-4 | 진단 결과에 대한 조치 이력이 관리되고 있는가? | 이슈 트래커(Jira 등) | ☐ |
| 4-5 | 조치 후 재검증(Re-scan)을 수행하고 있는가? | 재스캔 결과 비교 | ☐ |