Quiz: mTLS and Authorization

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

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

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

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

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

• 메시 전역 정책
• 워크로드 정책
• 네임스페이스 정책
• 세 정책의 논리곱

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

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

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

• 선언 순서대로
• CUSTOM → DENY → ALLOW
• ALLOW → DENY → CUSTOM
• DENY → ALLOW → CUSTOM

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

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

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

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