KCSA 쿠버네티스 클라우드 네이티브 보안 어소시에이트 실전 모의고사 60문제

A) Code B) Container C) Cluster D) Cloud

정답: D

설명: 4C 보안 모델은 Cloud(가장 외부) → Cluster → Container → Code(가장 내부) 순서입니다. Cloud 레이어는 IaaS 인프라, 네트워크, 스토리지 보안을 담당합니다. 각 레이어는 내부 레이어를 보호하며, 외부 레이어의 보안이 취약하면 내부 레이어가 안전하더라도 의미가 없습니다.

A) 단 하나의 강력한 보안 레이어에 집중 B) 여러 독립적인 보안 레이어를 구현하여 하나가 실패해도 다른 레이어가 보호 C) 보안을 외부 경계에만 집중 D) 암호화만으로 모든 보안 요구사항을 충족

정답: B

설명: Defense in Depth(심층 방어)는 여러 독립적인 보안 제어(레이어)를 구현하여 하나의 보안 제어가 실패하더라도 다른 제어가 공격을 막을 수 있도록 하는 원칙입니다. Kubernetes에서는 네트워크 정책, RBAC, Pod Security Standards, 이미지 스캐닝 등 여러 레이어를 함께 적용합니다.

A) 내부 네트워크는 신뢰하고 외부 네트워크만 검증한다 B) "절대 신뢰하지 말고, 항상 검증하라" - 내부/외부 모든 요청을 인증하고 권한을 최소한으로 부여한다 C) VPN으로 연결된 사용자는 모두 신뢰한다 D) 방화벽 내부의 트래픽은 자유롭게 허용한다

정답: B

설명: Zero Trust는 "Never Trust, Always Verify" 원칙으로, 네트워크 위치에 관계없이(내부/외부) 모든 요청을 인증하고 권한을 검증합니다. 최소 권한 원칙, 마이크로 세그멘테이션, 지속적인 모니터링을 핵심으로 합니다. Kubernetes에서 RBAC, mTLS, NetworkPolicy가 Zero Trust를 구현합니다.

A) 취약점에 대한 고유 식별자와 공개 데이터베이스 B) 컨테이너 이미지 서명 표준 C) Kubernetes 보안 설정 프레임워크 D) 네트워크 취약점 스캐너 도구

정답: A

설명: CVE는 공개적으로 알려진 소프트웨어 취약점에 부여되는 고유 식별자입니다(예: CVE-2024-XXXX). CVSS(Common Vulnerability Scoring System)는 0.010.0 점수로 심각도를 측정합니다(Critical: 9.010.0, High: 7.08.9, Medium: 4.06.9, Low: 0.1~3.9). 컨테이너 이미지 스캐닝 도구(Trivy, Grype)는 CVE 데이터베이스를 기반으로 취약점을 탐지합니다.

A) X.509 클라이언트 인증서 B) ServiceAccount 토큰 C) OIDC(OpenID Connect) D) MD5 패스워드 해시

정답: D

설명: Kubernetes API Server가 지원하는 인증 메커니즘은 X.509 인증서, Bearer Token(ServiceAccount), OIDC(Google, Dex 등 ID 제공자), 웹훅, HTTP 기본 인증(deprecated) 등입니다. MD5 패스워드 해시는 Kubernetes 인증 방식에 포함되지 않습니다.

A) etcd의 처리 속도를 높이기 위해 B) Secret 등 민감한 데이터가 etcd에 평문으로 저장되는 것을 방지하기 위해 C) 네트워크 전송 중 데이터를 보호하기 위해 D) 컨테이너 이미지를 암호화하기 위해

정답: B

설명: Kubernetes Secret은 기본적으로 etcd에 Base64 인코딩(암호화 아님)으로 저장됩니다. etcd에 직접 접근 가능한 공격자는 모든 Secret 데이터를 읽을 수 있습니다. Encryption at Rest를 설정하면 etcd에 기록되는 데이터(특히 Secret)가 AES-CBC 또는 AES-GCM으로 암호화됩니다.

A) 익명 인증이 활성화되면 kubelet API가 인증 없이 접근 가능해져 보안 위험이 된다 B) 익명 인증은 성능을 저하시킨다 C) 익명 인증은 Pod 스케줄링을 방해한다 D) 익명 인증은 Control Plane과의 통신을 차단한다

정답: A

설명: Kubelet은 10250 포트에서 API를 제공합니다. --anonymous-auth=true(기본값)이면 익명 요청이 system:anonymous 사용자로 처리됩니다. 이를 악용하면 인증 없이 노드의 Pod 목록 조회, 로그 접근, 명령 실행이 가능해집니다. --anonymous-auth=false와 Webhook 인증 설정이 권장됩니다.

A) ClusterRole은 더 강력한 권한을 가진다 B) Role은 특정 Namespace 내 리소스에만 적용되고, ClusterRole은 클러스터 전체 또는 클러스터 수준 리소스에 적용된다 C) ClusterRole은 ServiceAccount에만 바인딩할 수 있다 D) Role은 모든 Namespace에서 사용할 수 있다

정답: B

설명: Role은 특정 Namespace 내의 리소스에 대한 권한을 정의하며, RoleBinding으로 적용합니다. ClusterRole은 Namespace에 상관없이 클러스터 전체 또는 Node, PersistentVolume 같은 클러스터 수준 리소스에 대한 권한을 정의하며, ClusterRoleBinding으로 적용합니다. ClusterRole을 특정 Namespace에서만 사용하도록 RoleBinding으로 바인딩할 수도 있습니다.

