🥇Giới thiệu về Chính sách mạng Kubernetes dành cho Chuyên gia bảo mật

Ghi chú. bản dịch.: Tác giả bài viết, Reuven Harrison, có hơn 20 năm kinh nghiệm trong lĩnh vực phát triển phần mềm, hiện nay là CTO và đồng sáng lập của Tufin, một công ty tạo ra các giải pháp quản lý chính sách bảo mật. Mặc dù anh coi các chính sách mạng của Kubernetes là một công cụ khá mạnh mẽ để phân đoạn mạng trong một cụm, nhưng anh cũng tin rằng chúng không dễ thực hiện trên thực tế. Tài liệu này (khá đồ sộ) nhằm mục đích nâng cao nhận thức của các chuyên gia về vấn đề này và giúp họ tạo ra các cấu hình cần thiết.

Ngày nay, nhiều công ty ngày càng lựa chọn Kubernetes để chạy ứng dụng của mình. Sự quan tâm đến phần mềm này cao đến mức một số người gọi Kubernetes là “hệ điều hành mới cho trung tâm dữ liệu”. Dần dần, Kubernetes (hoặc k8s) bắt đầu được coi là một phần quan trọng của doanh nghiệp, đòi hỏi phải tổ chức các quy trình kinh doanh hoàn thiện, bao gồm cả an ninh mạng.

Đối với các chuyên gia bảo mật đang bối rối khi làm việc với Kubernetes, tiết lộ thực sự có thể là chính sách mặc định của nền tảng: cho phép mọi thứ.

Hướng dẫn này sẽ giúp bạn hiểu cấu trúc bên trong của các chính sách mạng; hiểu chúng khác với các quy tắc của tường lửa thông thường như thế nào. Nó cũng sẽ đề cập đến một số cạm bẫy và đưa ra các đề xuất để giúp bảo mật các ứng dụng trên Kubernetes.

Chính sách mạng Kubernetes

Cơ chế chính sách mạng Kubernetes cho phép bạn quản lý sự tương tác của các ứng dụng được triển khai trên nền tảng ở lớp mạng (lớp thứ ba trong mô hình OSI). Các chính sách mạng thiếu một số tính năng nâng cao của tường lửa hiện đại, chẳng hạn như thực thi OSI Lớp 7 và phát hiện mối đe dọa, nhưng chúng cung cấp mức độ bảo mật mạng cơ bản, đây là điểm khởi đầu tốt.

Chính sách mạng kiểm soát thông tin liên lạc giữa các nhóm

Khối lượng công việc trong Kubernetes được phân phối trên các nhóm, bao gồm một hoặc nhiều vùng chứa được triển khai cùng nhau. Kubernetes gán cho mỗi nhóm một địa chỉ IP có thể truy cập được từ các nhóm khác. Chính sách mạng Kubernetes đặt quyền truy cập cho các nhóm nhóm giống như cách mà các nhóm bảo mật trên đám mây được sử dụng để kiểm soát quyền truy cập vào các phiên bản máy ảo.

Xác định chính sách mạng

Giống như các tài nguyên Kubernetes khác, chính sách mạng được chỉ định trong YAML. Trong ví dụ dưới đây, ứng dụng balance truy cập vào postgres:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: balance
  policyTypes:
  - Ingress

(Ghi chú. bản dịch.: Ảnh chụp màn hình này, giống như tất cả các ảnh chụp màn hình tương tự tiếp theo, được tạo không phải bằng công cụ Kubernetes gốc mà sử dụng công cụ Tufin Orca, được phát triển bởi công ty của tác giả bài viết gốc và được đề cập ở cuối tài liệu.)

Để xác định chính sách mạng của riêng bạn, bạn sẽ cần có kiến thức cơ bản về YAML. Ngôn ngữ này dựa trên thụt lề (được chỉ định bằng dấu cách thay vì tab). Phần tử thụt lề thuộc về phần tử thụt lề gần nhất phía trên nó. Một phần tử danh sách mới bắt đầu bằng dấu gạch nối, tất cả các phần tử khác có dạng giá trị cốt lõi.

