퀴즈: 워크로드 보안

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

1. 트러스트 도메인이 cluster.local 이고, prod 네임스페이스에서 서비스어카운트 checkout 으로 뜬 파드의 SPIFFE ID 는?

   1. spiffe://cluster.local/prod/checkout
   2. spiffe://prod/sa/checkout
   3. spiffe://cluster.local/ns/prod/sa/checkout
   4. spiffe://cluster.local/pod/prod/checkout

2. 지금까지 인가 정책이 하나도 없던 워크로드에 ALLOW 정책 하나를 추가했습니다. 그 정책에 매칭되지 않는 기존 트래픽은?

   1. 그대로 허용된다 — ALLOW 정책은 허용만 추가할 뿐이므로
   2. 거부된다 — ALLOW 정책이 존재하는 순간 그 워크로드는 화이트리스트 모드가 되므로
   3. 경고 로그만 남고 허용된다
   4. DENY 정책이 함께 있어야만 거부된다

3. PERMISSIVE 상태에서 `principals` 조건이 있는 ALLOW 정책을 걸었더니 모든 요청이 403 입니다. 가장 유력한 원인은?

   1. PERMISSIVE 모드에서는 AuthorizationPolicy 가 평가되지 않는다
   2. principals 는 네임스페이스 단위로만 쓸 수 있다
   3. 평문으로 들어온 요청에는 principal 이 비어 있어 principals 조건에 매칭되지 않는다
   4. RequestAuthentication 이 없으면 principals 가 채워지지 않는다

4. 메시 전역은 STRICT, payments 네임스페이스는 PERMISSIVE, payments 안의 legacy 워크로드는 DISABLE 인 PeerAuthentication 이 모두 존재합니다. legacy 워크로드에 적용되는 모드는?

   1. DISABLE
   2. STRICT
   3. PERMISSIVE
   4. 충돌로 정책이 무시된다

5. RequestAuthentication 으로 JWT 검증을 설정했습니다. 토큰이 아예 없는 요청은 어떻게 처리되나요?

   1. 401 로 거부된다
   2. issuer 가 기본값으로 채워져 통과한다
   3. 수락되지만 인증되지 않은 요청으로 취급된다
   4. jwksUri 조회 실패로 503 이 된다

6. 워크로드 인증서가 24시간마다 갱신되는데도 커넥션 드레인이나 파드 재시작이 필요 없는 이유는?

   1. 인증서를 파일로 마운트하고 kubelet 이 자동 갱신하기 때문
   2. Envoy 가 만료된 인증서를 유예 기간 동안 계속 사용하기 때문
   3. istiod 가 대신 TLS 를 종료해 주기 때문
   4. istio-agent 가 SDS 로 Envoy 에 인증서를 전달하므로 프로세스 재시작 없이 교체되기 때문