A) 클러스터에 사용자를 추가하는 역할 B) API 요청이 etcd에 저장되기 전에 요청을 검증하거나 수정하는 플러그인 C) 컨테이너 런타임을 관리하는 역할 D) 네트워크 트래픽을 모니터링하는 역할

정답: B

설명: Admission Controller는 kube-apiserver에서 인증/인가 이후, etcd 저장 이전에 실행되는 플러그인입니다. Validating Admission Webhook은 요청을 검증(거부 가능)하고, Mutating Admission Webhook은 요청을 수정(기본값 주입, 사이드카 주입 등)합니다. OPA Gatekeeper, Kyverno 등이 이 메커니즘을 활용합니다.

A) runAsNonRoot: true B) allowPrivilegeEscalation: false C) privileged: true D) seccompProfile 설정

정답: C

설명: Restricted 프로파일은 가장 엄격한 Pod Security Standard입니다. runAsNonRoot: true, allowPrivilegeEscalation: false, readOnlyRootFilesystem: true(강력 권장), seccompProfile 설정, 호스트 네임스페이스 사용 금지 등을 요구합니다. privileged: true는 Privileged 프로파일에서만 허용되며 Restricted에서는 명시적으로 금지됩니다.

A) kube-apiserver에서 네트워크 옵션을 비활성화한다 B) 빈 podSelector를 가진 NetworkPolicy를 생성하여 모든 트래픽을 차단한다 C) 각 노드에서 방화벽 규칙을 설정한다 D) containerd 설정에서 네트워크를 비활성화한다

정답: B

설명: Kubernetes NetworkPolicy로 Default Deny를 구현하려면 빈 podSelector: {}(모든 Pod에 매칭)와 빈 ingress: [](모든 Ingress 차단)를 가진 NetworkPolicy를 Namespace에 적용합니다. Egress Default Deny도 별도로 설정할 수 있습니다. 그 후 필요한 트래픽만 허용하는 추가 NetworkPolicy를 생성합니다.

A) Secret은 완전히 안전하므로 추가 조치가 불필요하다 B) Secret은 기본적으로 Base64 인코딩만 되어 있으므로, etcd 암호화 + 외부 시크릿 관리(Vault, ESO)를 권장한다 C) Secret을 많이 만들수록 보안이 강화된다 D) Secret은 항상 ConfigMap보다 안전하다

정답: B

설명: Kubernetes Secret의 보안 문제점: 1) etcd에 Base64(인코딩, 암호화 아님)로 저장, 2) RBAC 없이는 Namespace 내 모든 사용자가 접근 가능, 3) 로그나 환경변수 출력 시 노출 위험. 개선책: etcd Encryption at Rest 활성화, RBAC 최소 권한 적용, HashiCorp Vault/External Secrets Operator(ESO)/Sealed Secrets 사용.

A) 컨테이너가 읽기 작업만 수행하도록 제한 B) 컨테이너의 루트 파일시스템을 읽기 전용으로 만들어 런타임 중 파일 수정 불가 C) 컨테이너 이미지 다운로드를 차단 D) Secret 파일을 읽기 전용으로 마운트

정답: B

설명: readOnlyRootFilesystem: true는 컨테이너의 루트 파일시스템을 읽기 전용으로 설정합니다. 공격자가 컨테이너에 침투하더라도 파일시스템에 악성코드를 작성하거나 설정을 변경할 수 없게 됩니다. 쓰기가 필요한 경우 특정 경로에 emptyDir 볼륨을 마운트하여 해결합니다.

A) 모든 Pod에 cluster-admin ClusterRole을 부여한다 B) automountServiceAccountToken: false를 설정하고 필요한 권한만 명시적으로 부여한다 C) 모든 Pod에 동일한 ServiceAccount를 공유한다 D) ServiceAccount를 사용하지 않는다

정답: B

설명: 최소 권한 원칙(Principle of Least Privilege) 적용: 1) Kubernetes API에 접근이 불필요한 Pod는 automountServiceAccountToken: false 설정, 2) 각 애플리케이션마다 전용 ServiceAccount 생성, 3) 필요한 리소스/verb만 허용하는 세밀한 RBAC Role 정의, 4) default ServiceAccount 사용 최소화.

A) Security, Threats, Risk, Identity, Defense, Encryption B) Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege C) System, Technology, Runtime, Infrastructure, Development, Environment D) Scanning, Testing, Review, Inspection, Detection, Enforcement

정답: B

설명: STRIDE는 마이크로소프트가 개발한 위협 모델링 프레임워크입니다: Spoofing(신분 위장), Tampering(데이터 변조), Repudiation(부인), Information Disclosure(정보 노출), Denial of Service(서비스 거부), Elevation of Privilege(권한 상승). Kubernetes 보안에서 각 위협에 대응하는 제어를 설계합니다.

A) runAsNonRoot: true B) privileged: true C) readOnlyRootFilesystem: true D) allowPrivilegeEscalation: false

정답: B

설명: privileged: true는 컨테이너에 호스트 노드와 거의 동일한 권한을 부여합니다. 이 설정이 있는 컨테이너는 노드의 전체 디바이스 접근, 커널 모듈 로드, 네트워크 설정 변경 등이 가능해져 컨테이너 경계를 탈출하여 호스트 노드를 장악할 수 있습니다. Pod Security Standards의 Baseline 이상에서는 이 설정이 금지됩니다.

