クイズ: ワークロードのセキュリティ

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

• spiffe://cluster.local/prod/checkout
• spiffe://prod/sa/checkout
• spiffe://cluster.local/ns/prod/sa/checkout
• spiffe://cluster.local/pod/prod/checkout

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

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

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

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

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

• DISABLE
• STRICT
• PERMISSIVE
• 충돌로 정책이 무시된다

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

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

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

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

orders 신원의 POST /v1/charges를 허용하던 정책에, 같은 대상의 JWT 주체만 허용하는 ALLOW를 별도로 추가했습니다. 왜 JWT 없는 orders가 계속 통과할까요?

• ALLOW들은 합집합이라 기존 orders 조건으로도 통과하며, JWT 없음 DENY나 같은 규칙의 조건 결합이 필요하다
• ALLOW들은 교집합이지만 앞 정책의 생성 시간이 빨라 JWT 조건이 생략되므로 생성 순서를 뒤집어야 한다
• RequestAuthentication은 처음 온 요청만 검증하므로 인증서와 세션 캐시를 삭제하고 다시 요청해야 한다
• 같은 source에 두 종류의 신원을 쓸 수 없으므로 JWT 허용 정책을 다른 네임스페이스로 옮겨야 한다