퀴즈: 런타임 보안과 감사

문항 7개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

1. 감사 정책의 rules 는 어떻게 평가되는가?

   1. 위에서부터 평가해 처음 매칭된 규칙 하나만 적용한다
   2. 모든 규칙을 평가해 가장 높은 레벨을 적용한다
   3. 아래에서부터 평가해 마지막 매칭 규칙을 적용한다
   4. 규칙 순서와 무관하게 가장 구체적인 규칙을 적용한다

2. Secret 리소스에 level: RequestResponse 를 지정하면 생기는 문제는?

   1. 감사 로그 크기가 커질 뿐 보안 문제는 없다
   2. API 서버가 Secret 조회를 거부하게 된다
   3. etcd 암호화가 비활성화된다
   4. 감사 로그 파일 안에 시크릿 값이 그대로 기록된다

3. 감사 로그가 디스크를 채워 API 서버가 멈추는 것을 막는 플래그 조합은?

   1. --audit-policy-file, --audit-log-path
   2. --audit-log-maxage, --audit-log-maxbackup, --audit-log-maxsize
   3. --audit-webhook-config-file 하나면 충분하다
   4. --audit-log-format=json

4. Falco 가 감사 로그로는 탐지할 수 없는 것을 잡아내는 이유는?

   1. 감사 로그보다 저장 주기가 짧기 때문
   2. etcd 를 직접 읽기 때문
   3. 커널 시스템 콜을 관찰하므로 API 서버를 거치지 않은 행동도 보이기 때문
   4. kubelet 의 읽기 전용 포트를 감시하기 때문

5. 노드에서 crictl 을 쓸 때 지켜야 할 경계로 옳은 것은?

   1. 진단에는 쓰되 상태 변경은 kubectl 로 한다. crictl 로 지우면 kubelet 인식과 실제 상태가 어긋난다
   2. 컨테이너를 다시 띄우고 싶을 때 crictl rm 으로 지우는 것이 가장 빠르다
   3. crictl 은 API 서버를 거치므로 kubectl 과 항상 같은 결과를 준다
   4. crictl 은 이미지 조회에만 쓸 수 있다

6. crictl 명령 하나가 아무 일도 하지 않는데 십수 초씩 걸린다. 가장 유력한 원인은?

   1. 노드의 디스크 I/O 가 포화됐다
   2. 런타임 엔드포인트를 지정하지 않아 알려진 소켓 후보를 차례로 시도하고 있다
   3. 감사 로그 레벨이 RequestResponse 로 설정돼 있다
   4. 컨테이너 수가 너무 많다

7. 침해된 파드를 발견했을 때 올바른 대응 순서는?

   1. 즉시 파드를 삭제하고 새 이미지로 재배포한다
   2. 노드를 재부팅해 런타임 상태를 초기화한다
   3. 증거 수집 → NetworkPolicy 로 격리 → 침해 범위 파악 → 취약점 수정 후 재배포
   4. 클러스터 전체를 새로 만들고 백업에서 복원한다