A) API 서버 노출은 성능에만 영향을 준다 B) 인증 취약점이 있으면 공격자가 클러스터 전체를 장악할 수 있다 C) API 서버는 항상 퍼블릭으로 노출해야 한다 D) API 서버 노출은 보안 문제가 없다

정답: B

설명: kube-apiserver는 클러스터의 중앙 컨트롤 포인트입니다. 외부 노출 + 인증 취약점이 결합되면 공격자가 악성 Pod 배포, RBAC 조작, Secret 탈취, 노드 장악 등 클러스터 전체를 제어할 수 있습니다. 실제로 공개된 Kubernetes API 서버를 스캔하는 공격이 지속적으로 발생합니다. API 서버는 최소한 IP 화이트리스트와 강력한 인증으로 보호해야 합니다.

A) 컨테이너 이미지 취약점 스캐닝 B) 런타임 보안 - 시스템 콜 수준에서 컨테이너 내의 이상 동작을 실시간 탐지 C) Kubernetes 네트워크 정책 자동 생성 D) RBAC 권한 자동 설정

정답: B

설명: Falco는 CNCF 졸업 프로젝트로, Linux 커널의 eBPF/커널 모듈을 통해 시스템 콜을 실시간 모니터링합니다. 규칙 기반으로 이상 동작(권한 없는 네트워크 연결, 민감 파일 접근, 셸 실행 등)을 탐지하고 경보를 발생시킵니다. 이미지 스캐닝(정적 분석)과 달리 런타임 시 실제 동작을 감시합니다.

A) 소프트웨어의 라이선스 비용을 계산하는 도구 B) 소프트웨어를 구성하는 모든 컴포넌트, 라이브러리, 의존성 목록 - 취약점 파악 및 규정 준수에 활용 C) 컨테이너 이미지 빌드 자동화 도구 D) 코드 배포를 제어하는 정책 엔진

정답: B

설명: SBOM(소프트웨어 자재 명세서)은 소프트웨어를 구성하는 모든 컴포넌트, 라이브러리, 의존성과 그 버전 정보를 나열한 목록입니다. CVE 취약점 발견 시 영향받는 소프트웨어를 빠르게 파악하고, 오픈소스 라이선스 준수 여부를 확인하는 데 활용됩니다. SPDX와 CycloneDX가 주요 SBOM 형식입니다.

A) 컨테이너 런타임 보안 모니터링 B) 컨테이너 이미지와 소프트웨어 아티팩트의 서명과 검증 - 공급망 보안 C) Kubernetes 클러스터 취약점 스캐닝 D) 네트워크 트래픽 암호화

정답: B

설명: Sigstore는 Linux Foundation 프로젝트로, Cosign(이미지 서명/검증), Fulcio(코드 서명 인증서 발급), Rekor(투명한 서명 로그)로 구성됩니다. 개발자가 컨테이너 이미지와 소프트웨어 아티팩트에 서명하고, 배포 시 서명을 검증하여 공급망 공격(이미지 변조)을 방지합니다. Admission Controller와 연계하여 서명된 이미지만 배포를 허용할 수 있습니다.

A) Kubernetes 클러스터 설정 모니터링 B) 컨테이너 이미지, 파일시스템, Git 저장소의 취약점(CVE), 시크릿, IaC 오설정 스캐닝 C) 런타임 시 시스템 콜 모니터링 D) 서비스 메시 mTLS 관리

정답: B

설명: Trivy는 Aqua Security가 개발한 오픈소스 취약점 스캐너입니다. 컨테이너 이미지, 파일시스템, Git 저장소, Kubernetes 클러스터에서 CVE 취약점, 노출된 시크릿, Dockerfile/IaC 오설정을 탐지합니다. CI/CD 파이프라인에 통합하여 빌드 시점에 취약한 이미지 배포를 차단할 수 있습니다.

A) 컨테이너 이미지 서명 검증 B) 서비스 간 양방향 인증과 암호화 - 통신하는 양쪽 모두 인증서로 신원 증명 C) Pod 간 트래픽 로드밸런싱 D) 데이터베이스 연결 암호화

정답: B

설명: mTLS(상호 TLS)는 일반 TLS와 달리 클라이언트와 서버 모두 인증서로 신원을 증명합니다. 서비스 메시(Istio, Linkerd)에서 자동으로 모든 서비스 간 통신에 mTLS를 적용하여 내부 네트워크에서의 도청(eavesdropping)과 MITM(Man-in-the-Middle) 공격을 방지합니다. Zero Trust 네트워크의 핵심 구성 요소입니다.

A) Kubernetes 클러스터 배포를 관리하기 위해 B) 중앙화된 시크릿 관리 - 동적 시크릿 생성, 자동 만료, 감사 로그 제공 C) 컨테이너 이미지 레지스트리로 사용하기 위해 D) Kubernetes 네트워크 정책 관리를 위해

정답: B

설명: HashiCorp Vault는 엔터프라이즈급 시크릿 관리 솔루션입니다. Kubernetes와 연동 시: 동적 데이터베이스 자격증명 생성(요청마다 유효한 임시 자격증명 발급), 자동 만료/갱신, 접근 로그, 강력한 암호화 제공. Vault Agent나 External Secrets Operator(ESO)를 통해 Vault의 시크릿을 Kubernetes Secret으로 동기화합니다.