Sau khi mô tả chính sách trong YAML, hãy sử dụng kubectlđể tạo nó trong cụm:

kubectl create -f policy.yaml

Đặc tả chính sách mạng

Đặc tả chính sách mạng Kubernetes bao gồm bốn thành phần:

podSelector: xác định các nhóm bị ảnh hưởng bởi chính sách này (mục tiêu) - bắt buộc;
policyTypes: cho biết loại chính sách nào được bao gồm trong phần này: xâm nhập và/hoặc đi ra - tùy chọn, nhưng tôi khuyên bạn nên chỉ định rõ ràng nó trong mọi trường hợp;
ingress: định nghĩa được phép đến lưu lượng truy cập đến nhóm mục tiêu - tùy chọn;
egress: định nghĩa được phép hướng ngoaị lưu lượng truy cập từ nhóm mục tiêu là tùy chọn.

Ví dụ lấy từ trang web Kubernetes (Tôi đã thay thế role trên app), cho thấy cách sử dụng tất cả bốn phần tử:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:    # <<<
    matchLabels:
      app: db
  policyTypes:    # <<<
  - Ingress
  - Egress
  ingress:        # <<<
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:         # <<<
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

Xin lưu ý rằng không cần phải đưa cả bốn yếu tố này vào. Nó chỉ bắt buộc podSelector, các thông số khác có thể được sử dụng theo ý muốn.

Nếu bạn bỏ qua policyTypes, chính sách sẽ được hiểu như sau:

Theo mặc định, nó được giả định rằng nó xác định phía đi vào. Nếu chính sách không nêu rõ điều này, hệ thống sẽ cho rằng tất cả lưu lượng truy cập đều bị cấm.
Hành vi ở phía đầu ra sẽ được xác định bởi sự hiện diện hay vắng mặt của tham số đầu ra tương ứng.

Để tránh sai lầm tôi khuyên bạn nên luôn luôn làm cho nó rõ ràng policyTypes.

Theo logic trên, nếu các tham số ingress và / hoặc egress bị bỏ qua, chính sách sẽ từ chối tất cả lưu lượng truy cập (xem "Quy tắc loại bỏ" bên dưới).

Chính sách mặc định là Cho phép

Nếu không có chính sách nào được xác định, Kubernetes sẽ cho phép tất cả lưu lượng truy cập theo mặc định. Tất cả các nhóm có thể tự do trao đổi thông tin với nhau. Điều này có vẻ phản trực giác từ góc độ bảo mật, nhưng hãy nhớ rằng Kubernetes ban đầu được các nhà phát triển thiết kế để kích hoạt khả năng tương tác của ứng dụng. Chính sách mạng đã được thêm vào sau đó.

Không gian tên

Không gian tên là cơ chế cộng tác Kubernetes. Chúng được thiết kế để tách biệt các môi trường logic với nhau, trong khi giao tiếp giữa các không gian được cho phép theo mặc định.

Giống như hầu hết các thành phần Kubernetes, chính sách mạng tồn tại trong một không gian tên cụ thể. trong khối metadata bạn có thể chỉ định chính sách thuộc về không gian nào:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: my-namespace  # <<<
spec:
...

Nếu không gian tên không được chỉ định rõ ràng trong siêu dữ liệu, hệ thống sẽ sử dụng không gian tên được chỉ định trong kubectl (theo mặc định namespace=default):

kubectl apply -n my-namespace -f namespace.yaml

Tôi đề nghị chỉ định không gian tên một cách rõ ràng, trừ khi bạn đang viết chính sách nhắm mục tiêu nhiều không gian tên cùng một lúc.

Chính thành phần podSelector trong chính sách sẽ chọn các nhóm từ không gian tên mà chính sách đó thuộc về (nó bị từ chối quyền truy cập vào các nhóm từ không gian tên khác).

Tương tự, podSelector trong khối đi vào và đi ra chỉ có thể chọn các nhóm từ không gian tên của riêng chúng, tất nhiên trừ khi bạn kết hợp chúng với namespaceSelector (điều này sẽ được thảo luận trong phần “Lọc theo không gian tên và nhóm”).

