Kubernetes 환경에서 Falco의 주요 역할은 무엇입니까?

A) 컨테이너 이미지의 취약점을 스캔한다 B) 런타임에 시스템 콜을 모니터링하여 비정상적인 활동을 감지하고 경고한다 C) 네트워크 정책을 자동 생성한다 D) Pod의 리소스 사용량을 제한한다

정답: B

Falco는 Linux 커널의 시스템 콜을 실시간으로 모니터링하는 런타임 보안 도구입니다. 컨테이너 내 쉘 실행, 민감한 파일 읽기, 네트워크 연결 등 비정상적인 활동을 감지하여 경고합니다. eBPF 또는 커널 모듈을 사용하여 동작합니다.

Falco 규칙의 condition 필드는 어떤 목적으로 사용됩니까?

A) 경고 메시지의 형식을 정의한다 B) 시스템 콜 이벤트를 필터링하는 조건식을 정의하여 어떤 이벤트가 규칙에 매칭되는지 결정한다 C) 규칙의 우선순위를 설정한다 D) 출력 채널을 지정한다

정답: B

condition은 Sysdig 필터 문법을 사용하여 이벤트 매칭 조건을 정의합니다. 예를 들어 container.id != host and proc.name = bash는 컨테이너 내에서 bash 프로세스가 실행되는 것을 감지합니다. syscall, process, file, network 관련 필드를 조합할 수 있습니다.

Falco 규칙으로 컨테이너 내부에서 쉘(bash, sh)이 실행되는 것을 감지하려면 어떤 condition을 사용해야 합니까?

A) fd.name contains /bin/bash B) container.id != host and proc.name in (bash, sh, zsh) and evt.type = execve C) k8s.pod.name exists D) syscall.type = open

정답: B

container.id != host로 컨테이너 환경을 필터링하고, proc.name으로 쉘 프로세스를 지정하며, evt.type = execve로 프로세스 실행 이벤트를 감지합니다. 이 조합으로 컨테이너 내 대화형 쉘 접근을 효과적으로 탐지할 수 있습니다.

Trivy를 사용하여 컨테이너 이미지의 HIGH/CRITICAL 취약점만 확인하려면?

A) trivy image IMAGE_NAME 만 실행하면 된다 B) trivy image --severity HIGH,CRITICAL IMAGE_NAME으로 심각도를 필터링한다 C) trivy scan --level=high 명령을 사용한다 D) docker scan 명령만 사용 가능하다

정답: B

trivy image --severity HIGH,CRITICAL 플래그를 사용하면 지정된 심각도의 취약점만 표시합니다. --exit-code 1을 추가하면 취약점이 발견될 때 CI/CD 파이프라인을 실패시킬 수 있습니다. --ignore-unfixed로 수정 가능한 취약점만 표시할 수도 있습니다.

Trivy와 Grype 모두 이미지 스캐닝 도구입니다. 주요 차이점은?

A) 둘 다 완전히 동일한 도구이다 B) Trivy는 이미지, 파일시스템, Git 저장소, IaC 등 다양한 대상을 스캔하고, Grype는 주로 이미지와 SBOM 기반 취약점 스캔에 특화되어 있다 C) Grype는 런타임 보안 도구이다 D) Trivy는 네트워크 스캐닝 도구이다

정답: B

Trivy는 Aqua Security가 개발한 종합 보안 스캐너로 이미지, 파일시스템, IaC, Secret 스캔 등을 지원합니다. Grype는 Anchore가 개발한 도구로 이미지 및 SBOM 기반 취약점 스캔에 집중합니다. 둘 다 CKS 시험에서 다룰 수 있는 도구입니다.

OPA Gatekeeper에서 ConstraintTemplate의 역할은 무엇입니까?

A) Kubernetes 리소스를 직접 생성한다 B) Rego 언어로 작성된 정책 로직을 정의하며, 이를 기반으로 Constraint 리소스를 생성할 수 있게 한다 C) NetworkPolicy를 자동 생성한다 D) RBAC 규칙을 관리한다

정답: B

ConstraintTemplate은 정책의 스키마와 Rego 로직을 정의합니다. 이를 기반으로 Constraint 리소스를 생성하면 특정 조건에서 리소스 생성/수정을 제한할 수 있습니다. 예를 들어 privileged 컨테이너 금지, 특정 레지스트리만 허용 등의 정책을 구현합니다.

