ポリシーをどこで執行するか

한 줄 요약

파이프라인은 빠른 피드백, 어드미션은 API 요청의 집행, 지속 점검은 이미 존재하는 자원의 위반 발견을 맡습니다. 정책이 있다는 사실과 실제 요청을 검사했다는 사실은 다릅니다.

왜 한 자리로는 부족한가

예시 시나리오: 결제 팀의 CI가 서명 없는 이미지를 거절합니다. 그런데 운영자가 다른 경로에서 배포하면 그 CI는 실행되지 않습니다. 반대로 어드미션만 두면 빌드를 끝낸 뒤에야 오류를 만납니다. 이미 떠 있는 워크로드는 정책을 새로 만들었다고 자동으로 교정되지도 않습니다.

세 자리를 연결하되 같은 검사를 세 번 복사하지는 않습니다. 공통 규칙의 버전과 예외 목록을 관리하고, 각 자리에서 무엇을 입력으로 검사했는지 남깁니다. 배포 성공률만 보지 말고 적용 대상 수, 위반 수, 검사 오류와 예외 만료도 함께 봅니다.

어떻게 동작하나

요청의 허용과 현재 상태의 점검

자리	확인할 증거	이것만으로 모르는 것
CI	검사 대상 digest, 규칙 버전, 종료 코드	CI를 우회한 API 요청
어드미션	대상 요청, 적용 범위, 허용·거절 결과	정책 도입 전에 생성된 자원의 현재 위반
지속 점검	점검 시각, 전체 대상 수, 위반 목록	다음 요청이 반드시 거절될지 여부

어드미션의 보장은 매칭된 요청과 설정 범위 안에서 성립합니다. namespaceSelector, 리소스·연산 선택, 예외와 웹훅 오류 처리까지 확인합니다. 웹훅의 failurePolicy: Ignore는 호출 오류를 무시하고 진행하게 합니다. 웹훅이 정상 응답으로 명시적으로 거절한 것을 허용한다는 뜻은 아닙니다. Fail은 오류 때도 거절하므로 가용성과 복구 경로를 함께 설계해야 합니다. Kubernetes 동적 어드미션

변형(mutating) 뒤에 검증(validating)이 옵니다. 변형이 필요한 라벨을 채웠다면 검증은 바뀐 객체를 검사해 허용할 수 있습니다. 이는 검증이 실행되지 않았다는 뜻이 아닙니다. 검증은 최종 객체가 규칙을 만족하는지 확인하는 자리입니다.

정책 Audit 모드와 API 감사 로그는 다릅니다

정책 엔진의 Audit 모드는 위반을 관찰하며 도입 영향을 계산하는 데 쓰입니다. 기능과 기존 자원 점검 범위는 엔진마다 확인해야 합니다. Kubernetes API 감사 로그는 요청 활동의 기록입니다. 로그를 켠 것만으로 정책 위반을 차단하거나 모든 기존 자원을 재검사하지 않습니다.

도입 계획에는 관찰 기간, 수정 담당자, 강제 전환 조건을 씁니다. 예외에는 대상·사유·승인자·만료일을 붙이고 만료가 실제로 집행되는지 확인합니다. 급한 예외를 영구 네임스페이스 제외로 바꾸면 그 공간의 이후 요청도 계속 빠질 수 있습니다.

NetworkPolicy와 mTLS는 서로 대체하지 않습니다

표준 NetworkPolicy는 주로 L3/L4 연결 범위를 제한합니다. 라벨·IP·포트로 허용 대상을 고르지만 TLS 암호화나 인증서 기반 상호 인증을 제공하지 않습니다. 서비스 메시 또는 애플리케이션의 mTLS는 신원을 인증하고 통신을 암호화하며, 누가 어떤 작업을 할 수 있는지는 별도의 인가 정책으로 결정합니다. Kubernetes NetworkPolicy의 범위와 한계

NetworkPolicy를 집행하는 네트워크 플러그인이 필요합니다. 표준 정책 관점에서 선택되지 않은 파드는 해당 방향으로 비격리 상태이며, 실제 도달성에는 다른 방화벽·플랫폼 정책도 영향을 줍니다. 기본 거부를 도입할 때는 DNS와 필요한 의존 통신을 먼저 목록화하고 격리된 시험 공간에서 확인합니다. 운영 전체에 기본 거부를 한꺼번에 넣어 연결을 끊는 것은 검증이 아닙니다.

현장에서 만나는 모습

예시 시나리오: 서명 검증이 계속 성공했지만 정책은 team-a만 선택했고 실제 서비스는 team-b에 있었습니다. 보고서의 성공만 읽으면 검사 범위가 빈 사실을 놓칩니다.

시험 표를 먼저 만듭니다. 허용할 요청은 성공해야 하고, 같은 대상의 서명 없는 요청은 거절돼야 합니다. 선택 범위를 벗어난 요청은 어떻게 처리되는지도 기록합니다. 타임아웃 시험은 소유한 격리 환경에서만 수행합니다. 네트워크도 허용 클라이언트의 성공과 비허용 클라이언트의 실패를 함께 확인합니다. 한쪽만 보면 서버가 꺼져 모든 연결이 실패한 상태를 보안 성공으로 오해할 수 있습니다.

그다음 읽을 것

다음 글에서는 digest, 서명, SBOM, provenance를 구분하고 비밀 본문을 복제하지 않으면서 감사 증거를 남기는 법을 봅니다. 이 단원은 설계와 판단을 연습하는 이론·퀴즈이며 실제 정책 엔진의 동작을 모두 검증한 실습을 뜻하지 않습니다.