A) Secret을 파일시스템에서 완전히 삭제 B) 퍼블릭 키로 Secret을 암호화한 SealedSecret 오브젝트를 Git에 안전하게 저장하고, 클러스터의 컨트롤러가 복호화 C) Secret을 클러스터 외부 서버에 백업 D) Secret을 여러 Namespace에 복제

정답: B

설명: Sealed Secrets는 Bitnami가 개발한 도구입니다. kubeseal CLI로 퍼블릭 키를 사용하여 Secret을 암호화한 SealedSecret 오브젝트를 생성하면, 이를 Git에 안전하게 저장할 수 있습니다. 클러스터의 Sealed Secrets 컨트롤러만 프라이빗 키로 복호화할 수 있어 GitOps 워크플로우와 잘 어울립니다.

A) Kubernetes 인증 시험 준비 가이드 B) Kubernetes 클러스터의 보안 설정 모범 사례와 하드닝 가이드라인 제공 C) 클라우드 제공업체별 Kubernetes 비용 최적화 D) Kubernetes 성능 벤치마크 측정

정답: B

설명: CIS Kubernetes Benchmark는 인터넷 보안 센터(CIS)가 개발한 Kubernetes 보안 설정 가이드라인입니다. API 서버 설정, etcd 보안, kubelet 설정, RBAC, 로깅 등 수백 가지 보안 권고사항을 포함합니다. kube-bench 도구를 사용하여 클러스터가 CIS 기준을 준수하는지 자동으로 평가할 수 있습니다.

A) Kubernetes 클러스터 배포 자동화 B) Policy as Code - Admission Controller를 통해 Kubernetes 리소스 생성/수정 시 정책을 강제 C) 컨테이너 런타임 취약점 탐지 D) 서비스 메시 설정 관리

정답: B

설명: OPA(Open Policy Agent) Gatekeeper는 CNCF 졸업 프로젝트로, Kubernetes Admission Webhook을 통해 정책을 강제합니다. Rego 언어로 작성된 정책(ConstraintTemplate + Constraint)으로 "privileged 컨테이너 금지", "최신 이미지만 허용", "특정 레이블 필수" 등의 규칙을 선언적으로 정의하고 자동 강제할 수 있습니다.

A) Kyverno는 더 복잡한 정책을 지원한다 B) Kyverno는 YAML로 정책을 작성하고(Kubernetes 네이티브), OPA Gatekeeper는 Rego 언어를 사용한다 C) OPA Gatekeeper는 Kubernetes에만 특화되어 있다 D) 두 도구는 완전히 동일한 기능을 제공한다

정답: B

설명: Kyverno는 Kubernetes 네이티브 정책 엔진으로, YAML로 정책을 작성하여 Kubernetes 사용자에게 친숙합니다. Validate, Mutate, Generate 세 가지 정책 타입을 지원합니다. OPA Gatekeeper는 범용 정책 엔진인 OPA를 Kubernetes에 통합한 것으로, Rego 언어를 사용하여 더 복잡한 논리 표현이 가능하지만 학습 곡선이 있습니다.

A) 컨테이너 이미지 서명 및 검증 (Sigstore/Cosign) B) 신뢰할 수 있는 베이스 이미지만 사용 C) CI/CD 파이프라인에서 취약점 스캐닝 D) Pod에 더 많은 리소스 limits 설정

정답: D

설명: 공급망 보안 방법: 이미지 서명 및 검증(Cosign), 신뢰할 수 있는 소스의 베이스 이미지 사용, CI/CD에서 Trivy/Grype로 취약점 스캐닝, SBOM 생성, Private Container Registry 사용, Admission Controller로 서명된 이미지만 허용. 리소스 limits 설정은 성능/가용성과 관련된 설정으로 공급망 보안과 직접적 관련이 없습니다.

A) Ingress는 클러스터 입장 트래픽, Egress는 클러스터 퇴장 트래픽 B) Ingress는 Pod로 들어오는 트래픽 제어, Egress는 Pod에서 나가는 트래픽 제어 C) Ingress는 HTTP 트래픽만, Egress는 TCP 트래픽만 제어 D) Ingress와 Egress는 동일한 규칙이다

정답: B

설명: NetworkPolicy에서 ingress 규칙은 특정 Pod로 들어오는 트래픽을 허용하는 소스(Pod, Namespace, IP 블록)를 지정합니다. egress 규칙은 특정 Pod에서 나가는 트래픽의 목적지를 지정합니다. 두 규칙을 함께 사용하면 양방향 트래픽을 세밀하게 제어하여 마이크로 세그멘테이션을 구현할 수 있습니다.

A) 리소스를 삭제하는 권한 B) 리소스 변경 사항을 실시간으로 스트리밍하여 구독하는 권한 C) 리소스를 수정하는 권한 D) 리소스 목록을 조회하는 권한

정답: B

설명: Kubernetes RBAC의 주요 Verb: get(단일 리소스 조회), list(목록 조회), watch(변경 사항 실시간 스트리밍), create(생성), update(전체 수정), patch(부분 수정), delete(삭제). watch는 컨트롤러가 리소스 변경을 실시간으로 감지하는 데 사용됩니다. 최소 권한 원칙에서 불필요한 watch 권한 부여를 주의해야 합니다.

A) enforce, audit, warn 세 가지 모드 - enforce는 위반 시 Pod 생성을 차단, audit과 warn은 로그/경고만 생성 B) allow, deny, monitor 세 가지 모드 C) strict, normal, permissive 세 가지 모드 D) active, passive, silent 세 가지 모드