ConstraintTemplate과 Constraint의 관계에 대해 올바른 설명은?

A) Constraint가 정책 로직을 포함한다 B) ConstraintTemplate이 정책 로직(Rego)을 정의하고, Constraint가 해당 템플릿의 인스턴스로 구체적인 매개변수와 적용 범위를 지정한다 C) 둘은 독립적이며 관계가 없다 D) Constraint는 네임스페이스 단위로만 적용된다

정답: B

ConstraintTemplate은 재사용 가능한 정책 템플릿(Rego 코드 포함)이고, Constraint는 해당 템플릿의 인스턴스입니다. Constraint에서 match 필드로 적용 대상(네임스페이스, 리소스 종류 등)을 지정하고, parameters로 정책의 구체적인 값을 설정합니다.

Gatekeeper Constraint를 dry-run 모드로 설정하면?

A) 정책이 완전히 비활성화된다 B) 정책 위반을 감지하고 로그에 기록하지만, 실제로 리소스 생성/수정을 차단하지는 않는다 C) 정책이 강제 적용된다 D) 테스트 네임스페이스에만 적용된다

정답: B

Constraint의 enforcementAction을 dryrun으로 설정하면 정책 위반 시 리소스를 차단하지 않고 위반 사항만 기록합니다. 새 정책을 프로덕션에 적용하기 전에 영향도를 파악하는 데 유용합니다. deny는 차단, warn은 경고만 표시합니다.

컨테이너 이미지를 태그 대신 다이제스트(sha256 해시)로 참조하는 이유는?

A) 이미지 다운로드 속도가 빨라진다 B) 동일한 태그에 다른 이미지가 푸시되는 태그 변조를 방지하고, 정확히 검증된 이미지를 사용하도록 보장한다 C) 이미지 크기가 줄어든다 D) 레지스트리 인증이 불필요해진다

정답: B

태그는 변경 가능하므로 같은 태그에 다른 이미지가 푸시될 수 있습니다(태그 변조). 다이제스트는 이미지 내용의 해시값이므로 내용이 변경되면 다이제스트도 변경됩니다. 이를 통해 서명된 정확한 이미지를 사용하는 것을 보장할 수 있습니다.

클러스터에서 특정 컨테이너 레지스트리(예: myregistry.io)의 이미지만 사용하도록 제한하려면?

A) NetworkPolicy로 레지스트리 접근을 차단한다 B) ConstraintTemplate에서 이미지 이름 접두사를 검사하는 Rego 정책을 작성하고, Constraint에서 허용 레지스트리 목록을 지정한다 C) kubelet 설정에서 레지스트리를 제한한다 D) Pod에 annotation을 추가한다

정답: B

ConstraintTemplate에서 컨테이너 이미지의 접두사가 허용 목록에 있는지 검사하는 Rego 코드를 작성합니다. Constraint에서 parameters로 허용 레지스트리 목록(예: myregistry.io)을 지정하면, 해당 레지스트리 이외의 이미지를 사용하는 Pod 생성이 거부됩니다.

Kubernetes에서 AppArmor 프로파일을 컨테이너에 적용하려면?

A) Pod의 securityContext에 직접 설정한다 B) 컨테이너의 securityContext.appArmorProfile 필드에 프로파일 타입과 이름을 지정한다(Kubernetes 1.30+) C) ConfigMap에 프로파일을 저장한다 D) 클러스터 전체에 한 번만 설정하면 된다

정답: B

Kubernetes 1.30+에서는 securityContext.appArmorProfile 필드를 사용합니다. type에 Localhost, RuntimeDefault 등을 지정하고, Localhost인 경우 localhostProfile에 프로파일 이름을 지정합니다. 프로파일은 해당 노드에 미리 로드되어 있어야 합니다.

Seccomp(Secure Computing Mode) 프로파일의 주요 역할은?

A) 네트워크 트래픽을 필터링한다 B) 컨테이너가 사용할 수 있는 Linux 시스템 콜을 제한하여 공격 표면을 줄인다 C) 파일 시스템 접근을 제어한다 D) CPU 사용량을 제한한다

정답: B

Seccomp은 컨테이너 프로세스가 호출할 수 있는 시스템 콜을 제한합니다. RuntimeDefault 프로파일은 일반적으로 안전하지 않은 시스템 콜을 차단합니다. 커스텀 프로파일을 만들어 특정 앱에 필요한 시스템 콜만 허용할 수도 있습니다.