Quy tắc đặt tên chính sách

Tên chính sách là duy nhất trong cùng một không gian tên. Không thể có hai chính sách có cùng tên trong cùng một không gian nhưng có thể có các chính sách có cùng tên ở các không gian khác nhau. Điều này hữu ích khi bạn muốn áp dụng lại chính sách tương tự trên nhiều không gian.

Tôi đặc biệt thích một trong những cách đặt tên. Nó bao gồm việc kết hợp tên không gian tên với nhóm mục tiêu. Ví dụ:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres  # <<<
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

Nhãn

Bạn có thể đính kèm nhãn tùy chỉnh vào các đối tượng Kubernetes, chẳng hạn như nhóm và không gian tên. Nhãn (nhãn - thẻ) tương đương với các thẻ trên đám mây. Chính sách mạng Kubernetes sử dụng nhãn để chọn vỏ quảmà họ áp dụng:

podSelector:
  matchLabels:
    role: db

… hoặc không gian tênmà họ áp dụng. Ví dụ này chọn tất cả các nhóm trong không gian tên có nhãn tương ứng:

namespaceSelector:
  matchLabels:
    project: myproject

Một lưu ý: khi sử dụng namespaceSelector đảm bảo các không gian tên bạn chọn có chứa nhãn chính xác. Xin lưu ý rằng các không gian tên tích hợp như default и kube-system, theo mặc định không chứa nhãn.

Bạn có thể thêm nhãn vào không gian như thế này:

kubectl label namespace default namespace=default

Đồng thời, không gian tên trong phần metadata nên đề cập đến tên không gian thực tế chứ không phải nhãn:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default   # <<<
spec:
...

Nguồn và đích

Chính sách tường lửa bao gồm các quy tắc với nguồn và đích. Chính sách mạng Kubernetes được xác định cho một mục tiêu - một tập hợp các nhóm mà chúng áp dụng - sau đó đặt quy tắc cho lưu lượng truy cập vào và/hoặc đi ra. Trong ví dụ của chúng tôi, mục tiêu của chính sách sẽ là tất cả các nhóm trong không gian tên default có nhãn có chìa khóa app và ý nghĩa db:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: db   # <<<
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

tiểu mục ingress trong chính sách này, sẽ mở lưu lượng truy cập đến các nhóm mục tiêu. Nói cách khác, ingress là nguồn và đích là đích tương ứng. Tương tự như vậy, đầu ra là đích đến và mục tiêu là nguồn của nó.

Điều này tương đương với hai quy tắc tường lửa: Ingress → Target; Mục tiêu → Đi ra.

Đầu ra và DNS (quan trọng!)

Bằng cách hạn chế lưu lượng đi ra, đặc biệt chú ý đến DNS - Kubernetes sử dụng dịch vụ này để ánh xạ các dịch vụ tới địa chỉ IP. Ví dụ: chính sách sau sẽ không hoạt động vì bạn chưa cho phép ứng dụng balance truy cập DNS:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  policyTypes:
  - Egress

Bạn có thể khắc phục bằng cách mở quyền truy cập vào dịch vụ DNS:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:               # <<<
    ports:            # <<<
    - protocol: UDP   # <<<
      port: 53        # <<<
  policyTypes:
  - Egress

yếu tố cuối cùng to trống, và do đó nó gián tiếp chọn tất cả các nhóm trong tất cả các không gian tên, cho phép balance gửi truy vấn DNS đến dịch vụ Kubernetes thích hợp (thường chạy trong không gian kube-system).

Cách tiếp cận này có hiệu quả, tuy nhiên nó quá dễ dãi và không an toàn, vì nó cho phép các truy vấn DNS được chuyển hướng ra ngoài cụm.

Bạn có thể cải thiện nó trong ba bước liên tiếp.

1. Chỉ cho phép truy vấn DNS bên trong cụm bằng cách thêm namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:
    - namespaceSelector: {} # <<<
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

2. Chỉ cho phép truy vấn DNS trong không gian tên kube-system.

