[Golden Kubestronaut] KCSA 추가 실전 문제 30제 - 클라우드 네이티브 보안 심화

정답: B) 소프트웨어 공급망의 무결성을 보장하기 위한 보안 수준을 정의한다

SLSA는 소프트웨어 공급망 공격을 방지하기 위한 보안 프레임워크로, Build Level 0부터 Level 3까지의 보안 수준을 정의합니다. 빌드 프로세스의 출처(provenance) 추적, 변조 방지, 격리된 빌드 환경 등을 요구합니다.

정답: D) Falco - 런타임 위협 탐지

Sigstore는 Cosign(이미지/아티팩트 서명), Fulcio(키리스 서명을 위한 단기 인증서 발급), Rekor(서명 투명성 로그)로 구성됩니다. Falco는 런타임 보안 도구로 Sigstore와는 별개의 CNCF 프로젝트입니다.

정답: B) 소프트웨어 공급망의 전체 프로세스(레이아웃과 링크를 통한 단계별 검증)

in-toto는 소프트웨어 공급망의 전체 과정을 보호하는 프레임워크입니다. 레이아웃(layout)으로 공급망의 예상 단계를 정의하고, 링크(link) 메타데이터로 각 단계의 실제 수행을 기록하여 변조를 탐지합니다.

정답: B) eBPF 또는 커널 모듈을 통해 시스템 콜을 실시간으로 모니터링한다

Falco는 eBPF 프로브 또는 커널 모듈을 사용하여 시스템 콜을 실시간으로 모니터링하고, YAML 기반 규칙에 따라 비정상적인 행위(예: 예기치 않은 셸 실행, 민감한 파일 접근)를 탐지합니다.

정답: B) eBPF 기반으로 커널 레벨에서 보안 정책을 적용하고 프로세스를 즉시 차단할 수 있다

Tetragon은 Cilium 프로젝트의 eBPF 기반 보안 관찰성 및 런타임 강제 도구입니다. Falco와 달리 탐지뿐 아니라 커널 레벨에서 직접 프로세스를 차단(kill)할 수 있는 런타임 강제(enforcement) 기능을 제공합니다.

정답: B) 네트워크 위치에 관계없이 모든 요청을 검증하고 최소 권한을 부여한다

제로 트러스트 모델은 "절대 신뢰하지 않고, 항상 검증한다(Never Trust, Always Verify)"를 원칙으로 합니다. 네트워크 경계 내부라도 모든 요청에 대해 인증, 인가, 암호화를 요구하며 최소 권한 원칙을 적용합니다.

정답: B) 워크로드에 통일된 ID(SPIFFE ID)를 부여하고 SVID를 통해 인증한다

SPIFFE는 워크로드에 플랫폼 독립적인 ID(spiffe://trust-domain/path 형식)를 부여하는 표준입니다. SPIRE는 SPIFFE의 참조 구현체로, X.509 SVID 또는 JWT SVID를 발급하여 워크로드 간 mTLS 인증을 가능하게 합니다.

정답: B) Kubernetes Auth Method (ServiceAccount 토큰 기반)

Vault의 Kubernetes Auth Method는 Pod의 ServiceAccount 토큰을 사용하여 Vault에 인증합니다. Vault Agent Injector 또는 CSI Provider를 통해 시크릿을 Pod에 주입할 수 있으며, 동적 시크릿 관리가 가능합니다.

정답: B) OIDC 기반 ID를 사용하여 장기 키 관리 없이 단기 인증서로 서명한다

Keyless Signing은 Fulcio CA에서 OIDC 인증(예: Google, GitHub)을 통해 단기 서명 인증서를 발급받아 서명하고, Rekor 투명성 로그에 기록합니다. 장기 개인 키를 관리할 필요가 없어 키 관리 부담을 제거합니다.

정답: B) OCI 아티팩트에 서명하고 검증하기 위한 표준 도구

