クイズ：ポリシーの方向と証拠

API IP로는 200인데 서비스 이름으로는 timeout이다. egress를 바꾼 직후라면 어떤 비교가 가장 유용한가?

• 같은 출발지의 IP 통제군을 유지하고 DNS 53 흐름과 정책을 확인한다.
• 서버의 Ready가 참이므로 먼저 클라이언트의 HTTP 메서드를 바꾼다.
• 이름 요청에만 실패하므로 서버 replica를 늘리고 두 경로를 다시 합친다.
• HTTP 000은 서버 오류이므로 API 로그만으로 장애 계층을 확정한다.

표준 NetworkPolicy의 한 from 항목에 namespaceSelector와 podSelector를 함께 넣었다. 어떻게 읽는가?

• 두 선택자 중 먼저 동기화된 하나가 통신 상대의 범위를 결정한다.
• 선택된 네임스페이스 안에서 파드 선택자까지 만족하는 상대를 고른다.
• 각 선택자가 다른 허용 문이므로 둘 중 하나만 맞는 상대도 고른다.
• namespaceSelector가 있으므로 podSelector는 API가 무시한다.

두 namespace의 client 파드가 모두 role=client다. Cilium identity를 어떻게 비교해야 하는가?

• 같은 role이므로 숫자 ID가 달라도 같은 신원이라고 기록한다.
• IP가 다른지만 비교하면 identity 라벨을 읽을 필요는 없다.
• namespace를 포함한 보안 라벨 집합과 CEP identity를 함께 본다.
• 파드 이름과 컨테이너 이미지가 같으면 숫자 ID도 영구히 같다.

파란 client를 허용하는 CNP에 빨간 client를 허용하는 표준 NP를 추가했다. 별도 deny가 없다면 무엇을 확인해야 하는가?

• 정책 두 개를 모두 만족하는 출발지만 남았는지 확인한다.
• 이름순 마지막 정책이 기존 CNP를 대체했는지 확인한다.
• CNP가 표준 NP보다 우선하므로 빨간 팀은 항상 막히는지 확인한다.
• 두 허용 경로가 합쳐져 파란 팀과 빨간 팀이 모두 통과하는지 확인한다.

표준 NP가 빨간 client의 API 접근을 허용하지만 CNP ingressDeny도 그 요청과 일치한다. 예상 결과는?

• 명시적 deny가 우선하므로 빨간 요청은 거부되며 정상 통제군도 비교한다.
• 표준 Kubernetes API가 우선하므로 빨간 요청은 기존대로 통과한다.
• 가장 최근에 만든 객체 하나만 읽으므로 생성 시각이 있어야 판단한다.
• CNP와 표준 NP를 같이 쓰면 둘 다 무효가 되어 모든 요청을 허용한다.

Hubble 버퍼에 DROPPED 한 줄이 있다. 방금 보낸 API 요청이 정책에 막혔다는 결론에 무엇이 더 필요한가?

• DROPPED가 한 줄이라도 있으면 충분하므로 HTTP 응답은 생략한다.
• 출발지·목적지·source port·시각·신원을 맞추고 HTTP 결과도 대조한다.
• 가장 오래된 DROPPED를 고르면 정책 적용 이전의 기준선이 된다.
• 서버 이름만 같다면 다른 namespace의 흐름도 같은 요청으로 취급한다.