Real Attack Check

runner는 app의 Secret 조회가 거절되지만 Pod 생성은 허용된다. Restricted가 적용된 app에서 Secret 볼륨을 쓰는 비루트 Pod를 만들면?

• Pod가 Restricted 조건을 만족하면 같은 namespace의 Secret 볼륨을 읽을 수 있다
• Restricted는 모든 Secret 참조를 금지하므로 Pod 생성이 항상 거절된다
• Pod 생성은 허용되지만 runner의 get secrets 권한이 없으면 볼륨이 항상 거절된다
• 저장 암호화가 켜져 있으면 Pod에는 Secret의 암호문 파일만 마운트된다

관리자가 serviceAccountName=runner인 Pod를 생성했다. 이 결과만으로 무엇을 증명하지 못하는가?

• Pod가 선택한 서비스 계정의 이름이 runner라는 점
• runner가 실제 생성 요청 주체로서 Pod를 만들 수 있다는 점
• API 서버에 Pod 객체가 등록되어 있다는 점
• Pod 명세에 서비스 계정 이름이 포함되어 있다는 점

Pod의 automountServiceAccountToken을 false로 설정했다. 정확한 효과는?

• 해당 namespace의 모든 Secret API 조회를 거절한다
• Pod에 명시된 모든 Secret 볼륨 참조를 거절한다
• 그 Pod의 서비스 계정 토큰 자동 마운트를 끈다
• 선택한 서비스 계정의 RBAC RoleBinding을 삭제한다

저장 암호화를 켜고 API 서버를 재시작한 뒤, 기존 Secret이 모두 암호화됐다고 보고했다. 빠진 것은?

• 기존 Secret을 읽는 모든 SA의 토큰을 다시 발급하는 단계
• 모든 Secret의 API base64 문자열 길이를 늘리는 단계
• 암호화와 무관하게 모든 namespace를 다시 만드는 단계
• 기존 객체를 재작성하고 저장 결과와 읽기 가능성을 검증하는 단계

EncryptionConfiguration의 첫 제공자가 identity이고 다음이 aescbc라면 새 Secret은?

• 첫 쓰기 제공자인 identity로 저장되어 암호화되지 않는다
• 두 제공자를 순서대로 적용해 이중 암호화된다
• 마지막 쓰기 제공자인 aescbc로 자동 저장된다
• identity가 포함되면 API 서버가 항상 기동을 거부한다

익명 요청의 응답을 해석할 때 올바른 판단은?

• 자격증명이 없으면 모든 경로가 예외 없이 401을 반환한다
• 403이면 네트워크 연결이 실패해 서버에 요청이 도달하지 않았다
• 익명 인증이 허용된 경로에서는 익명 주체로 인가될 수 있다
• 기본 SA 토큰은 모든 namespace의 Secret 조회를 허용한다