Pod의 모든 컨테이너에 RuntimeDefault Seccomp 프로파일을 적용하려면?

A) Node에 설정해야 한다 B) Pod spec의 securityContext.seccompProfile에 type: RuntimeDefault를 설정한다 C) DaemonSet으로 배포해야 한다 D) kube-proxy에 설정한다

정답: B

Pod 수준의 securityContext.seccompProfile에 type: RuntimeDefault를 설정하면 모든 컨테이너에 적용됩니다. 컨테이너 수준에서도 개별 설정이 가능하며 컨테이너 설정이 Pod 설정보다 우선합니다. Localhost 타입으로 커스텀 프로파일도 사용 가능합니다.

Kubernetes Pod Security Standards에서 정의하는 3가지 보안 레벨은?

A) Low, Medium, High B) Privileged, Baseline, Restricted C) Basic, Standard, Enterprise D) None, Default, Strict

정답: B

Pod Security Standards는 Privileged(제한 없음), Baseline(알려진 권한 상승 방지), Restricted(강화된 보안 모범 사례)의 3단계입니다. Baseline은 hostNetwork, privileged 컨테이너 등을 금지하고, Restricted는 추가로 root 실행, 권한 상승 등을 금지합니다.

특정 네임스페이스에 Restricted 수준의 Pod Security를 적용하려면?

A) CRD를 생성해야 한다 B) 네임스페이스에 pod-security.kubernetes.io/enforce: restricted 레이블을 추가한다 C) 클러스터 전체 설정만 가능하다 D) Pod에 annotation을 추가한다

정답: B

네임스페이스에 pod-security.kubernetes.io/enforce 레이블을 설정하면 해당 수준을 초과하는 Pod 생성이 거부됩니다. enforce 외에 audit(감사 로그 기록)과 warn(경고 표시) 모드도 있습니다. 버전도 함께 지정할 수 있습니다(예: pod-security.kubernetes.io/enforce-version: v1.30).

Kubernetes RuntimeClass는 어떤 목적으로 사용됩니까?

A) Pod의 네트워크 설정을 관리한다 B) 컨테이너 런타임 핸들러를 선택하여 gVisor, Kata Containers 등 다양한 격리 수준의 런타임을 Pod별로 지정할 수 있게 한다 C) 이미지 레지스트리를 관리한다 D) 스토리지 클래스를 관리한다

정답: B

RuntimeClass를 사용하면 Pod가 사용할 컨테이너 런타임을 선택할 수 있습니다. 예를 들어 보안이 중요한 워크로드에 gVisor나 Kata Containers를 사용하고, 일반 워크로드에는 runc를 사용하는 식으로 런타임을 분리할 수 있습니다.

gVisor와 Kata Containers의 격리 방식 차이는?

A) 둘 다 동일한 방식으로 동작한다 B) gVisor는 사용자 공간에서 Linux 커널을 에뮬레이션하고, Kata Containers는 경량 가상 머신(VM) 내에서 컨테이너를 실행한다 C) gVisor는 VM을 사용하고 Kata는 네임스페이스를 사용한다 D) 둘 다 eBPF 기반이다

정답: B

gVisor(runsc)는 Go로 작성된 사용자 공간 커널로, 시스템 콜을 인터셉트하여 제한된 커널 인터페이스를 제공합니다. Kata Containers는 각 컨테이너를 경량 VM에서 실행하여 하드웨어 레벨 격리를 제공합니다. 둘 다 runc보다 강한 격리를 제공하지만 오버헤드가 있습니다.

Pod가 gVisor 런타임을 사용하도록 설정하려면?

A) 노드에 레이블을 추가한다 B) RuntimeClass 리소스를 생성하고, Pod spec의 runtimeClassName 필드에 해당 RuntimeClass 이름을 지정한다 C) kubelet 설정만 변경한다 D) 모든 Pod가 자동으로 gVisor를 사용한다

정답: B

먼저 RuntimeClass 리소스를 생성하여 handler(예: runsc)를 지정합니다. 그런 다음 Pod spec의 runtimeClassName 필드에 해당 RuntimeClass 이름을 지정하면 해당 런타임으로 컨테이너가 실행됩니다. 노드에 해당 런타임이 설치되어 있어야 합니다.

