クイズ: validateポリシー

패턴에서 team: "?*" 가 뜻하는 것은?

• team 라벨 값이 정확히 물음표여야 한다
• team 라벨은 있어도 되고 없어도 된다
• team 라벨이 없어야 한다
• team 라벨이 있고 값이 비어 있지 않아야 한다

preconditions 와 validate.deny.conditions 의 차이로 옳은 것은?

• deny 는 참이면 규칙을 건너뛰고, preconditions 는 거짓이면 요청을 거부한다
• 둘은 적는 문법만 다를 뿐 평가 결과도 리포트에 남는 모습도 완전히 같다
• preconditions 는 거짓이면 규칙 자체를 건너뛰고, deny 는 참이면 규칙이 실행된 결과로 거부한다
• preconditions 는 mutate 규칙에서만 쓸 수 있고 validate 에서는 못 쓴다

부정 앵커 X(privileged) 의 의미는?

• privileged 가 있으면 경고만 남긴다
• privileged 키가 존재하면 안 된다
• privileged 값이 false 여야 한다
• privileged 값이 무엇이든 상관없다

새 검증 정책을 만들고 통과하는 리소스로만 테스트했습니다. 이때 놓치는 위험은?

• 거부 메시지가 너무 길어져 API 응답에서 뒷부분이 잘리는 것
• 통과 사례만 있으면 background 스캔이 자동으로 꺼지는 것
• 같은 리소스가 어드미션과 백그라운드에서 두 번 평가되는 것
• 매치 범위가 잘못돼 아무것도 매칭하지 않는 정책과 구분할 수 없는 것

validate.failureAction 이 정책 수준에서 규칙 수준으로 내려온 덕분에 가능해진 것은?

• 같은 정책을 네임스페이스마다 서로 다른 강제 수준으로 적용할 수 있게 됐다
• 규칙마다 서로 다른 match 블록을 두어 대상 범위를 나눌 수 있게 됐다
• 한 정책 안에서 어떤 규칙은 Enforce, 다른 규칙은 Audit 으로 둘 수 있다
• Audit 으로 둔 규칙도 심각도가 높으면 요청을 거부할 수 있게 됐다

이미 돌고 있는 워크로드가 새 정책에 걸릴 때 가장 적절한 대응은?

• 정책 전체를 다시 Audit 으로 되돌려 두고 위반 목록이 저절로 줄기를 기다린다
• 그 네임스페이스를 정책의 match 에서 통째로 빼서 앞으로 만들 것까지 제외한다
• 정책을 일단 삭제했다가 걸린 워크로드를 전부 고친 다음 다시 만들어 올린다
• PolicyException 으로 정책 이름·규칙 이름·리소스 이름까지 좁혀 예외를 남기고 목록을 줄여 나간다

거부 메시지를 공들여 쓰는 실용적 이유는?

• 거부 메시지를 근거로 PolicyException 이 자동으로 만들어지기 때문
• 메시지가 길수록 정책 평가와 리포트 기록 속도가 함께 느려지기 때문
• 배포가 막힌 사람이 볼 수 있는 것은 그 한 줄뿐이라 스스로 고칠 수 있느냐가 여기서 갈리기 때문
• message 필드가 비어 있으면 정책 등록 단계에서 거부되기 때문