정답: A

설명: PSA(Pod Security Admission)는 3가지 모드를 지원합니다: enforce(정책 위반 시 Pod 생성 차단), audit(감사 로그에 위반 사항 기록, 생성은 허용), warn(사용자에게 경고 반환, 생성은 허용). Namespace 레이블로 설정합니다(예: pod-security.kubernetes.io/enforce: restricted).

A) 모든 Service를 ClusterIP 타입으로 설정 B) API 서버의 --anonymous-auth=false 옵션 설정 C) NetworkPolicy로 모든 외부 트래픽 차단 D) Pod에 PodDisruptionBudget 설정

정답: B

설명: kube-apiserver에 --anonymous-auth=false를 설정하면 인증되지 않은 요청이 system:anonymous로 처리되는 것을 방지합니다. RBAC으로 system:anonymous와 system:unauthenticated 그룹에 부여된 권한을 제거하는 것도 함께 수행해야 합니다. CIS Kubernetes Benchmark에서도 이 설정을 권장합니다.

A) 최소한의 기반 이미지 사용 (Alpine, Distroless) B) 이미지에 root 사용자 사용 금지 C) 이미지에 SSH 서버 포함 D) 멀티-스테이지 빌드로 빌드 도구 제외

정답: C

설명: 컨테이너 이미지 보안 모범 사례: 최소 기반 이미지 사용(공격 표면 최소화), Non-root 사용자로 실행, 멀티-스테이지 빌드로 빌드 도구 제외, 취약점 스캐닝, 이미지 서명. SSH 서버를 이미지에 포함하는 것은 보안상 나쁜 습관입니다. 디버깅이 필요하면 kubectl exec 또는 ephemeral container를 사용해야 합니다.

A) SOC2는 Kubernetes 성능 기준을 정의한다 B) SOC2는 보안, 가용성, 처리 무결성, 기밀성, 개인정보 보호 원칙을 기반으로, Kubernetes 클러스터 보안이 SOC2 요구사항 충족에 기여한다 C) SOC2는 Kubernetes 전용 보안 표준이다 D) SOC2 준수를 위해 Kubernetes를 반드시 사용해야 한다

정답: B

설명: SOC2는 미국 공인회계사협회(AICPA)가 개발한 서비스 제공업체의 보안 기준입니다. Trust Service Criteria(TSC) 5가지 원칙을 기반으로 합니다. Kubernetes 환경에서 RBAC, 감사 로깅, 네트워크 정책, 암호화 등의 보안 제어를 구현하면 SOC2 요구사항 충족에 도움이 됩니다.

A) 컨테이너의 stdout/stderr 로그 수집 B) 누가, 언제, 무엇을, 어떤 결과로 API 서버에 요청했는지 기록 C) 노드 시스템 리소스 사용량 기록 D) 컨테이너 간 네트워크 트래픽 기록

정답: B

설명: Kubernetes Audit Logging은 kube-apiserver에 대한 모든 요청을 기록합니다. 정책 파일로 기록 레벨(None, Metadata, Request, RequestResponse)을 설정합니다. 보안 사고 조사, 비정상적인 API 활동 탐지, 규정 준수 증명에 필수적입니다. 로그에는 요청자(user), 시간(timestamp), 대상 리소스, HTTP 메서드, 응답 코드가 포함됩니다.

A) 컨테이너가 root로 실행될 수 없다 B) 컨테이너 프로세스가 부모보다 더 많은 권한을 획득할 수 없다 (setuid/setgid 방지) C) 컨테이너가 호스트 네트워크를 사용할 수 없다 D) 컨테이너가 다른 컨테이너와 통신할 수 없다

정답: B

설명: allowPrivilegeEscalation: false는 컨테이너의 프로세스가 자신의 부모 프로세스보다 더 많은 권한을 얻는 것(setuid/setgid 바이너리 실행)을 방지합니다. 예를 들어 sudo, passwd 같은 setuid 바이너리를 통한 권한 상승을 차단합니다. Restricted Pod Security Standard에서 이 설정이 필수입니다.

A) 평문 HTTP 통신 B) TLS 인증서 기반 통신 - 각 컴포넌트(kube-apiserver, kubelet 등) 간 TLS 암호화 C) SSH 터널링만 사용 D) VPN 없이 인터넷으로 통신

정답: B

설명: Kubernetes 컴포넌트 간 통신은 TLS로 암호화됩니다: kube-apiserver ↔ etcd, kube-apiserver ↔ kubelet, Control Plane ↔ Worker Node. 각 컴포넌트는 클러스터 CA(Certificate Authority)가 서명한 인증서를 사용합니다. kubeadm으로 클러스터를 구성하면 이러한 PKI 인프라가 자동으로 설정됩니다.

A) PCI-DSS는 클라우드 환경에 적용되지 않는다 B) 카드 결제 데이터를 처리하는 클라우드 네이티브 애플리케이션은 PCI-DSS 요구사항을 충족해야 한다 C) PCI-DSS는 Kubernetes 전용 표준이다 D) PCI-DSS는 인터넷 트래픽에만 적용된다

정답: B

설명: PCI-DSS는 신용카드 데이터를 처리, 저장, 전송하는 모든 조직에 적용되는 보안 표준입니다. 클라우드 네이티브 환경에서도 카드 데이터를 다루면 PCI-DSS를 준수해야 합니다. Kubernetes 보안 제어(암호화, 접근 제어, 감사 로그, 네트워크 세그멘테이션)가 PCI-DSS 요구사항 충족에 기여합니다.