AppArmor와 SELinux의 주요 차이점은?

A) 둘 다 동일한 방식으로 동작한다 B) AppArmor는 경로 기반 접근 제어를 사용하고, SELinux는 레이블 기반 접근 제어(MAC)를 사용한다 C) SELinux가 더 단순하다 D) AppArmor는 네트워크만 제어한다

정답: B

AppArmor는 파일 경로 기반으로 프로세스의 접근을 제어하며 프로파일 작성이 상대적으로 쉽습니다. SELinux는 모든 파일, 프로세스, 포트에 보안 레이블을 할당하여 레이블 기반 강제 접근 제어(MAC)를 수행하며, 더 세밀한 제어가 가능하지만 복잡합니다.

Pod Security Admission에서 특정 사용자나 네임스페이스를 정책에서 제외하려면?

A) 제외는 불가능하다 B) PodSecurityConfiguration의 exemptions 필드에서 usernames, runtimeClasses, namespaces를 지정하여 예외를 설정한다 C) 네임스페이스를 삭제해야 한다 D) RBAC로만 제어 가능하다

정답: B

PodSecurityConfiguration(AdmissionConfiguration 파일)의 exemptions에서 특정 사용자, RuntimeClass, 네임스페이스를 정책 적용에서 제외할 수 있습니다. 시스템 컴포넌트나 특수한 워크로드가 보안 제한을 우회해야 할 때 사용합니다.

Kubernetes 감사 정책에서 omitStages 필드의 용도는?

A) 특정 리소스를 로깅에서 제외한다 B) RequestReceived 등 특정 요청 처리 단계를 로깅에서 제외하여 로그 볼륨을 줄인다 C) 감사 로그를 비활성화한다 D) 특정 사용자를 제외한다

정답: B

omitStages를 사용하면 RequestReceived, ResponseStarted, ResponseComplete, Panic 중 특정 단계를 로깅에서 제외할 수 있습니다. 예를 들어 RequestReceived를 제외하면 요청 수신 시점의 로그를 생략하여 로그 볼륨을 줄일 수 있습니다.

Kubernetes API 서버 감사 로그의 백엔드 종류는?

A) 파일 백엔드만 지원한다 B) 로그 백엔드(파일)와 Webhook 백엔드(외부 서비스)를 지원한다 C) 데이터베이스 백엔드만 지원한다 D) syslog만 지원한다

정답: B

Kubernetes는 로그 백엔드(--audit-log-path로 파일에 기록)와 Webhook 백엔드(--audit-webhook-config-file로 외부 HTTP 서비스에 전송)를 지원합니다. 두 백엔드를 동시에 사용할 수 있으며, 각각 별도의 정책 설정이 가능합니다.

kubelet의 클라이언트 인증서가 자동으로 순환되도록 설정하려면?

A) 수동으로만 갱신 가능하다 B) kubelet 설정에서 rotateCertificates를 true로 설정하고, controller-manager에서 CSR 자동 승인을 활성화한다 C) etcd에서 인증서를 관리한다 D) 인증서는 만료되지 않는다

정답: B

kubelet의 rotateCertificates: true 설정은 인증서 만료 전에 자동으로 CSR(Certificate Signing Request)을 생성합니다. kube-controller-manager의 csrsigning 컨트롤러가 CSR을 자동 승인하면 새 인증서가 발급됩니다. serverTLSBootstrap도 함께 설정하면 서빙 인증서도 자동 순환됩니다.

etcd에 저장되는 Secret을 암호화하려면?

A) Secret을 base64로 인코딩하면 암호화된다 B) EncryptionConfiguration 파일을 생성하고 kube-apiserver에 --encryption-provider-config 플래그로 지정한다 C) etcd 자체가 자동으로 암호화한다 D) Secret 대신 ConfigMap을 사용한다

정답: B

EncryptionConfiguration 파일에서 암호화 프로바이더(aescbc, aesgcm, secretbox 등)와 키를 정의합니다. kube-apiserver 시작 시 --encryption-provider-config로 이 파일을 지정하면 지정된 리소스(secrets 등)가 etcd에 암호화되어 저장됩니다. base64는 인코딩일 뿐 암호화가 아닙니다.

Secrets 암호화에서 KMS 프로바이더를 사용하는 이점은?