Để làm điều này, bạn cần thêm nhãn vào không gian tên kube-system: kubectl label namespace kube-system namespace=kube-system - và viết nó vào chính sách bằng cách sử dụng namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:
    - namespaceSelector:         # <<<
        matchLabels:             # <<<
          namespace: kube-system # <<<
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

3. Những người hoang tưởng có thể đi xa hơn nữa và giới hạn các truy vấn DNS ở một dịch vụ DNS cụ thể trong kube-system. Phần “Lọc theo không gian tên VÀ nhóm” sẽ cho bạn biết cách đạt được điều này.

Một tùy chọn khác là phân giải DNS ở cấp độ không gian tên. Trong trường hợp này, nó sẽ không cần phải mở cho mỗi dịch vụ:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.dns
  namespace: default
spec:
  podSelector: {} # <<<
  egress:
  - to:
    - namespaceSelector: {}
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

Trống podSelector chọn tất cả các nhóm trong không gian tên.

Trận đấu đầu tiên và thứ tự quy tắc

Trong tường lửa thông thường, hành động (Cho phép hoặc Từ chối) trên một gói được xác định bởi quy tắc đầu tiên mà nó đáp ứng. Trong Kubernetes, thứ tự của các chính sách không quan trọng.

Theo mặc định, khi không có chính sách nào được đặt, liên lạc giữa các nhóm được phép và chúng có thể tự do trao đổi thông tin. Khi bạn bắt đầu xây dựng các chính sách, mỗi nhóm bị ảnh hưởng bởi ít nhất một trong số chúng sẽ bị cô lập theo sự phân tách (HOẶC logic) của tất cả các chính sách đã chọn nó. Các nhóm không bị ảnh hưởng bởi bất kỳ chính sách nào vẫn mở.

Bạn có thể thay đổi hành vi này bằng cách sử dụng quy tắc tước bỏ.

Quy tắc tước bỏ (“Từ chối”)

Chính sách tường lửa thường từ chối mọi lưu lượng truy cập không được cho phép rõ ràng.

Không có hành động từ chối trong Kubernetes, tuy nhiên, có thể đạt được hiệu ứng tương tự bằng chính sách thông thường (cho phép) bằng cách chọn một nhóm nhóm nguồn trống (xâm nhập):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress

Chính sách này chọn tất cả các nhóm trong không gian tên và không xác định hoạt động xâm nhập, từ chối tất cả lưu lượng truy cập đến.

Theo cách tương tự, bạn có thể hạn chế tất cả lưu lượng truy cập đi từ một không gian tên:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress

Xin lưu ý rằng mọi chính sách bổ sung cho phép lưu lượng truy cập vào nhóm trong không gian tên sẽ được ưu tiên hơn quy tắc này (tương tự như thêm quy tắc cho phép trước quy tắc từ chối trong cấu hình tường lửa).

Cho phép mọi thứ (Any-Any-Any-Allow)

Để tạo chính sách Cho phép tất cả, bạn cần bổ sung chính sách Từ chối ở trên bằng một phần tử trống ingress:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
  namespace: default
spec:
  podSelector: {}
  ingress: # <<<
  - {}     # <<<
  policyTypes:
  - Ingress

Nó cho phép truy cập từ tất cả các nhóm trong tất cả các không gian tên (và tất cả IP) đến bất kỳ nhóm nào trong không gian tên default. Hành vi này được bật theo mặc định nên thường không cần phải xác định thêm. Tuy nhiên, đôi khi bạn có thể cần phải tạm thời vô hiệu hóa một số quyền cụ thể để chẩn đoán sự cố.

Quy tắc có thể được thu hẹp để chỉ cho phép truy cập vào một tập hợp các nhóm cụ thể (app:balance) trong không gian tên default:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-to-balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  ingress: 
  - {}
  policyTypes:
  - Ingress

Chính sách sau đây cho phép tất cả lưu lượng truy cập vào và ra, bao gồm quyền truy cập vào bất kỳ IP nào bên ngoài cụm:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
spec:
  podSelector: {}
  ingress:
  - {}
  egress:
  - {}
  policyTypes:
  - Ingress
  - Egress

