Plugin mạng Calico cung cấp nhiều chính sách mạng với cú pháp thống nhất để bảo vệ máy chủ phần cứng, máy ảo và nhóm. Các chính sách này có thể được áp dụng trong một không gian tên hoặc là các chính sách mạng toàn cầu áp dụng cho (để bảo vệ các ứng dụng chạy trực tiếp trên máy chủ - máy chủ có thể là máy chủ hoặc máy ảo) hoặc (để bảo vệ các ứng dụng chạy trong vùng chứa hoặc máy ảo được lưu trữ). Chính sách của Calico cho phép bạn áp dụng các biện pháp bảo mật tại nhiều điểm khác nhau trong đường dẫn của gói bằng cách sử dụng các tùy chọn như preDNAT, unraracked và applyOnForward. Hiểu cách các tùy chọn này hoạt động có thể giúp cải thiện tính bảo mật và hiệu suất của toàn bộ hệ thống của bạn. Bài viết này giải thích bản chất của các tùy chọn chính sách Calico này (preDNAT, unraracked và applyOnForward) được áp dụng cho điểm cuối máy chủ, nhấn mạnh vào những gì xảy ra trong đường dẫn xử lý gói (chuỗi iptabels).
Bài viết này giả định rằng bạn có hiểu biết cơ bản về cách hoạt động của các chính sách mạng Kubernetes và Calico. Nếu không, chúng tôi khuyên bạn nên thử nó и sử dụng Calico trước khi đọc bài viết này. Chúng tôi cũng mong muốn bạn có hiểu biết cơ bản về công việc trong linux.
một thứ vải trắng cho phép bạn áp dụng một bộ quy tắc truy cập theo nhãn (đối với các nhóm máy chủ và khối lượng công việc/nhóm). Điều này rất hữu ích nếu bạn sử dụng các hệ thống không đồng nhất cùng nhau - máy ảo, hệ thống trực tiếp trên phần cứng hoặc cơ sở hạ tầng kubernetes. Ngoài ra, bạn có thể bảo vệ cụm (nút) của mình bằng cách sử dụng một bộ chính sách khai báo và áp dụng chính sách mạng cho lưu lượng truy cập đến (ví dụ: thông qua dịch vụ NodePorts hoặc IP bên ngoài).
Ở cấp độ cơ bản, khi Calico kết nối một nhóm với mạng (xem sơ đồ bên dưới), nó sẽ kết nối nhóm đó với máy chủ bằng giao diện Ethernet ảo (veth). Lưu lượng được gửi bởi nhóm đến máy chủ từ giao diện ảo này và được xử lý theo cách tương tự như khi nó đến từ giao diện mạng vật lý. Theo mặc định, Calico đặt tên cho các giao diện này là caliXXX. Vì lưu lượng truy cập đi qua giao diện ảo nên nó sẽ đi qua iptables như thể nhóm chỉ cách một bước nhảy. Do đó, khi lưu lượng truy cập đến/từ một nhóm, nó sẽ được chuyển tiếp theo quan điểm của máy chủ.
Trên nút Kubernetes chạy Calico, bạn có thể ánh xạ giao diện ảo (veth) tới khối lượng công việc như sau. Trong ví dụ bên dưới, bạn có thể thấy rằng veth#10 (calic1cbf1ca0f8) được kết nối với cnx-manager-* trong không gian tên giám sát calico.
[centos@ip-172-31-31-46 K8S]$ sudo ip a
...
10: calic1cbf1ca0f8@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 5
inet6 fe80::ecee:eeff:feee:eeee/64 scope link
valid_lft forever preferred_lft forever
...
[centos@ip-172-31-31-46 K8S]$ calicoctl get wep --all-namespaces
...
calico-monitoring cnx-manager-8f778bd66-lz45m ip-172-31-31-46.ec2.internal 192.168.103.134/32
calic1cbf1ca0f8
...
Vì Calico tạo giao diện veth cho từng khối lượng công việc, nó thực thi các chính sách như thế nào? Để thực hiện điều này, Calico tạo các móc nối trong các chuỗi khác nhau của đường dẫn xử lý gói bằng cách sử dụng iptables.
Sơ đồ bên dưới hiển thị các chuỗi liên quan đến xử lý gói trong iptables (hoặc hệ thống con netfilter). Khi một gói đến qua giao diện mạng, trước tiên nó sẽ đi qua chuỗi PREROUTING. Sau đó, quyết định định tuyến sẽ được đưa ra và dựa trên điều này, gói sẽ chuyển qua INPUT (chuyển hướng đến quy trình máy chủ) hoặc FORWARD (chuyển hướng đến nhóm hoặc nút khác trên mạng). Từ quy trình cục bộ, gói đi qua chuỗi OUTPUT và sau đó POSTROUTING trước khi được gửi xuống cáp.
Lưu ý rằng nhóm cũng là một thực thể bên ngoài (được kết nối với veth) về mặt xử lý iptables. Hãy tóm tắt:
- Lưu lượng được chuyển tiếp (nat, được định tuyến hoặc đến/từ một nhóm) đi qua chuỗi PREROUTING - Forward - POSTROUTING.
- Lưu lượng truy cập đến quy trình máy chủ cục bộ đi qua chuỗi PREROUTING - INPUT.
- Lưu lượng truy cập từ quá trình lưu trữ cục bộ đi qua chuỗi OUTPUT - POSTROUTING.
Calico cung cấp các tùy chọn chính sách cho phép bạn áp dụng chính sách trên tất cả các chuỗi. Với ý nghĩ đó, chúng ta hãy xem xét các tùy chọn cấu hình chính sách khác nhau có sẵn trong Calico. Các số trong danh sách tùy chọn bên dưới tương ứng với các số trong sơ đồ trên.
- Chính sách điểm cuối (nhóm) khối lượng công việc
- Chính sách điểm cuối máy chủ
- Tùy chọn Áp dụngOnForward
- Chính sách PreDNAT
- Chính sách không bị theo dõi
Hãy bắt đầu bằng cách xem cách áp dụng các chính sách cho điểm cuối khối lượng công việc (nhóm Kubernetes hoặc máy ảo OpenStack), sau đó xem xét các tùy chọn chính sách cho điểm cuối máy chủ.
Điểm cuối khối lượng công việc
Chính sách điểm cuối khối lượng công việc (1)
Đây là một tùy chọn để bảo vệ nhóm kubernetes của bạn. Calico hỗ trợ làm việc với Kubernetes NetworkPolicy, nhưng nó cũng cung cấp các chính sách bổ sung - Calico NetworkPolicy và GlobalNetworkPolicy. Calico tạo một chuỗi cho từng pod (khối lượng công việc) và móc trong chuỗi INPUT và OUTPUT cho khối lượng công việc vào bảng lọc của chuỗi FORWARD.
Điểm cuối máy chủ
Chính sách điểm cuối máy chủ (2)
Ngoài CNI (giao diện mạng container), các chính sách của Calico còn cung cấp khả năng tự bảo vệ máy chủ. Trong Calico, bạn có thể tạo điểm cuối máy chủ bằng cách chỉ định kết hợp giao diện máy chủ và số cổng nếu cần. Việc thực thi chính sách cho thực thể này được thực hiện bằng cách sử dụng bảng lọc trong chuỗi INPUT và OUTPUT. Như bạn có thể thấy từ sơ đồ, (2) chúng áp dụng cho các quy trình cục bộ trên nút/máy chủ. Nghĩa là, nếu bạn tạo chính sách áp dụng cho điểm cuối máy chủ, điều đó sẽ không ảnh hưởng đến lưu lượng truy cập đến/từ nhóm của bạn. Tuy nhiên, nó cung cấp một giao diện/cú pháp duy nhất để chặn lưu lượng truy cập cho máy chủ và nhóm của bạn bằng chính sách Calico. Điều này giúp đơn giản hóa đáng kể quá trình quản lý chính sách cho một mạng không đồng nhất. Định cấu hình chính sách điểm cuối máy chủ để tăng cường bảo mật cụm là một trường hợp sử dụng quan trọng khác.
Chính sách ApplyOnForward (3)
Tùy chọn ApplyOnForward có sẵn trong chính sách mạng toàn cầu của Calico để cho phép áp dụng các chính sách cho tất cả lưu lượng truy cập đi qua điểm cuối máy chủ, bao gồm cả lưu lượng truy cập sẽ được máy chủ chuyển tiếp. Điều này bao gồm lưu lượng truy cập được chuyển tiếp đến nhóm cục bộ hoặc bất kỳ nơi nào khác trên mạng. Calico yêu cầu bật cài đặt này cho các chính sách sử dụng PreDNAT và không bị theo dõi, hãy xem các phần sau. Ngoài ra, ApplyOnForward có thể được sử dụng để giám sát lưu lượng máy chủ trong trường hợp sử dụng bộ định tuyến ảo hoặc phần mềm NAT.
Lưu ý rằng nếu bạn cần áp dụng cùng một chính sách mạng cho cả tiến trình máy chủ và nhóm thì bạn không cần sử dụng tùy chọn ApplyOnForward. Tất cả những gì bạn cần làm là tạo nhãn cho điểm cuối máy chủ và điểm cuối khối lượng công việc (nhóm) được yêu cầu. Calico đủ thông minh để thực thi chính sách dựa trên nhãn, bất kể loại điểm cuối (điểm cuối máy chủ hoặc khối lượng công việc).
Chính sách PreDNAT (4)
Trong Kubernetes, các cổng thực thể dịch vụ có thể được hiển thị bên ngoài bằng tùy chọn NodePorts hoặc, tùy chọn (khi sử dụng Calico), bằng cách quảng cáo chúng bằng tùy chọn IP cụm hoặc IP bên ngoài. Kube-proxy cân bằng lưu lượng truy cập đến được liên kết với một dịch vụ với các nhóm của dịch vụ tương ứng bằng cách sử dụng DNAT. Vì điều này, làm cách nào để bạn thực thi các chính sách đối với lưu lượng truy cập đi qua NodePort? Để đảm bảo rằng các chính sách này được áp dụng trước khi lưu lượng truy cập được xử lý bởi DNAT (là ánh xạ giữa máy chủ: cổng và dịch vụ tương ứng), Calico cung cấp một tham số cho GlobalNetworkPolicy có tên là "preDNAT: true".
Khi pre-DNAT được bật, các chính sách này được triển khai trong (4) trong sơ đồ - trong bảng mangle của chuỗi PREROUTING - ngay trước DNAT. Thứ tự thông thường của các chính sách không được tuân theo ở đây, vì việc áp dụng các chính sách này xảy ra sớm hơn nhiều trong quá trình xử lý lưu lượng. Tuy nhiên, các chính sách preDNAT tôn trọng thứ tự áp dụng giữa chúng.
Khi tạo chính sách với pre-DNAT, điều quan trọng là phải cẩn thận với lưu lượng truy cập bạn muốn xử lý và cho phép phần lớn bị từ chối. Lưu lượng truy cập được đánh dấu là 'cho phép' trong chính sách tiền DNAT sẽ không còn được chính sách điểm cuối máy chủ kiểm tra nữa, trong khi lưu lượng truy cập không đạt chính sách tiền DNAT sẽ tiếp tục đi qua các chuỗi còn lại.
Calico đã bắt buộc phải bật tùy chọn applyOnForward khi sử dụng preDNAT, vì theo định nghĩa, đích của lưu lượng truy cập vẫn chưa được chọn. Lưu lượng truy cập có thể được chuyển hướng đến quy trình máy chủ hoặc có thể được chuyển tiếp đến một nhóm hoặc nút khác.
Chính sách không bị theo dõi (5)
Mạng và ứng dụng có thể có sự khác biệt lớn về hành vi. Trong một số trường hợp đặc biệt, ứng dụng có thể tạo ra nhiều kết nối có thời gian tồn tại ngắn. Điều này có thể khiến conntrack (một thành phần cốt lõi của ngăn xếp mạng Linux) hết bộ nhớ. Theo truyền thống, để chạy các loại ứng dụng này trên Linux, bạn sẽ phải định cấu hình hoặc tắt conntrack theo cách thủ công hoặc viết các quy tắc iptables để bỏ qua conntrack. Chính sách không bị theo dõi trong Calico là một lựa chọn đơn giản và hiệu quả hơn nếu bạn muốn xử lý các kết nối nhanh nhất có thể. Ví dụ: nếu bạn sử dụng lớn hoặc như một biện pháp bổ sung để bảo vệ chống lại .
Đọc này (hoặc ) để biết thêm thông tin, bao gồm kiểm tra hiệu suất bằng chính sách không bị theo dõi.
Khi bạn đặt tùy chọn "doNotTrack: true" trong Calico GlobalNetworkPolicy, tùy chọn này sẽ trở thành chính sách **không bị theo dõi** và được áp dụng từ rất sớm trong quy trình xử lý gói Linux. Nhìn vào sơ đồ trên, các chính sách không được theo dõi được áp dụng trong chuỗi PREROUTING và OUTPUT trong bảng thô trước khi bắt đầu theo dõi kết nối (conntrack). Khi một gói được cho phép bởi chính sách không bị theo dõi, nó sẽ được đánh dấu để tắt tính năng theo dõi kết nối cho gói đó. Nó có nghĩa là:
- Chính sách không bị theo dõi được áp dụng trên cơ sở từng gói. Không có khái niệm về kết nối (hoặc dòng chảy). Thiếu kết nối có một số hậu quả quan trọng:
- Nếu bạn muốn cho phép cả lưu lượng truy cập yêu cầu và phản hồi, bạn cần có quy tắc cho cả lưu lượng truy cập vào và ra (vì Calico thường sử dụng conntrack để đánh dấu lưu lượng truy cập phản hồi là được phép).
- Chính sách không bị theo dõi không hoạt động đối với khối lượng công việc Kubernetes (nhóm), vì trong trường hợp này không có cách nào để theo dõi kết nối đi từ nhóm.
- NAT không hoạt động chính xác với các gói không được theo dõi (vì kernel lưu trữ ánh xạ NAT trong conntrack).
- Khi chuyển qua quy tắc "cho phép tất cả" trong chính sách không bị theo dõi, tất cả các gói sẽ được đánh dấu là không bị theo dõi. Đây hầu như không phải là điều bạn mong muốn, vì vậy điều quan trọng là phải hết sức chọn lọc các gói được cho phép bởi các chính sách không bị theo dõi (và cho phép hầu hết lưu lượng truy cập đi qua các chính sách được theo dõi thông thường).
- Các chính sách không bị theo dõi được áp dụng ngay từ đầu quy trình xử lý gói. Điều này rất quan trọng cần hiểu khi tạo chính sách Calico. Bạn có thể có chính sách nhóm với order:1 và chính sách không được theo dõi với order:1000. Nó sẽ không thành vấn đề. Chính sách Không bị theo dõi sẽ được áp dụng trước chính sách cho nhóm. Các chính sách không được theo dõi chỉ tôn trọng thứ tự thực hiện giữa chúng.
Bởi vì một trong những mục đích của chính sách doNotTrack là thực thi chính sách này từ rất sớm trong quy trình xử lý gói Linux, Calico bắt buộc phải chỉ định tùy chọn applyOnForward khi sử dụng doNotTrack. Tham khảo sơ đồ xử lý gói, lưu ý rằng chính sách không bị theo dõi(5) được áp dụng trước bất kỳ quyết định định tuyến nào. Lưu lượng truy cập có thể được chuyển hướng đến quy trình máy chủ hoặc có thể được chuyển tiếp đến một nhóm hoặc nút khác.
Kết quả
Chúng tôi đã xem xét các tùy chọn chính sách khác nhau (Điểm cuối máy chủ, ApplyOnForward, preDNAT và Untracked) trong Calico và cách chúng được áp dụng dọc theo đường dẫn xử lý gói. Hiểu cách chúng hoạt động sẽ giúp phát triển các chính sách hiệu quả và an toàn. Với Calico, bạn có thể sử dụng chính sách mạng toàn cầu áp dụng cho nhãn (một nhóm nút và nhóm) và áp dụng các chính sách với nhiều thông số khác nhau. Điều này cho phép các chuyên gia thiết kế mạng và bảo mật bảo vệ một cách thuận tiện “mọi thứ” (loại điểm cuối) cùng một lúc bằng cách sử dụng một ngôn ngữ chính sách duy nhất với chính sách Calico.
Lời cảm ơn: Tôi xin gửi lời cảm ơn и để họ xem xét và cung cấp thông tin có giá trị.
Nguồn: www.habr.com