クイズ: ランタイムセキュリティと監査

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

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

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

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

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

• --audit-policy-file, --audit-log-path
• --audit-log-maxage, --audit-log-maxbackup, --audit-log-maxsize
• --audit-webhook-config-file 하나면 충분하다
• --audit-log-format=json

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

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

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

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

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

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

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

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