Notation은 OCI 이미지 및 아티팩트에 대한 서명과 검증을 위한 CLI 도구이자 라이브러리입니다. 플러그인 확장 모델을 지원하며, Azure Key Vault, AWS Signer 등의 KMS와 통합할 수 있습니다.

정답: B) 소프트웨어에 포함된 모든 구성 요소(라이브러리, 의존성)의 목록을 제공하여 취약점 관리를 지원한다

SBOM은 소프트웨어의 "재료 목록"으로, 포함된 모든 컴포넌트와 버전을 문서화합니다. 새로운 CVE가 발견되면 SBOM을 통해 영향받는 소프트웨어를 빠르게 식별할 수 있습니다.

정답: B) 둘 다 SBOM 형식 표준이다

CycloneDX(OWASP)와 SPDX(Linux Foundation)는 모두 SBOM을 생성하기 위한 표준 형식입니다. SPDX는 라이선스 컴플라이언스에 초점이 있고, CycloneDX는 보안과 취약점 분석에 최적화되어 있습니다.

정답: A) Mutating -> Validating -> Object Persistence

Kubernetes API 요청은 인증/인가 후 먼저 MutatingAdmissionWebhook을 거쳐 리소스를 변형(수정)하고, 그 다음 ValidatingAdmissionWebhook으로 유효성을 검증한 후 etcd에 저장됩니다.

정답: B) YAML 기반으로 정책을 정의하며, 검증 외에 변형(mutate)과 생성(generate) 기능을 제공한다

Kyverno는 Kubernetes 네이티브 정책 엔진으로, YAML과 CEL로 정책을 정의합니다. validate(검증), mutate(변형), generate(리소스 생성), verifyImages(이미지 검증) 규칙을 지원합니다.

정답: C) Rego

OPA는 범용 정책 엔진으로, Rego라는 선언적 쿼리 언어를 사용하여 정책을 정의합니다. Gatekeeper는 OPA를 Kubernetes에 통합한 것으로, ConstraintTemplate에 Rego로 정책 로직을 작성합니다.

정답: B) Privileged, Baseline, Restricted

Pod Security Standards는 Privileged(무제한), Baseline(최소한의 제한으로 알려진 권한 상승 방지), Restricted(최대 보안으로 Pod 하드닝 모범 사례 적용) 세 단계를 정의합니다.

정답: B) enforce, audit, warn

Pod Security Admission은 enforce(위반 시 거부), audit(위반을 감사 로그에 기록), warn(위반 시 경고 메시지 표시) 세 가지 모드를 지원합니다. 네임스페이스 레이블로 적용합니다.

정답: B) 사용법이 복잡하고, RBAC 바인딩이 혼란스러우며, 적용 범위가 예측하기 어려웠다

PSP는 RBAC를 통한 바인딩 메커니즘이 직관적이지 않았고, 어떤 PSP가 어떤 Pod에 적용되는지 예측이 어려웠습니다. Kubernetes 1.25에서 제거되었으며, Pod Security Admission, Kyverno, OPA/Gatekeeper가 대체합니다.

정답: B) NetworkPolicy가 없으면 모든 트래픽이 허용되며, 정책이 적용되면 명시적으로 허용된 트래픽만 통과한다

기본적으로 Kubernetes는 모든 Pod 간 통신을 허용합니다. NetworkPolicy를 적용하면 선택된 Pod에 대해 명시적으로 허용된 인그레스/이그레스 트래픽만 통과합니다. 단, CNI 플러그인이 NetworkPolicy를 지원해야 합니다.

정답: B) 기본적으로 Base64 인코딩만 되어 etcd에 저장되며, 암호화하려면 EncryptionConfiguration을 별도 설정해야 한다

Kubernetes Secret은 기본적으로 Base64 인코딩된 상태로 etcd에 저장됩니다. 이는 암호화가 아니므로, etcd 접근 권한이 있으면 시크릿을 읽을 수 있습니다. 정적 암호화를 위해 EncryptionConfiguration을 설정하거나, KMS 프로바이더를 사용해야 합니다.

