クイズ: セキュリティとポリシー執行

CI에서 서명 없는 이미지를 거절하지만 다른 배포 경로도 있습니다. 가장 적절한 보완은 무엇입니까?

• CI 로그의 보존 기간을 늘리고 모든 API 경로도 차단됐다고 판단합니다
• 기존 자원을 점검한 보고서로 이후 API 요청의 거절 여부를 대신합니다
• 어드미션 범위와 예외를 검토하고 허용·거절 요청을 실제로 시험합니다
• 웹훅의 준비 상태만 확인하고 정책에 맞지 않는 입력 시험은 생략합니다

표준 NetworkPolicy로 연결 범위를 제한했습니다. 서비스 사이 인증과 암호화에 대한 정확한 판단은 무엇입니까?

• TLS와 신원 인증은 별도이며 메시나 애플리케이션에서 구성해야 합니다
• 허용된 파드 라벨이 인증서 신원을 대신하므로 별도 인증은 필요 없습니다
• TCP 443만 허용하면 API가 인증서를 검증하므로 mTLS가 보장됩니다
• 기본 거부가 있으면 허용된 연결의 본문도 자동으로 암호화됩니다

감사 정책 첫 규칙이 모든 요청의 RequestResponse이고, 뒤에는 Secret의 Metadata 규칙이 있습니다. 올바른 조치는 무엇입니까?

• Secret은 base64이므로 순서를 유지하고 보존 기간만 줄입니다
• 뒤의 구체적인 규칙이 우선하므로 설정을 유지하고 수집만 확인합니다
• Secret을 None으로 바꿔 뒤에 두면 앞 규칙의 본문 수집이 취소됩니다
• 민감 리소스 규칙을 먼저 두고 기록 존재와 본문 부재를 함께 시험합니다

태그로 배포한 서비스의 실행 빌드를 조사해야 합니다. 증거를 다루는 적절한 방법은 무엇입니까?

• 현재 태그가 가리키는 이미지를 조회해 과거 모든 파드의 실행본으로 봅니다
• 런타임 imageID와 배포 기록을 모아 digest·빌드 증거를 연결합니다
• 태그로 배포했으므로 현재 파드에서도 이미지 식별 정보를 얻을 수 없습니다
• digest만 구하면 작성자와 소스 커밋도 해시에서 복원할 수 있습니다

이미지 서명 검증은 통과했고 별도 SBOM 파일을 받았습니다. 배포 판단 전에 무엇을 더 확인해야 합니까?

• 이미지 서명이 옆 파일도 인증하므로 SBOM의 파일명만 맞춰 둡니다
• SBOM에 패키지가 하나 이상 있으면 이미지와의 연결도 확인된 것으로 봅니다
• SBOM 증거의 신뢰성과 대상 digest 연결을 별도로 검증합니다
• 레지스트리에 함께 저장되어 있으면 빌더 신원 확인을 생략합니다

변형 정책이 빠진 라벨을 채웠고 검증 정책이 요청을 허용했습니다. 어떤 결론이 타당합니까?

• 검증은 변형된 객체를 검사할 수 있으므로 허용만으로 미실행이라 볼 수 없습니다
• 검증은 반드시 원래 객체만 보므로 정책 충돌을 API 서버가 무시한 것입니다
• 변형이 성공한 요청은 검증 단계를 자동으로 건너뛰므로 허용된 것입니다
• 검증이 먼저 실행되어 라벨 없는 객체를 허용한 뒤 변형이 진행된 것입니다