Quiz: trace the conditions that opened the door

orders를 허용하던 정책에 JWT 주체를 허용하는 별도 ALLOW를 추가하자 낯선 워크로드도 통과했습니다. 가장 직접적인 설명은?

• 모든 허용 정책이 교집합으로 처리됐지만 신원 캐시가 갱신되지 않았다
• 허용 정책 중 하나라도 일치하는 경로가 생겨 JWT만으로도 허용됐다
• JWT 검증이 성공하면 어떤 DENY 정책도 자동으로 비활성화된다
• 정책을 추가한 네임스페이스에서 mTLS가 자동으로 평문으로 바뀌었다

같은 from.source에 principals와 requestPrincipals를 함께 둔 이유는?

• 두 필드 중 문자열이 더 긴 신원을 선택하기 위해
• 토큰이 없으면 워크로드 신원을 대신 넣기 위해
• 검증된 워크로드와 검증된 JWT 주체를 함께 요구하기 위해
• 워크로드 신원 대신 JWT 서명 키를 저장하기 위해

scoped에서 토큰 없는 8080은 403, 8081은 200입니다. 가장 정확한 완료 보고는?

• JWT 없음 DENY가 지정한 8080 범위에 작동했고 8081까지 보호한 것은 아니다
• 동일 파드의 모든 포트가 JWT 검증을 강제하므로 8081도 안전하다
• 8081은 HTTP가 아니므로 이 실습의 응답 코드에는 의미가 없다
• 403이 한 번 나왔으므로 다른 출발지와 경로의 시험은 생략해도 된다

두 요청이 모두 403인데 하나는 audience 오류, 다른 하나는 RBAC 거부 본문을 냅니다. 다음 조사는?

• 모든 403은 동일한 인가 오류이므로 ALLOW 정책만 넓힌다
• JWT 서명 검사를 끄고 응답 코드가 바뀌는지만 확인한다
• 두 요청 모두 만료로 분류하고 토큰 유효기간만 늘린다
• 코드와 본문을 보존하고 JWT 검증 설정과 인가 조건을 나눠 대조한다

YAML은 정답인데 채점이 실제 적용 정책과 다르다고 합니다. 무엇을 먼저 확인해야 하나요?

• 파일 내용을 서버가 자동으로 읽을 때까지 브라우저만 새로 고친다
• 올바른 네임스페이스에 apply했는지 확인하고 실제 객체와 전파된 응답을 대조한다
• 채점에 성공하도록 저장된 JSON의 HTTP 코드만 200으로 바꾼다
• 다른 정책과 충돌하지 않도록 기존 ALLOW와 DENY를 전부 삭제한다

intersection이 payments-api와 other-api를 모두 허용하다 payments-api 하나로 좁혀졌습니다. 반드시 다시 볼 요청은?

• 정상 결제용 토큰 하나만 확인하고 다른 audience 요청은 생략한다
• 모든 JWT를 제거한 뒤 HTTP 포트가 열려 있는지만 확인한다
• 정상 결제용은 계속 성공하고 다른 API용은 실제로 거부되는지 함께 확인한다
• 정책 파일 이름이 길어졌는지 보고 검증 강화 여부를 판단한다