정답: D) Helm

Trivy(Aqua Security), Grype(Anchore), Clair(Quay)는 모두 컨테이너 이미지 취약점 스캐닝 도구입니다. Helm은 Kubernetes 패키지 매니저로 보안 스캐닝과는 관련이 없습니다.

정답: B) 필요한 리소스와 동사(verbs)만 포함하는 Role을 생성하고 최소 범위의 RoleBinding을 사용한다

최소 권한 원칙은 필요한 최소한의 권한만 부여하는 것입니다. 특정 리소스의 특정 동사만 허용하는 Role을 만들고, 해당 네임스페이스에만 적용하는 RoleBinding을 사용합니다. 와일드카드 사용과 cluster-admin 남용을 피해야 합니다.

정답: B) 서버와 클라이언트 양쪽 모두 인증서로 상호 인증하고 통신을 암호화한다

mTLS(mutual TLS)는 서버뿐 아니라 클라이언트도 인증서를 제시하여 양방향 인증을 수행합니다. Istio, Linkerd 등의 서비스 메시는 사이드카 프록시를 통해 서비스 간 mTLS를 자동으로 적용합니다.

정답: D) RequestResponse

Kubernetes 감사 로그는 None(기록 없음), Metadata(요청 메타데이터만), Request(메타데이터 + 요청 본문), RequestResponse(메타데이터 + 요청 + 응답 본문) 4단계를 지원합니다. RequestResponse가 가장 상세합니다.

정답: C) networkPolicy

Pod SecurityContext에서는 runAsUser, runAsNonRoot, runAsGroup, fsGroup, supplementalGroups, sysctls, seccompProfile 등을 설정할 수 있습니다. NetworkPolicy는 별도의 Kubernetes 리소스로 SecurityContext와는 관련이 없습니다.

정답: B) 컨테이너가 사용할 수 있는 시스템 콜을 필터링한다

Seccomp(Secure Computing Mode)은 프로세스가 호출할 수 있는 시스템 콜을 허용 목록 또는 차단 목록으로 필터링합니다. Kubernetes에서는 seccompProfile을 통해 RuntimeDefault 또는 커스텀 프로파일을 적용할 수 있습니다.

정답: B) Admission Controller(Kyverno, OPA)를 통해 서명된 이미지만 허용하는 정책을 적용한다

Kyverno의 verifyImages 규칙이나 OPA/Gatekeeper의 ConstraintTemplate을 사용하여 cosign 서명 또는 Notation 서명이 검증된 이미지만 배포를 허용할 수 있습니다. 이는 공급망 보안의 핵심 요소입니다.

정답: B) 자동 마운트되는 영구 토큰이 더 이상 생성되지 않으며, TokenRequest API를 통한 단기 토큰 사용이 권장된다

Kubernetes 1.24부터 ServiceAccount 생성 시 자동으로 Secret이 생성되지 않습니다. 대신 TokenRequest API를 통해 시간 제한이 있는 단기 토큰을 발급받는 방식이 권장되어 보안이 강화되었습니다.

정답: B) 커널을 공유하지 않거나 추가 격리 레이어를 통해 컨테이너 이스케이프 위험을 줄인다

gVisor는 사용자 공간 커널(application kernel)을 제공하여 호스트 커널과의 직접 시스템 콜을 차단합니다. Kata Containers는 경량 VM 내에서 컨테이너를 실행하여 하드웨어 레벨 격리를 제공합니다. 두 기술 모두 RuntimeClass를 통해 선택적으로 사용합니다.

정답: D) 모든 워크로드를 root로 실행하고 privileged 모드를 사용

다계층 방어는 여러 보안 계층을 중첩하여 하나의 계층이 실패해도 다른 계층이 보호하는 전략입니다. 이미지 보안, 네트워크 보안, 접근 제어, 런타임 보안을 결합합니다. root 실행과 privileged 모드는 보안 모범 사례에 반합니다.