퀴즈: 플랫폼 보안 — 메시, PKI, 관측성

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

1. Istio 에서 mTLS 를 STRICT 로 켜고 AuthorizationPolicy 를 하나도 두지 않았을 때 메시 안 워크로드 사이의 요청은?

   1. 인증서가 있는 클라이언트라도 정책이 없으므로 모두 거부된다
   2. 유효한 인증서를 가진 어떤 워크로드의 요청이든 허용된다
   3. 같은 네임스페이스의 워크로드끼리만 허용되고 다른 네임스페이스는 거부된다
   4. HTTP 요청은 허용되고 gRPC 와 TCP 요청은 거부된다

2. Istio 사이드카가 가로채지 못하거나 보호하지 못하는 트래픽으로 모범 사례 문서가 든 것은?

   1. HTTPS 로 이미 암호화된 트래픽은 사이드카가 다시 mTLS 로 감싸지 못한다
   2. 다른 네임스페이스로 가는 트래픽은 사이드카가 라우팅하지 못한다
   3. gRPC 트래픽은 HTTP/2 기반이라 사이드카가 해석하지 못한다
   4. UDP·ICMP 는 리다이렉션되지 않고, 22번 같은 포트는 inbound 캡처에서 빠지며, 애플리케이션이 리다이렉션 규칙을 지워 우회할 수 있다

3. kubeadm 클러스터의 세 CA 와 그 역할을 바르게 짝지은 것은?

   1. kubernetes-ca 는 일반 CA, etcd-ca 는 etcd 관련 기능 전부, front-proxy-ca 는 front-end proxy 용
   2. kubernetes-ca 는 노드 인증서, etcd-ca 는 서비스 어카운트 토큰, front-proxy-ca 는 Ingress TLS
   3. kubernetes-ca 는 API 서버 전용, etcd-ca 는 kubelet 전용, front-proxy-ca 는 kube-proxy 전용
   4. 세 CA 는 이름만 다르고 같은 키 쌍을 공유하므로 역할 구분이 없다

4. kubeadm 이 만든 클라이언트 인증서의 만료와 갱신에 대해 문서가 설명한 내용은?

   1. 10년 뒤 만료되며 CA 와 함께 kubeadm reset 으로만 갱신할 수 있다
   2. 만료되지 않으며 kubelet 이 자동으로 교체하므로 관리자가 신경 쓸 필요가 없다
   3. 1년 뒤 만료되며 컨트롤 플레인 업그레이드 때 자동 갱신되고, 수동으로는 kubeadm certs renew 뒤 컨트롤 플레인 파드를 재시작해야 한다
   4. 90일 뒤 만료되며 cert-manager 를 설치해야만 갱신된다

5. 감사 정책 파일의 여러 규칙 중 한 이벤트에 적용되는 수준은 어떻게 정해지나?

   1. 맞는 규칙들 중 가장 상세한 수준(RequestResponse 에 가까운 것)이 적용된다
   2. 규칙을 순서대로 비교해 첫 번째로 맞는 규칙의 수준이 적용된다
   3. 맞는 규칙들의 수준을 합쳐 요청 본문과 응답 본문을 모두 기록한다
   4. 마지막에 적힌 규칙이 앞의 규칙을 덮어쓴다

6. 누군가 파드 안에서 셸을 띄웠는데 감사 로그에는 pods/exec 요청이 없고 Falco 경고만 있다. 이 신호의 조합이 가리키는 것은?

   1. 감사 정책이 exec 를 Metadata 수준으로 기록해 요청이 누락된 것이므로 정책만 고치면 된다
   2. Falco 규칙이 오탐한 것이므로 감사 로그가 없는 이상 침해로 볼 수 없다
   3. API 서버가 감사 이벤트를 메모리 부족으로 버린 것이므로 API 서버를 재시작하면 된다
   4. kubelet API·런타임 소켓·static Pod 처럼 API 서버를 거치지 않는 경로가 쓰였을 가능성이 있다