Kết hợp nhiều chính sách

Các chính sách được kết hợp bằng cách sử dụng logic OR ở ba cấp độ; Quyền của mỗi nhóm được đặt theo sự phân tách của tất cả các chính sách ảnh hưởng đến nó:

1. Trên cánh đồng from и to Có thể xác định ba loại phần tử (tất cả đều được kết hợp bằng OR):

namespaceSelector — chọn toàn bộ không gian tên;
podSelector - chọn nhóm;
ipBlock — chọn một mạng con.

Hơn nữa, số phần tử (kể cả phần tử giống hệt nhau) trong các phần phụ from/to không giới hạn. Tất cả chúng sẽ được kết hợp bằng logic OR.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    - podSelector:
        matchLabels:
          app: admin
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

2. Bên trong phần chính sách ingress có thể có nhiều phần tử from (kết hợp bằng logic OR). Tương tự, phần egress có thể bao gồm nhiều yếu tố to (cũng được kết hợp bằng phép tách):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
  - from:
    - podSelector:
        matchLabels:
          app: admin
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

3. Các chính sách khác nhau cũng được kết hợp với logic OR

Nhưng khi kết hợp chúng lại có một hạn chế đó là chỉ ra Chris Cooney: Kubernetes chỉ có thể kết hợp các chính sách với các chính sách khác nhau policyTypes (Ingress hoặc Egress). Các chính sách xác định lối vào (hoặc lối ra) sẽ ghi đè lên nhau.

Mối quan hệ giữa các không gian tên

Theo mặc định, việc chia sẻ thông tin giữa các không gian tên được cho phép. Điều này có thể được thay đổi bằng cách sử dụng chính sách từ chối sẽ hạn chế lưu lượng truy cập đi và/hoặc đi vào không gian tên (xem "Quy tắc loại bỏ" ở trên).

Khi bạn đã chặn quyền truy cập vào một không gian tên (xem "Quy tắc loại bỏ" ở trên), bạn có thể tạo ngoại lệ cho chính sách từ chối bằng cách cho phép kết nối từ một không gian tên cụ thể bằng cách sử dụng namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector: # <<<
        matchLabels:
          namespace: default
  policyTypes:
  - Ingress

Kết quả là tất cả các nhóm trong không gian tên default sẽ có quyền truy cập vào nhóm postgres trong không gian tên database. Nhưng nếu bạn muốn mở quyền truy cập vào postgres chỉ các nhóm cụ thể trong không gian tên default?

Lọc theo không gian tên và nhóm

Kubernetes phiên bản 1.11 trở lên cho phép bạn kết hợp các toán tử namespaceSelector и podSelector sử dụng logic AND. Nó trông như thế này:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          namespace: default
      podSelector: # <<<
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

Tại sao điều này được hiểu là AND thay vì OR thông thường?

Xin lưu ý rằng podSelector không bắt đầu bằng dấu gạch nối. Trong YAML điều này có nghĩa là podSelector và đứng trước mặt anh ấy namespaceSelector tham chiếu đến cùng một phần tử danh sách. Do đó, chúng được kết hợp với logic AND.

Thêm dấu gạch nối trước podSelector sẽ dẫn đến sự xuất hiện của một phần tử danh sách mới, phần tử này sẽ được kết hợp với phần tử trước đó namespaceSelector sử dụng logic OR.

Để chọn nhóm có nhãn cụ thể trong tất cả các không gian tên, điền trống namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

Nhiều nhãn hợp tác với tôi

Các quy tắc cho tường lửa có nhiều đối tượng (máy chủ, mạng, nhóm) được kết hợp bằng OR logic. Quy tắc sau sẽ hoạt động nếu nguồn gói phù hợp Host_1 OR Host_2:

| Source | Destination | Service | Action |
| ----------------------------------------|
| Host_1 | Subnet_A    | HTTPS   | Allow  |
| Host_2 |             |         |        |
| ----------------------------------------|

