kubectl는 VPN에서 동작하지만 AKS가 스케일링을 멈추는 이유

사무실 VPN의 공인 주소를 AKS API 서버 허용 목록에 추가하면 kubectl이 동작합니다. 일주일 뒤 node pool 확장이 실패하고, CI 작업이 클러스터에 도달하지 못하며, 포털은 IP 범위에 대해 아무 말도 하지 않는 오류를 표시합니다. 아무도 허용 목록을 바꾸지 않았습니다. 활성화한 제어는 API 서버 앞의 공인 IP 필터이며, 누가 호출하는지는 모르고 호출이 어느 주소에서 왔는지만 압니다. VPN은 클러스터가 필요로 하는 여러 주소 중 하나일 뿐이고, 먼저 깨지는 경우는 드뭅니다.

허용 목록은 주소와 일치하며 사람과 일치하지 않습니다

--api-server-authorized-ip-ranges CIDR 블록을 받으며 사용자나 그룹은 받지 않습니다. 개발자의 요청이 VPN 서버를 떠나 Azure로 향할 때 API 서버에서 보이는 출발지 주소는 VPN 서버의 공인 이그레스입니다. 따라서 그 VPN의 모든 사람이 하나의 항목을 공유하며, VPN 밖에 있는 사람은 인증이 일어나기도 전에 거부됩니다.

이는 이 항목이 의도한 것보다 더 많은 사람을 허용한다는 뜻이기도 합니다. VPN 접근 권한이 있는 계약자, 같은 집선 장치에 있는 개인 노트북, 탈취된 계정이 모두 같은 주소에서 옵니다. 클러스터 권한 부여는 그대로이므로 호출자가 무엇을 할 수 있는지는 여전히 역할 기반 접근 제어가 결정하지만, 허용 목록은 신원 제어가 아니며 그렇게 설명해서는 안 됩니다.

먼저 깨지는 것은 대개 kubectl이 아닙니다

허용 목록은 API 서버의 공인 엔드포인트에 적용되므로, 목록에 넣은 주소 밖의 모든 것은 즉시 동작을 멈춥니다. 명백한 피해자는 VPN 경로가 없는 두 번째 사무실, 호스팅 파이프라인의 CI 러너, 연결을 잊은 노트북입니다. 사람이 기다리고 있으므로 알아채기 쉽습니다.

덜 명백한 경우는 Azure나 자체 도구가 구동하는 자동화입니다. 플랫폼이 시작하는 일부 작업은 VPN이 아닌 주소에서 API 서버에 도달하며, 목록을 조인 직후 그중 하나가 실패하기 시작하면 타이밍이 단서입니다. 대화형 접근이 동작한다고 목록이 완전하다고 가정하지 말고, 클러스터가 고장 났다고 결론 내리기 전에 해당 기능이 리전과 구독에 무엇을 요구하는지 확인하십시오.

실패 서명이 도움이 됩니다. 요청이 인증에 도달하지 않는다면 필터입니다. 인증을 통과한 뒤 권한 오류가 난다면 필터는 제 역할을 한 것이고, 문제는 허용 목록이 전혀 건드리지 않는 역할 기반 접근 제어입니다.

목록 전체를 한 명령으로 만드십시오

업데이트 매개변수는 항목을 추가하는 대신 목록 전체를 교체하므로, VPN 주소만 담은 명령은 거기에 있던 다른 모든 것을 조용히 떨어뜨립니다. 먼저 현재 값을 읽고 유지한 다음 합집합을 보내십시오.

az aks show -g rg-app -n aks-prod \
  --query apiServerAccessProfile.authorizedIpRanges -o tsv

az aks update -g rg-app -n aks-prod \
  --api-server-authorized-ip-ranges 203.0.113.10/32,198.51.100.0/24

이것에 의존하기 전에 VPN 서버에 예약된 공인 IP를 사용하십시오. 동적 주소는 재연결 시 바뀌며, 변경이 있을 때마다 아직 허용된 네트워크에서 누군가 목록을 갱신할 때까지 팀이 조용히 클러스터 밖으로 잠깁니다. 중복성을 위해 VPN 이그레스 지점이 두 개라면 둘 다 올리십시오. 필터에는 선호 경로라는 개념이 없습니다.

첫 번째 허용된 시도가 곧 테스트가 되도록 변경을 순서화하십시오. 새 목록을 공지하고 적용한 뒤 즉시 VPN에서 연결하십시오. 반대 순서로 하면 CIDR 블록의 오타를 고치려는 사람이 API 서버에 도달할 수 없는 창이 남습니다.

허용 목록이 결코 다루지 않은 것

그것은 API 서버를 프라이빗으로 만들지 않습니다. 프라이빗 클러스터는 프라이빗 엔드포인트와 프라이빗 DNS를 사용하며, 허용 범위 목록은 이를 대체하는 제어가 아닙니다. 또한 허용된 호출자가 무엇을 할 수 있는지도 바꾸지 않으므로, 유출된 관리자 kubeconfig는 허용된 어느 주소에서든 여전히 동작합니다. 자격 증명을 보안 경계로, 목록을 네트워크 편의로 취급하십시오.

이것은 워크로드와 아무 관련이 없습니다. 목록이 활성화된 상태에서도 Pods와 Services는 계속 실행되며, VPN을 통해 애플리케이션에 도달하는 것은 별개의 문제입니다. 클러스터 IP만 가진 Service는 노트북이 열 수 있기 전에 여전히 내부 로드 밸런서, ingress 또는 port-forward가 필요합니다. 이 두 설계를 섞으면 개발자를 제한한다고 주장하면서 실제로는 애플리케이션에 대해 아무것도 제한하지 않는 변경 티켓이 생깁니다.

양쪽에서 검증한 다음 실제 작업 하나를 실행하십시오

VPN의 새 클라이언트와 그 밖의 클라이언트로 테스트하십시오. 바깥 시도는 이름 확인이 아니라 API 서버에서 거부되어야 합니다. 이름이 확인되지 않는다면 DNS를 테스트하는 것이며 필터에 대해 아무것도 배우지 못한 것입니다. 그런 다음 대화형 kubectl 호출이 아닌 작업, 예를 들어 node pool 확장이나 업그레이드 확인을 실행하고, 될 것이라고 가정하지 말고 완료되었는지 확인하십시오.

변경 옆에 이전 목록 값을 기록하고, 입력한 명령을 믿는 대신 업데이트 후 유효 값을 다시 읽으십시오. AKS 허용 IP 범위 문서에는 지원되는 매개변수와 같은 목록에 속해야 하는 플랫폼 요구 사항이 나열되어 있으며, 대부분의 티켓 설명이 빠뜨리는 부분이 바로 이것입니다.