A) 프라이빗 레지스트리 사용 B) 이미지 취약점 스캐닝 자동화 C) 공개 인터넷의 모든 이미지를 무분별하게 사용 D) 이미지 서명 및 검증

정답: C

설명: Container Registry 보안 모범 사례: 프라이빗 레지스트리 사용(외부 의존성 최소화), 이미지 취약점 자동 스캐닝, 이미지 서명 및 검증(Cosign), 레지스트리 접근 제어(RBAC), 오래된 이미지 정리 정책. 공개 인터넷의 이미지를 검증 없이 사용하는 것은 공급망 공격, 악성 이미지 실행의 위험이 있습니다.

A) Pod의 성능이 저하된다 B) 노드의 파일시스템에 직접 접근하여 호스트 시스템을 조작하거나 민감한 파일(kubelet 설정, 시크릿 등)에 접근할 수 있다 C) HostPath는 완전히 안전한 볼륨 타입이다 D) HostPath를 사용하면 Pod를 재시작할 수 없다

정답: B

설명: HostPath 볼륨은 컨테이너에서 노드의 파일시스템 경로를 직접 마운트합니다. 악의적이거나 손상된 컨테이너는 HostPath를 통해 노드의 /etc, /var/lib/kubelet, /proc 같은 민감한 경로에 접근하거나 수정하여 컨테이너 탈출 및 호스트 장악이 가능합니다. Pod Security Standards의 Restricted 프로파일에서 HostPath 볼륨은 금지됩니다.

A) Kubernetes Secret을 외부 데이터베이스에 동기화 B) 외부 시크릿 관리 시스템(Vault, AWS Secrets Manager 등)의 시크릿을 Kubernetes Secret으로 동기화 C) Kubernetes 클러스터를 외부 클러스터와 연결 D) 외부 사용자의 Kubernetes API 접근을 관리

정답: B

설명: External Secrets Operator(ESO)는 AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, Azure Key Vault 등 다양한 외부 시크릿 관리 시스템과 Kubernetes를 통합합니다. ExternalSecret 오브젝트로 외부 시크릿을 참조하면 ESO가 자동으로 Kubernetes Secret으로 동기화하고 갱신합니다.

A) Flannel B) Cilium (eBPF 기반, L7 NetworkPolicy, 암호화 지원) C) Bridge D) Host networking

정답: B

설명: Cilium은 eBPF(extended Berkeley Packet Filter) 기반의 고성능 네트워크 플러그인으로, 표준 NetworkPolicy뿐 아니라 L7(HTTP 경로, 메서드) 수준의 정책, 노드 간 암호화(WireGuard/IPSec), 네트워크 트래픽 가시성(Hubble)을 제공합니다. Calico도 NetworkPolicy와 암호화를 지원하는 강력한 보안 CNI입니다. Flannel은 기본 L3 네트워킹만 제공합니다.

A) 토큰 만료 시간 제한은 성능 향상을 위해서이다 B) 토큰이 탈취되어도 유효 기간이 짧으면 공격자가 사용할 수 있는 시간이 제한된다 C) Kubernetes에서 토큰 만료는 지원하지 않는다 D) 토큰 만료 시간은 보안과 관련이 없다

정답: B

설명: 서비스 계정 토큰이 탈취되면 공격자가 이를 사용하여 API 서버에 접근할 수 있습니다. 만료 시간을 짧게 설정하면 탈취된 토큰의 유용성을 최소화합니다. Kubernetes 1.22+에서 Projected ServiceAccount Tokens를 통해 만료 시간이 있는 바운드 토큰을 자동으로 사용합니다. TokenRequest API로 단기 토큰을 발급받는 것이 모범 사례입니다.

A) 각 Namespace에 다른 CNI 플러그인을 설치한다 B) NetworkPolicy를 사용하여 다른 Namespace의 Pod에서 오는 트래픽을 차단한다 C) Namespace를 삭제하면 자동으로 차단된다 D) kube-apiserver 설정으로 Namespace를 격리한다

정답: B

설명: 기본적으로 Kubernetes는 Namespace 간 트래픽을 허용합니다. NetworkPolicy에서 namespaceSelector를 사용하여 특정 Namespace의 트래픽만 허용하거나, 다른 모든 Namespace 트래픽을 차단하는 정책을 적용할 수 있습니다. podSelector: {}(모든 Pod)와 빈 ingress 규칙으로 Namespace 레벨의 Default Deny를 구현한 후 필요한 트래픽을 허용합니다.

A) Plan, Design, Build, Test, Deploy B) Identify, Protect, Detect, Respond, Recover C) Scan, Patch, Monitor, Alert, Fix D) Authenticate, Authorize, Encrypt, Log, Review

정답: B

설명: NIST Cybersecurity Framework(CSF)의 5가지 기능: Identify(자산, 위험 식별), Protect(보호 제어 구현), Detect(보안 이벤트 탐지), Respond(사고 대응), Recover(복구). Kubernetes 보안에서 이 프레임워크는 보안 전략을 체계적으로 수립하는 데 활용됩니다.

A) 환경변수로 주입된 Secret은 자동으로 암호화된다 B) 환경변수는 프로세스 덤프, 로그 출력, kubectl describe 등을 통해 노출될 위험이 있다 C) 환경변수로 주입하면 Secret이 자동 삭제된다 D) 환경변수 주입은 볼륨 마운트보다 항상 더 안전하다