Ngược lại, trong Kubernetes, các nhãn khác nhau trong podSelector hoặc namespaceSelector được kết hợp với logic AND. Ví dụ: quy tắc sau sẽ chọn các nhóm có cả hai nhãn, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Logic tương tự áp dụng cho tất cả các loại toán tử: bộ chọn mục tiêu chính sách, bộ chọn nhóm và bộ chọn không gian tên.

Mạng con và địa chỉ IP (IPBlocks)

Tường lửa sử dụng Vlan, địa chỉ IP và mạng con để phân đoạn mạng.

Trong Kubernetes, địa chỉ IP được gán tự động cho các nhóm và có thể thay đổi thường xuyên, do đó, nhãn được sử dụng để chọn các nhóm và không gian tên trong chính sách mạng.

Mạng con (ipBlocks) được sử dụng khi quản lý các kết nối bên ngoài (Bắc-Nam) đến (vào) hoặc đi (ra). Ví dụ: chính sách này mở ra cho tất cả các nhóm từ không gian tên default truy cập vào dịch vụ DNS của Google:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-dns
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 8.8.8.8/32
    ports:
    - protocol: UDP
      port: 53

Bộ chọn nhóm trống trong ví dụ này có nghĩa là “chọn tất cả các nhóm trong không gian tên”.

Chính sách này chỉ cho phép truy cập vào 8.8.8.8; truy cập vào bất kỳ IP nào khác đều bị cấm. Như vậy, về bản chất, bạn đã chặn quyền truy cập vào dịch vụ DNS Kubernetes nội bộ. Nếu bạn vẫn muốn mở nó, hãy cho biết điều này một cách rõ ràng.

Thường ipBlocks и podSelectors loại trừ lẫn nhau vì địa chỉ IP nội bộ của nhóm không được sử dụng trong ipBlocks. Bằng cách chỉ ra nhóm IP nội bộ, bạn thực sự sẽ cho phép kết nối đến/từ các nhóm có các địa chỉ này. Trong thực tế, bạn sẽ không biết nên sử dụng địa chỉ IP nào, đó là lý do tại sao chúng không nên được sử dụng để chọn nhóm.

Để làm ví dụ phản biện, chính sách sau bao gồm tất cả IP và do đó cho phép truy cập vào tất cả các nhóm khác:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-any
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0

Bạn chỉ có thể mở quyền truy cập vào các IP bên ngoài, ngoại trừ địa chỉ IP nội bộ của nhóm. Ví dụ: nếu mạng con của nhóm của bạn là 10.16.0.0/14:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-any
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.16.0.0/14

Cổng và giao thức

Thông thường nhóm nghe một cổng. Điều này có nghĩa là bạn có thể không chỉ định số cổng trong chính sách và để mọi thứ như mặc định. Tuy nhiên, nên đưa ra các chính sách hạn chế nhất có thể, vì vậy trong một số trường hợp bạn vẫn có thể chỉ định cổng:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    - podSelector:
        matchLabels:
          app: admin
    ports:             # <<<
      - port: 443      # <<<
        protocol: TCP  # <<<
      - port: 80       # <<<
        protocol: TCP  # <<<
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

Lưu ý rằng bộ chọn ports áp dụng cho tất cả các phần tử trong khối to hoặc from, trong đó có chứa. Để chỉ định các cổng khác nhau cho các bộ phần tử khác nhau, hãy chia ingress hoặc egress thành nhiều tiểu mục với to hoặc from và trong mỗi lần đăng ký cổng của bạn:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    ports:             # <<<
     - port: 443       # <<<
       protocol: TCP   # <<<
  - from:
    - podSelector:
        matchLabels:
          app: admin
    ports:             # <<<
     - port: 80        # <<<
       protocol: TCP   # <<<
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

Hoạt động cổng mặc định:

Nếu bạn bỏ qua hoàn toàn định nghĩa cổng (ports), điều này có nghĩa là tất cả các giao thức và tất cả các cổng;
Nếu bạn bỏ qua định nghĩa giao thức (protocol), điều này có nghĩa là TCP;
Nếu bạn bỏ qua định nghĩa cổng (port), điều này có nghĩa là tất cả các cổng.

Cách thực hành tốt nhất: Đừng dựa vào các giá trị mặc định, hãy chỉ định rõ ràng những gì bạn cần.