A) 설정이 더 간단하다 B) 암호화 키가 외부 KMS에서 관리되어 키 관리가 중앙화되고, 키 순환이 API 서버 재시작 없이 가능하다 C) 암호화 성능이 떨어진다 D) 추가 인프라가 불필요하다

정답: B

KMS 프로바이더를 사용하면 DEK(Data Encryption Key)는 로컬에서 생성하고, DEK를 암호화하는 KEK(Key Encryption Key)는 외부 KMS(AWS KMS, GCP KMS, HashiCorp Vault 등)에서 관리합니다. 키 순환 시 API 서버 재시작이 불필요하며 키 관리가 중앙화됩니다.

CIS(Center for Internet Security) Kubernetes Benchmark는 무엇입니까?

A) Kubernetes 성능 벤치마크 도구이다 B) Kubernetes 클러스터의 보안 설정에 대한 모범 사례 가이드라인으로, 컨트롤 플레인, 노드, 정책 등의 보안 구성을 검사한다 C) 네트워크 성능 테스트 도구이다 D) 이미지 빌드 가이드이다

정답: B

CIS Benchmark는 Kubernetes 컴포넌트(API 서버, etcd, kubelet, 스케줄러 등)의 보안 설정을 점검하는 가이드라인입니다. kube-bench 도구를 사용하여 자동으로 검사할 수 있으며, 각 항목에 대해 통과/실패/경고 결과를 제공합니다.

kube-bench는 어떤 목적으로 사용됩니까?

A) Kubernetes 클러스터의 부하 테스트를 수행한다 B) CIS Kubernetes Benchmark에 따라 클러스터 보안 설정을 자동으로 검사하고 결과를 보고한다 C) 이미지 취약점을 스캔한다 D) 런타임 보안을 모니터링한다

정답: B

kube-bench는 Aqua Security가 개발한 오픈소스 도구로, CIS Benchmark 항목을 자동으로 검사합니다. 컨트롤 플레인, 워커 노드, etcd 등의 설정을 점검하고, 실패 항목에 대한 수정 방법을 안내합니다. Job으로 클러스터 내에서 실행할 수 있습니다.

cosign을 사용하여 컨테이너 이미지에 서명하는 목적은?

A) 이미지 크기를 줄인다 B) 이미지의 출처와 무결성을 검증하여 승인된 빌드 파이프라인에서 생성된 이미지만 배포되도록 보장한다 C) 이미지 다운로드 속도를 높인다 D) 이미지의 취약점을 제거한다

정답: B

cosign(Sigstore 프로젝트)으로 이미지에 서명하면, 배포 시 서명을 검증하여 이미지가 신뢰할 수 있는 소스에서 빌드되었고 변조되지 않았음을 확인할 수 있습니다. 정책 엔진(Kyverno, OPA 등)과 연동하면 서명되지 않은 이미지의 배포를 자동 차단할 수 있습니다.

컨테이너 이미지의 SBOM을 생성하는 이유는?

A) 이미지 빌드를 자동화한다 B) 이미지에 포함된 모든 소프트웨어 패키지와 의존성 목록을 제공하여 취약점 관리와 라이선스 준수를 지원한다 C) 이미지를 압축한다 D) 이미지 레이어를 최적화한다

정답: B

SBOM은 컨테이너 이미지에 포함된 모든 패키지, 라이브러리, 의존성의 상세 목록입니다. 새 취약점이 발견되었을 때 영향받는 이미지를 빠르게 파악하고, 라이선스 준수 여부를 확인하는 데 활용됩니다. Syft, Trivy 등으로 생성할 수 있습니다.

Kubernetes 공급망 보안에서 admission controller를 활용하는 방법은?

A) 이미지 빌드를 담당한다 B) 이미지 서명 검증, 허용 레지스트리 검사, 취약점 스캔 결과 확인 등을 배포 시점에 자동으로 수행하여 미승인 이미지의 배포를 차단한다 C) CI/CD 파이프라인을 관리한다 D) 소스 코드를 스캔한다

정답: B

Validating Admission Webhook이나 정책 엔진(Kyverno, OPA Gatekeeper)을 사용하여 Pod 생성 시 이미지 서명 검증, 허용된 레지스트리 확인, 취약점 스캔 결과 기반 차단, 다이제스트 사용 강제 등의 검사를 자동으로 수행합니다. 이를 통해 공급망 공격을 방어할 수 있습니다.