퀴즈: mTLS 와 인가

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

1. Istio 에서 워크로드의 신원은 무엇을 기준으로 만들어지나요?

   1. 쿠버네티스 서비스 어카운트
   2. 파드가 떠 있는 노드의 호스트명
   3. 파드에 할당된 클러스터 IP 주소
   4. 파드 이름과 네임스페이스 조합

2. `spec: {}` 만 있는 AuthorizationPolicy 가 전면 거부가 되는 이유는?

   1. ALLOW 정책이 존재하지만 매칭 규칙이 없어, 화이트리스트에 아무도 없는 상태가 되기 때문
   2. `action` 을 적지 않은 정책은 기본값이 DENY 로 해석되어 전부 막히기 때문
   3. `selector` 가 없는 정책은 네임스페이스 전체를 거부 대상으로 잡기 때문
   4. 규칙이 비어 있으면 CUSTOM 으로 해석되어 없는 외부 인가 서버를 찾기 때문

3. PeerAuthentication 정책이 메시 전역, 네임스페이스, 워크로드 세 곳에 각각 있습니다. 특정 워크로드에 적용되는 것은?

   1. 메시 전역 정책
   2. 워크로드 정책
   3. 네임스페이스 정책
   4. 세 정책의 논리곱

4. RequestAuthentication 만 배포하고 AuthorizationPolicy 를 두지 않았습니다. JWT 없이 온 요청은?

   1. AuthorizationPolicy 가 없다며 적용이 거부된다
   2. 토큰이 없다는 이유로 401 이 반환된다
   3. 인증되지 않은 상태로 통과한다
   4. 인가 대상이 아니라 403 으로 거부된다

5. AuthorizationPolicy 의 평가 순서로 옳은 것은?

   1. 선언 순서대로
   2. CUSTOM → DENY → ALLOW
   3. ALLOW → DENY → CUSTOM
   4. DENY → ALLOW → CUSTOM

6. PERMISSIVE 상태에서 평문으로 들어온 요청이 `principals` 조건에 매칭되지 않는 이유는?

   1. principal 은 mTLS 인증서에서 나오는데 평문 연결에는 인증서가 없기 때문
   2. 평문 요청에서는 프록시가 신원을 담은 헤더를 모두 지워 버리기 때문
   3. PERMISSIVE 모드에서는 인가 평가가 통째로 건너뛰어지기 때문
   4. 인증서 없이 들어온 요청은 규칙 평가 전에 DENY 로 분류되기 때문

7. 운영 메시에 기본 거부 정책을 넣기 전에 가장 적절한 절차는?

   1. AUDIT 액션이나 dry-run 으로 먼저 '켰다면 무엇이 거부됐을지'를 관찰한다
   2. 네임스페이스를 새로 파고 거기에만 정책을 얹어 배포한 뒤 결과를 비교한다
   3. 트래픽이 가장 적은 야간에 적용하고 문제가 보이면 즉시 롤백한다
   4. 모든 서비스의 재시도 횟수를 늘려 일시적인 거부를 흡수하게 한다