Xin lưu ý rằng bạn phải sử dụng cổng pod chứ không phải cổng dịch vụ (xem thêm về điều này trong đoạn tiếp theo).

Các chính sách có được xác định cho nhóm hoặc dịch vụ không?

Thông thường, các nhóm trong Kubernetes truy cập lẫn nhau thông qua một dịch vụ - bộ cân bằng tải ảo chuyển hướng lưu lượng truy cập đến các nhóm triển khai dịch vụ. Bạn có thể nghĩ rằng các chính sách mạng kiểm soát quyền truy cập vào các dịch vụ, nhưng thực tế không phải vậy. Chính sách mạng Kubernetes hoạt động trên các cổng pod chứ không phải cổng dịch vụ.

Ví dụ: nếu một dịch vụ nghe cổng 80 nhưng chuyển hướng lưu lượng truy cập đến cổng 8080 trong nhóm của nó thì bạn phải chỉ định chính xác 8080 trong chính sách mạng.

Cơ chế như vậy nên được coi là chưa tối ưu: nếu cấu trúc bên trong của dịch vụ (các cổng mà nhóm lắng nghe) thay đổi, thì các chính sách mạng sẽ phải được cập nhật.

Phương pháp kiến trúc mới sử dụng Service Mesh (ví dụ: xem về Istio bên dưới - khoảng. bản dịch.) cho phép bạn đối phó với vấn đề này.

Có cần thiết phải đăng ký cả Ingress và Egress không?

Câu trả lời ngắn gọn là có, để pod A giao tiếp với pod B, nó phải được phép tạo kết nối đi (để làm được điều này, bạn cần định cấu hình chính sách đi ra) và pod B phải có khả năng chấp nhận kết nối đến ( để làm điều này, theo đó, bạn cần có chính sách xâm nhập).

Tuy nhiên, trên thực tế, bạn có thể dựa vào chính sách mặc định để cho phép kết nối theo một hoặc cả hai hướng.

Nếu một số pod-nguồn sẽ được chọn bởi một hoặc nhiều đi ra-các chính trị gia, những hạn chế áp đặt lên nó sẽ được xác định bởi sự phân chia của họ. Trong trường hợp này, bạn cần phải cho phép kết nối với nhóm một cách rõ ràng -đến người nhận. Nếu một nhóm không được chọn bởi bất kỳ chính sách nào thì lưu lượng đi (đầu ra) của nhóm đó sẽ được cho phép theo mặc định.

Tương tự, số phận của cái kén làngười nhận, được chọn bởi một hoặc nhiều xâm nhập-các chính trị gia, sẽ được xác định bởi sự phân biệt của họ. Trong trường hợp này, bạn phải cho phép nó nhận lưu lượng truy cập từ nhóm nguồn một cách rõ ràng. Nếu bất kỳ chính sách nào không chọn một nhóm thì tất cả lưu lượng truy cập vào nhóm đó đều được cho phép theo mặc định.

Xem Stateful hoặc Stateless bên dưới.

Nhật ký

Chính sách mạng Kubernetes không thể ghi lại lưu lượng truy cập. Điều này gây khó khăn cho việc xác định liệu một chính sách có hoạt động như dự định hay không và làm phức tạp đáng kể việc phân tích bảo mật.

Kiểm soát lưu lượng đến các dịch vụ bên ngoài

Chính sách mạng Kubernetes không cho phép bạn chỉ định tên miền (DNS) đủ điều kiện trong phần đầu ra. Thực tế này dẫn đến sự bất tiện đáng kể khi cố gắng hạn chế lưu lượng truy cập đến các điểm đến bên ngoài không có địa chỉ IP cố định (chẳng hạn như aws.com).

Kiểm tra chính sách

Tường lửa sẽ cảnh báo bạn hoặc thậm chí từ chối chấp nhận chính sách sai. Kubernetes cũng thực hiện một số xác minh. Khi thiết lập chính sách mạng thông qua kubectl, Kubernetes có thể tuyên bố rằng chính sách đó không chính xác và từ chối chấp nhận. Trong các trường hợp khác, Kubernetes sẽ lấy chính sách và điền vào đó những chi tiết còn thiếu. Chúng có thể được nhìn thấy bằng cách sử dụng lệnh:

