퀴즈: 정책의 방향과 증거

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

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

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

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

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

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

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

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

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

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

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

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

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