정답: B

설명: 환경변수로 주입된 Secret의 위험: 1) kubectl describe pod 시 노출, 2) 애플리케이션 오류 로그에 포함 가능, 3) 프로세스 메모리 덤프 시 노출. 볼륨 마운트(파일) 방식이 더 안전합니다. tmpfs로 마운트하면 디스크에 기록되지 않습니다. 또한 Secret 변경 시 볼륨 마운트는 자동으로 업데이트되지만 환경변수는 Pod 재시작이 필요합니다.

A) 모든 컨테이너에 root 권한 부여 B) 컨테이너에 필요한 최소한의 Linux capabilities만 부여하고 불필요한 권한 제거 C) 모든 컨테이너를 privileged 모드로 실행 D) 모든 ServiceAccount에 ClusterAdmin 역할 부여

정답: B

설명: 컨테이너의 최소 권한 원칙: Linux capabilities를 사용하여 필요한 권한만 부여합니다. 예를 들어 웹서버는 NET_BIND_SERVICE(1024 미만 포트 바인딩)만 필요합니다. securityContext.capabilities.drop: ["ALL"]로 모든 capabilities를 제거한 후 필요한 것만 추가하는 것이 모범 사례입니다. Restricted PSS에서는 기본적으로 모든 capabilities 드롭이 필요합니다.

A) 이미지를 절대 업데이트하지 않는다 B) 매번 레지스트리에서 최신 이미지를 풀하여 변조된 로컬 캐시 이미지 사용을 방지 C) 이미지 다운로드를 비활성화한다 D) 노드 간 이미지를 공유한다

정답: B

설명: ImagePullPolicy: Always는 Pod 시작 시마다 레지스트리에서 이미지를 다운로드합니다. 보안 관점에서 로컬에 캐시된 변조된 이미지 사용을 방지합니다. latest 태그 대신 특정 다이제스트(SHA256)를 사용하면 이미지 무결성을 더 확실히 보장할 수 있습니다. 단, 레지스트리 장애 시 Pod 시작이 실패할 수 있습니다.

A) Pod 간 네트워크 트래픽을 제어 B) 자발적 중단(노드 드레인, 업그레이드) 시에도 최소 가용 Pod 수를 보장하여 가용성 유지 C) Pod의 보안 정책을 정의 D) 리소스 사용량 제한

정답: B

설명: PodDisruptionBudget(PDB)은 자발적 중단(voluntary disruption) 중에 동시에 중단될 수 있는 Pod의 최대 수를 제한합니다. minAvailable(최소 가용 Pod 수) 또는 maxUnavailable(최대 이용 불가 Pod 수)로 설정합니다. 노드 드레인, 클러스터 업그레이드, Pod 자동 재시작 시 서비스 가용성을 보장합니다.

A) etcd 저장 → Authenticating → Authorizing → Admission Control B) Authenticating → Authorizing → Mutating Admission → Validating Admission → etcd 저장 C) Admission Control → Authenticating → Authorizing → etcd 저장 D) Authorizing → Authenticating → etcd 저장 → Admission Control

정답: B

설명: API 요청 처리 순서: 1) Authentication(인증 - 누구인가?), 2) Authorization(인가 - 무엇을 할 수 있나? RBAC), 3) Mutating Admission Webhooks(요청 수정), 4) Object Schema Validation(오브젝트 스키마 검증), 5) Validating Admission Webhooks(요청 검증), 6) etcd 저장. Mutating이 Validating보다 먼저 실행되는 이유는 수정 후 최종 상태를 검증하기 위함입니다.

A) kubectl에서 자동으로 발급된다 B) CertificateSigningRequest(CSR) API를 통해 클러스터 CA로 서명한 인증서를 발급 C) 외부 인증 기관에서만 발급 가능하다 D) ServiceAccount 토큰으로 대체하면 인증서가 불필요하다

정답: B

설명: Kubernetes는 CertificateSigningRequest(CSR) 오브젝트를 통해 사용자 X.509 인증서 발급을 지원합니다. 사용자가 private key와 CSR을 생성하면, 클러스터 관리자가 kubectl certificate approve로 승인하여 클러스터 CA가 서명한 인증서를 발급합니다. 이 인증서를 kubeconfig에 추가하여 사용합니다.

A) 컨테이너의 CPU 사용량을 제한 B) 컨테이너 프로세스가 사용할 수 있는 Linux 시스템 콜을 제한하여 공격 표면 축소 C) 컨테이너 간 네트워크 암호화 D) 컨테이너 이미지 서명 검증

정답: B

설명: seccomp(Secure Computing Mode)는 프로세스가 사용할 수 있는 Linux 시스템 콜을 화이트리스트/블랙리스트로 제어합니다. 컨테이너에 seccompProfile: RuntimeDefault를 설정하면 대부분의 안전한 시스템 콜만 허용하고 위험한 호출을 차단합니다. Restricted PSS에서 seccomp 프로파일 설정이 요구됩니다. AppArmor와 함께 컨테이너 런타임 보안의 핵심입니다.

A) NetworkPolicy 오브젝트를 생성하면 자동으로 적용된다 B) NetworkPolicy를 실제로 강제하는 CNI 플러그인(Calico, Cilium 등)이 설치되어야 한다 C) kube-proxy가 NetworkPolicy를 자동으로 처리한다 D) Ingress Controller 설치가 필요하다

정답: B