kubernetes get networkpolicy <policy-name> -o yaml

Hãy nhớ rằng hệ thống xác thực Kubernetes không thể sai lầm và có thể bỏ sót một số loại lỗi.

Thực hiện

Kubernetes không tự triển khai các chính sách mạng mà chỉ đơn thuần là một cổng API ủy thác gánh nặng kiểm soát cho một hệ thống cơ bản được gọi là Giao diện mạng container (CNI). Việc đặt chính sách trên cụm Kubernetes mà không chỉ định CNI thích hợp cũng giống như tạo chính sách trên máy chủ quản lý tường lửa mà không cài đặt chúng trên tường lửa. Bạn có thể đảm bảo mình có CNI tốt hoặc, trong trường hợp nền tảng Kubernetes, được lưu trữ trên đám mây (bạn có thể xem danh sách các nhà cung cấp đây - khoảng. Dịch.), hãy bật các chính sách mạng sẽ đặt CNI cho bạn.

Lưu ý rằng Kubernetes sẽ không cảnh báo bạn nếu bạn đặt chính sách mạng mà không có CNI trợ giúp thích hợp.

Có trạng thái hay không có trạng thái?

Tất cả các CNI Kubernetes mà tôi gặp đều có trạng thái (ví dụ: Calico sử dụng kết nối Linux). Điều này cho phép nhóm nhận phản hồi trên kết nối TCP mà nó khởi tạo mà không cần phải thiết lập lại. Tuy nhiên, tôi không biết tiêu chuẩn Kubernetes nào có thể đảm bảo tính trạng thái.

Quản lý chính sách bảo mật nâng cao

Dưới đây là một số cách để cải thiện việc thực thi chính sách bảo mật trong Kubernetes:

Mẫu kiến trúc Service Mesh sử dụng các thùng chứa sidecar để cung cấp khả năng đo từ xa và kiểm soát lưu lượng chi tiết ở cấp độ dịch vụ. Để làm ví dụ chúng ta có thể lấy Istio.
Một số nhà cung cấp CNI đã mở rộng các công cụ của họ để vượt xa các chính sách mạng Kubernetes.
cá kình tufin Cung cấp khả năng hiển thị và tự động hóa các chính sách mạng Kubernetes.

Gói Tufin Orca quản lý các chính sách mạng Kubernetes (và là nguồn của ảnh chụp màn hình ở trên).

thêm thông tin

Kết luận

Các chính sách mạng Kubernetes cung cấp một bộ công cụ tốt để phân đoạn các cụm, nhưng chúng không trực quan và có nhiều chi tiết phức tạp. Vì sự phức tạp này, tôi tin rằng nhiều chính sách cụm hiện tại có nhiều lỗi. Các giải pháp khả thi cho vấn đề này bao gồm tự động hóa các định nghĩa chính sách hoặc sử dụng các công cụ phân đoạn khác.

Tôi hy vọng hướng dẫn này sẽ giúp làm sáng tỏ một số câu hỏi và giải quyết các vấn đề bạn có thể gặp phải.

Tái bút từ người dịch

Đọc thêm trên blog của chúng tôi:

"Quay lại microservice với Istio": phần 1 (giới thiệu các tính năng chính), phần 2 (định tuyến, điều khiển giao thông), phần 3 (bảo mật);
"Hướng dẫn minh họa về kết nối mạng trong Kubernetes": phần 1 và 2 (mô hình mạng, mạng lớp phủ), phần 3 (dịch vụ và xử lý lưu lượng);
«Docker và Kubernetes trong môi trường nhạy cảm về bảo mật»;
«9 Thực tiễn tốt nhất về bảo mật Kubernetes»;
«11 cách để (không) trở thành nạn nhân của vụ hack Kubernetes'.

Nguồn: www.habr.com

Giới thiệu về Chính sách mạng Kubernetes dành cho chuyên gia bảo mật