クイズ: プラットフォームセキュリティ — メッシュ、PKI、可観測性

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

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

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

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

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

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

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

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

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

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

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

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