测验：策略一坏，集群就停

모든 자원을 매칭하는 정책이 위험한 가장 큰 이유는?

• 정책 오브젝트가 커져 etcd 의 오브젝트 크기 한계에 부딪히기 때문
• 매칭 규칙이 많아질수록 API 서버가 정책을 임의 순서로 평가하게 되기 때문
• 같은 요청이 여러 번 평가되어 판정 결과가 서로 달라질 수 있기 때문
• 비용이 정책 한 번의 실행 시간이 아니라 들어오는 모든 쓰기 요청에 붙는 지연세이기 때문

failurePolicy 의 Fail 과 Ignore 가 맞바꾸는 것은?

• Fail 은 보장을 지키는 대신 가용성을 걸고, Ignore 는 가용성을 지키는 대신 보장을 잃는다
• Fail 은 거부 메시지를 남기고 Ignore 는 감사 이벤트만 남긴다는 기록 방식의 차이다
• Fail 은 어드미션 단계에서, Ignore 는 백그라운드 스캔에서 위반을 처리한다는 시점의 차이다
• Fail 은 클러스터 범위 자원에, Ignore 는 네임스페이스 범위 자원에 적용되는 범위의 차이다

정책 엔진이 사는 네임스페이스와 kube-system 을 범위에서 빼 두는 이유는?

• 그 네임스페이스의 자원은 어드미션 단계를 원래 지나지 않아 규칙이 무의미하기 때문
• 엔진이 죽었을 때 엔진을 되살리는 요청까지 막혀 클러스터가 스스로 복구하지 못하기 때문
• 시스템 네임스페이스의 요청은 감사 로그에 남지 않아 위반을 확인할 수 없기 때문
• 그곳의 워크로드는 이미 Pod Security Admission 이 검사하므로 중복 평가가 되기 때문

와일드카드로 매칭한 뒤 CEL 조건으로 걸러 내는 정책의 문제는?

• CEL 조건은 요청 본문을 읽을 수 없어 종류와 동사만으로 판단해야 한다
• 조건이 거짓인 요청도 거부 대상으로 기록되어 감사 로그가 오염된다
• 같은 결과를 내면서 세 층 중 가장 비싼 자리에서 일해, 걸러질 요청까지 정책을 떠올리게 한다
• 조건식이 하나라도 있으면 자원 층의 매칭 규칙이 무시되어 범위가 오히려 넓어진다

내장 정책(VAP·PSA)과 웹훅 정책의 고장 모드가 다른 이유는?

• 내장 정책은 API 서버 안에서 평가되어 외부 파드와 네트워크에 의존하지 않기 때문
• 내장 정책은 failurePolicy 를 지원하지 않아 실패라는 상태 자체가 없기 때문
• 내장 정책은 어드미션이 아니라 저장 직후 단계에서 평가되어 요청을 막지 않기 때문
• 웹훅 정책만 감사 이벤트를 남겨 고장이 기록으로 드러나기 때문

정책을 켜는 날의 순서에서 범위를 넓히는 일과 차단으로 올리는 일을 같은 날에 하지 말라는 이유는?

• 두 변경을 한 번에 적용하면 정책 오브젝트의 resourceVersion 충돌로 적용이 실패하기 때문
• 범위를 넓힌 뒤에는 엔진이 캐시를 다시 채워야 해서 몇 분 동안 판정이 비기 때문
• 새로 들어온 네임스페이스들이 관찰 단계 없이 곧장 차단을 만나 그날이 사고의 날이 되기 때문
• 차단은 정책 본문을 고치는 일이고 범위는 바인딩을 고치는 일이라 리뷰 담당자가 다르기 때문