Tại sao kubectl hoạt động qua VPN nhưng AKS ngừng mở rộng

Bạn thêm địa chỉ công cộng của VPN văn phòng vào danh sách cho phép của máy chủ AKS API, và kubectl hoạt động. Một tuần sau, việc mở rộng một node pool thất bại, một tác vụ CI không thể đến cụm, và cổng thông tin hiển thị lỗi không đề cập gì đến dải IP. Không ai thay đổi danh sách cho phép. Kiểm soát bạn bật là một bộ lọc IP công cộng trước máy chủ API, và nó không biết ai đang gọi, chỉ biết cuộc gọi đến từ địa chỉ nào. VPN là một địa chỉ trong số nhiều địa chỉ cụm cần, và hiếm khi nó là thứ vỡ trước.

Danh sách cho phép khớp với địa chỉ, không phải con người

--api-server-authorized-ip-ranges nhận các khối CIDR, không phải người dùng hay nhóm. Khi yêu cầu của một nhà phát triển rời máy chủ VPN đi Azure, địa chỉ nguồn tại máy chủ API là lối ra công cộng của máy chủ VPN. Vì vậy mọi người trên VPN đó chia sẻ một mục, và bất kỳ ai ngoài VPN đều bị từ chối trước khi xác thực diễn ra.

Điều đó cũng có nghĩa là mục này cho phép nhiều người hơn bạn định. Một nhà thầu có quyền truy cập VPN, một máy tính xách tay cá nhân trên cùng bộ tập trung, và một tài khoản bị xâm phạm đều đến từ cùng một địa chỉ. Việc phân quyền của cụm không thay đổi, nên kiểm soát truy cập dựa trên vai trò vẫn quyết định người gọi được làm gì, nhưng danh sách cho phép không phải kiểm soát danh tính và không bao giờ nên được mô tả như vậy.

Thứ vỡ trước thường không phải kubectl

Danh sách cho phép áp dụng cho điểm cuối công cộng của máy chủ API, nên mọi thứ ngoài các địa chỉ bạn liệt kê sẽ ngừng hoạt động ngay lập tức. Nạn nhân rõ ràng là văn phòng thứ hai không có tuyến VPN, một trình chạy CI trong pipeline được lưu trữ, và một máy tính xách tay quên kết nối. Những thứ này dễ nhận ra vì có một con người đang chờ.

Trường hợp ít rõ ràng hơn là tự động hóa do Azure hoặc công cụ của bạn điều khiển. Một số thao tác do nền tảng khởi tạo đến máy chủ API từ các địa chỉ không phải VPN của bạn, và khi một trong số đó bắt đầu thất bại ngay sau khi danh sách bị siết chặt, thời điểm chính là manh mối. Đừng cho rằng danh sách đã đầy đủ vì truy cập tương tác hoạt động; hãy kiểm tra tính năng yêu cầu gì cho khu vực và đăng ký của bạn trước khi kết luận cụm bị hỏng.

Dấu hiệu thất bại giúp ích. Nếu yêu cầu không bao giờ đến xác thực, đó là bộ lọc. Nếu nó xác thực rồi nhận lỗi quyền, bộ lọc đã làm việc của nó và vấn đề là kiểm soát truy cập dựa trên vai trò, thứ mà danh sách cho phép không bao giờ chạm tới.

Xây toàn bộ danh sách bằng một lệnh

Tham số cập nhật thay thế toàn bộ danh sách thay vì thêm một mục, nên một lệnh chỉ mang địa chỉ VPN sẽ âm thầm bỏ mọi thứ khác đã có ở đó. Hãy đọc giá trị hiện tại trước, giữ nó, và gửi hợp nhất:

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

Dùng một IP công cộng được đặt trước cho máy chủ VPN trước khi dựa vào điều này. Địa chỉ động thay đổi khi kết nối lại, và mỗi thay đổi âm thầm khóa đội ra khỏi cụm cho đến khi ai đó cập nhật danh sách từ một mạng vẫn được cho phép. Nếu bạn có hai điểm ra VPN để dự phòng, hãy liệt kê cả hai, vì bộ lọc không có khái niệm đường đi ưu tiên.

Sắp xếp thay đổi sao cho lần thử được cho phép đầu tiên cũng là bài kiểm tra. Công bố danh sách mới, áp dụng nó, và kết nối từ VPN ngay lập tức; làm theo thứ tự ngược lại sẽ để lại một khoảng thời gian không ai có thể đến máy chủ API để sửa lỗi đánh máy trong một khối CIDR.

Những gì danh sách cho phép chưa bao giờ bao phủ

Nó không làm máy chủ API thành riêng tư. Một cụm riêng tư dùng điểm cuối riêng tư và DNS riêng tư, và danh sách dải được cấp phép không phải kiểm soát thay thế điều đó. Nó cũng không thay đổi điều người gọi được chấp nhận có thể làm, nên một kubeconfig quản trị bị lộ vẫn hoạt động từ bất kỳ địa chỉ được cho phép nào. Hãy coi thông tin xác thực là ranh giới bảo mật và danh sách là tiện ích mạng.

Nó không liên quan gì đến khối lượng công việc. Pods và Services tiếp tục chạy khi danh sách được bật, và việc tiếp cận một ứng dụng qua VPN là một vấn đề riêng: một Service chỉ có IP cụm vẫn cần bộ cân bằng tải nội bộ, ingress hoặc port-forward trước khi máy tính xách tay có thể mở nó. Trộn hai thiết kế này tạo ra một phiếu thay đổi tự nhận hạn chế nhà phát triển và thực tế không hạn chế gì về ứng dụng.

Xác minh từ cả hai phía, rồi chạy một thao tác thực

Kiểm tra bằng một máy khách mới trên VPN và một máy khách bên ngoài. Nỗ lực từ bên ngoài phải bị từ chối tại máy chủ API, không phải tại phân giải tên; nếu tên không phân giải được, bạn đang kiểm tra DNS và chưa học được gì về bộ lọc. Sau đó chạy một thao tác không phải lệnh gọi kubectl tương tác, chẳng hạn mở rộng node pool hoặc kiểm tra nâng cấp, và xác nhận nó hoàn tất thay vì cho rằng nó sẽ hoàn tất.

Ghi lại giá trị danh sách trước đó bên cạnh thay đổi, và đọc lại giá trị hiệu lực sau khi cập nhật thay vì tin vào lệnh đã gõ. tài liệu AKS về dải IP được cho phép liệt kê các tham số được hỗ trợ và yêu cầu nền tảng thuộc cùng danh sách, và đây là phần mà hầu hết mô tả phiếu bỏ qua.