설명: Kubernetes NetworkPolicy 오브젝트는 정책을 정의하는 API 리소스입니다. 하지만 실제 네트워크 규칙을 강제하는 것은 CNI(Container Network Interface) 플러그인이 담당합니다. NetworkPolicy를 지원하는 CNI: Calico, Cilium, Antrea, WeaveNet. 지원하지 않는 CNI: Flannel(기본적으로). CNI 없이는 NetworkPolicy 오브젝트가 있어도 아무 효과가 없습니다.

A) 컨테이너를 UID 0(root)으로 실행하여 컨테이너 탈출 위험이 증가한다 B) 컨테이너를 최소 권한 사용자로 실행한다 C) 컨테이너가 실행되지 않도록 차단한다 D) 보안에 영향이 없다

정답: A

설명: runAsUser: 0은 UID 0, 즉 root 사용자로 컨테이너를 실행합니다. root로 실행된 컨테이너는 컨테이너 탈출 취약점 발생 시 호스트 노드에서도 root 권한을 얻을 위험이 높습니다. 반드시 runAsNonRoot: true와 runAsUser: 1000 이상의 UID를 사용해야 합니다. Restricted PSS에서는 root 실행이 금지됩니다.

A) None B) Metadata C) Request D) RequestResponse

정답: D

설명: Kubernetes 감사 로그 레벨: None(기록 안 함), Metadata(요청자, 타임스탬프, 리소스, 동사만 기록), Request(메타데이터 + 요청 본문), RequestResponse(메타데이터 + 요청 본문 + 응답 본문). RequestResponse는 가장 상세하지만 로그 크기가 크게 증가합니다. Secret 관련 API는 최소한 Metadata 레벨로 기록하는 것이 좋습니다.

A) Pod의 네트워크 성능이 저하된다 B) Pod가 노드의 네트워크 인터페이스에 직접 접근하여 노드의 모든 네트워크 트래픽을 도청하거나 수정할 수 있다 C) 네트워크 정책이 자동으로 강화된다 D) 보안 위험이 없다

정답: B

설명: hostNetwork: true는 Pod를 노드의 네트워크 네임스페이스에서 실행합니다. Pod가 노드의 모든 네트워크 인터페이스에 직접 접근할 수 있어 노드 네트워크 트래픽 도청, 포트 충돌, 네트워크 설정 변경이 가능합니다. 시스템 수준 Pod(CNI 등)에서만 사용해야 합니다. Restricted PSS에서는 금지됩니다.

A) 모든 사용자에게 secrets: ["*"] 권한 부여 B) 애플리케이션이 필요한 특정 Secret의 이름을 명시하여 get 권한만 부여 C) 모든 Namespace에서 Secret을 list할 수 있는 ClusterRole 부여 D) ServiceAccount에 cluster-admin 권한 부여

정답: B

설명: Secret RBAC 최소 권한 원칙: 특정 Secret 이름을 resourceNames로 지정하여 해당 Secret만 get 또는 watch할 수 있도록 설정합니다. list와 watch 권한은 모든 Secret을 조회할 수 있어 위험합니다. Namespace 수준 Role을 사용하여 클러스터 전체 접근을 제한합니다.

A) 빌드 속도를 높이기 위해 B) 취약한 이미지가 프로덕션에 배포되기 전에 조기에 탐지하고 차단 C) 컨테이너 이미지 크기를 줄이기 위해 D) Kubernetes 클러스터 설정을 자동화하기 위해

정답: B

설명: CI/CD 파이프라인에서 이미지 취약점 스캐닝(Trivy, Grype, Snyk 등)을 통합하면 "Shift Left Security"를 실현합니다. 개발 초기 단계에서 취약점을 발견하면 수정 비용이 낮고, 프로덕션 침해 위험을 크게 줄일 수 있습니다. CVSS 점수 임계값을 설정하여 High/Critical 취약점이 있는 이미지 빌드를 자동으로 차단할 수 있습니다.

A) 새 버전은 성능만 향상시킨다 B) 새 버전에는 알려진 CVE 보안 취약점 패치가 포함되어 있다 C) 업그레이드는 보안과 관련이 없다 D) 업그레이드는 항상 보안을 약화시킨다

정답: B

설명: Kubernetes는 정기적으로 보안 패치를 포함한 새 버전을 릴리스합니다. 구버전 Kubernetes 클러스터는 알려진 CVE 취약점에 노출될 수 있습니다. Kubernetes의 지원 정책은 최신 3개 마이너 버전만 유지보수 패치를 제공합니다. 클러스터를 지원되는 버전으로 유지하는 것이 보안의 기본입니다.

A) kubeconfig 파일을 Git 저장소에 커밋한다 B) 파일 권한 제한(chmod 600), 암호화된 스토리지 사용, 최소 권한 kubeconfig 사용 C) 모든 팀원이 동일한 관리자 kubeconfig를 공유한다 D) kubeconfig 파일은 보안 위험이 없다

정답: B

설명: kubeconfig는 클러스터 접근 자격증명을 포함하며, 특히 cluster-admin 권한의 kubeconfig는 매우 민감합니다. 보안 모범 사례: chmod 600 ~/.kube/config(소유자만 읽기/쓰기), Git에 절대 커밋 금지(.gitignore에 추가), 각 팀원에게 최소 권한 kubeconfig 발급, 자격증명 만료 정기 점검. 팀 공유 계정보다 개인 서비스 계정 사용을 권장합니다.