OpenShift - Bảo mật

Bảo mật OpenShift chủ yếu là sự kết hợp của hai thành phần chủ yếu xử lý các ràng buộc bảo mật.

Ràng buộc về ngữ cảnh bảo mật (SCC)
Tài khoản dịch vụ

Ràng buộc về ngữ cảnh bảo mật (SCC)

Về cơ bản, nó được sử dụng để hạn chế nhóm, có nghĩa là nó xác định các giới hạn cho nhóm, như những hành động mà nó có thể thực hiện và tất cả những thứ nó có thể truy cập trong cụm.

OpenShift cung cấp một tập hợp SCC được xác định trước có thể được quản trị viên sử dụng, sửa đổi và mở rộng.

$ oc get scc
NAME              PRIV   CAPS  HOSTDIR  SELINUX    RUNASUSER         FSGROUP   SUPGROUP  PRIORITY
anyuid            false   []   false    MustRunAs  RunAsAny          RunAsAny  RunAsAny  10
hostaccess        false   []   true     MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>
hostmount-anyuid  false   []   true     MustRunAs  RunAsAny          RunAsAny  RunAsAny  <none>
nonroot           false   []   false    MustRunAs  MustRunAsNonRoot  RunAsAny  RunAsAny  <none>
privileged        true    []   true     RunAsAny   RunAsAny          RunAsAny  RunAsAny  <none>
restricted        false   []   false    MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>

Nếu một người muốn sử dụng bất kỳ scc nào được xác định trước, điều đó có thể được thực hiện bằng cách chỉ cần thêm người dùng hoặc nhóm vào nhóm scc.

$ oadm policy add-user-to-scc <scc_name> <user_name>
$ oadm policy add-group-to-scc <scc_name> <group_name>

Tài khoản dịch vụ

Tài khoản dịch vụ về cơ bản được sử dụng để kiểm soát quyền truy cập vào API chính OpenShift, được gọi khi một lệnh hoặc một yêu cầu được kích hoạt từ bất kỳ máy chủ hoặc máy nút nào.

Bất kỳ lúc nào một ứng dụng hoặc một quy trình yêu cầu khả năng không được cấp bởi SCC hạn chế, bạn sẽ phải tạo một tài khoản dịch vụ cụ thể và thêm tài khoản vào SCC tương ứng. Tuy nhiên, nếu một SCC không phù hợp với yêu cầu của bạn, thì tốt hơn là tạo một SCC mới cụ thể cho yêu cầu của bạn hơn là sử dụng một SCC phù hợp nhất. Cuối cùng, hãy đặt nó cho cấu hình triển khai.

$ oc create serviceaccount Cadmin
$ oc adm policy add-scc-to-user vipin -z Cadmin

An ninh vùng chứa

Trong OpenShift, bảo mật của vùng chứa dựa trên khái niệm về mức độ an toàn của nền tảng vùng chứa và các vùng chứa đang chạy ở đâu. Có rất nhiều điều xuất hiện khi chúng ta nói về an ninh vùng chứa và những gì cần được quan tâm.

Image Provenance - Một hệ thống ghi nhãn an toàn được thiết lập để xác định chính xác và không thể kiểm soát được nguồn gốc của các thùng chứa đang chạy trong môi trường sản xuất.

Security Scanning - Một máy quét hình ảnh tự động kiểm tra tất cả các hình ảnh để tìm các lỗ hổng đã biết.

Auditing - Môi trường sản xuất thường xuyên được kiểm tra để đảm bảo tất cả các thùng chứa đều dựa trên các thùng chứa cập nhật và cả máy chủ và thùng chứa đều được định cấu hình an toàn.

Isolation and Least Privilege- Các vùng chứa chạy với tài nguyên và đặc quyền tối thiểu cần thiết để hoạt động hiệu quả. Chúng không thể can thiệp quá mức vào máy chủ hoặc các vùng chứa khác.

Runtime Threat Detection - Khả năng phát hiện các mối đe dọa đang hoạt động chống lại ứng dụng được lưu trữ trong thời gian chạy và tự động phản hồi nó.

Access Controls - Các mô-đun bảo mật của Linux, chẳng hạn như AppArmor hoặc SELinux, được sử dụng để thực thi các kiểm soát truy cập.

Có một vài phương pháp chính để lưu trữ bảo mật vùng chứa.

Kiểm soát quyền truy cập qua oAuth
Qua bảng điều khiển web tự phục vụ
Bằng chứng chỉ của nền tảng

Kiểm soát quyền truy cập qua OAuth

Trong phương pháp này, xác thực đối với quyền truy cập điều khiển API được lưu trữ bằng cách nhận mã thông báo bảo mật để xác thực thông qua máy chủ OAuth, có sẵn trong máy chủ OpenShift. Là quản trị viên, bạn có khả năng sửa đổi cấu hình cấu hình máy chủ OAuth.

Để biết thêm chi tiết về cấu hình máy chủ OAuth, hãy tham khảo Chương 5 của hướng dẫn này.

Qua Bảng điều khiển Web Tự phục vụ

Tính năng bảo mật bảng điều khiển web này được tích hợp sẵn trong bảng điều khiển web OpenShift. Bảng điều khiển này đảm bảo rằng tất cả các nhóm làm việc cùng nhau không có quyền truy cập vào các môi trường khác mà không có xác thực. Master multi-telnet trong OpenShift có các tính năng bảo mật sau:

Lớp TCL được bật
Sử dụng chứng chỉ x.509 để xác thực
Bảo mật cấu hình etcd trên máy chủ

Bằng chứng chỉ nền tảng

Trong phương pháp này, các chứng chỉ cho mỗi máy chủ được cấu hình trong quá trình cài đặt thông qua Ansible. Vì nó sử dụng giao thức truyền thông HTTPS thông qua Rest API, chúng tôi cần kết nối bảo mật TCL với các thành phần và đối tượng khác nhau. Đây là những chứng chỉ được xác định trước, tuy nhiên, người ta thậm chí có thể cài đặt chứng chỉ tùy chỉnh trên cụm chính để truy cập. Trong quá trình thiết lập ban đầu của chính, các chứng chỉ tùy chỉnh có thể được định cấu hình bằng cách ghi đè các chứng chỉ hiện có bằng cách sử dụngopenshift_master_overwrite_named_certificates tham số.

Example

openshift_master_named_certificates = [{"certfile": "/path/on/host/to/master.crt", 
"keyfile": "/path/on/host/to/master.key", 
"cafile": "/path/on/host/to/mastercert.crt"}]

Để biết thêm chi tiết về cách tạo chứng chỉ tùy chỉnh, hãy truy cập liên kết sau:

https://www.linux.com/learn/creating-self-signed-ssl-certificates-apache-linux

An ninh mạng

Trong OpenShift, Mạng do Phần mềm Xác định (SDN) được sử dụng để liên lạc. Không gian tên mạng được sử dụng cho mỗi nhóm trong cụm, trong đó mỗi nhóm có IP riêng và một loạt các cổng để nhận lưu lượng mạng trên đó. Bằng phương pháp này, người ta có thể cô lập các nhóm vì nó không thể giao tiếp với các nhóm trong dự án khác.

Cô lập một dự án

Điều này có thể được thực hiện bởi quản trị viên cụm bằng cách sử dụng sau oadm command từ CLI.

$ oadm pod-network isolate-projects <project name 1> <project name 2>

Điều này có nghĩa là các dự án được xác định ở trên không thể giao tiếp với các dự án khác trong cụm.

Bảo mật khối lượng

Bảo mật khối lượng rõ ràng có nghĩa là bảo mật PV và PVC của các dự án trong cụm OpenShift. Chủ yếu có bốn phần để kiểm soát quyền truy cập vào các ổ đĩa trong OpenShift.

Nhóm bổ sung
fsGroup
runAsUser
seLinuxOptions

Nhóm bổ sung - Nhóm bổ sung là các nhóm Linux thông thường. Khi một tiến trình chạy trong hệ thống, nó sẽ chạy với ID người dùng và ID nhóm. Các nhóm này được sử dụng để kiểm soát quyền truy cập vào bộ nhớ dùng chung.

Kiểm tra ngàm NFS bằng lệnh sau.

# showmount -e <nfs-server-ip-or-hostname>
Export list for f21-nfs.vm:
/opt/nfs *

Kiểm tra chi tiết NFS trên máy chủ gắn kết bằng lệnh sau.

# cat /etc/exports
/opt/nfs *(rw,sync,no_root_squash)
...
# ls -lZ /opt/nfs -d
drwxrws---. nfsnobody 2325 unconfined_u:object_r:usr_t:s0 /opt/nfs
# id nfsnobody
uid = 65534(nfsnobody) gid = 454265(nfsnobody) groups = 454265(nfsnobody)

Các / opt / nfs / xuất khẩu có thể truy cập bằng cách UID454265 và nhóm 2325.

apiVersion: v1
kind: Pod
...
spec:
   containers:
   - name: ...
      volumeMounts:
      - name: nfs
         mountPath: /usr/share/...
   securityContext:
      supplementalGroups: [2325]
   volumes:
   - name: nfs
      nfs:
      server: <nfs_server_ip_or_host>
      path: /opt/nfs

fsGroup

fsGroup là viết tắt của nhóm hệ thống tệp được sử dụng để thêm các nhóm bổ sung vùng chứa. ID nhóm bổ sung được sử dụng để lưu trữ chia sẻ và fsGroup được sử dụng để lưu trữ khối.

kind: Pod
spec:
   containers:
   - name: ...
   securityContext:
      fsGroup: 2325

runAsUser

runAsUser sử dụng ID người dùng để giao tiếp. Điều này được sử dụng để xác định hình ảnh vùng chứa trong định nghĩa nhóm. Một người dùng ID duy nhất có thể được sử dụng trong tất cả các vùng chứa, nếu được yêu cầu.

Trong khi chạy vùng chứa, ID đã xác định được khớp với ID chủ sở hữu khi xuất. Nếu ID được chỉ định được xác định bên ngoài, thì nó sẽ trở thành chung cho tất cả các vùng chứa trong nhóm. Nếu nó được xác định với một nhóm cụ thể, thì nó sẽ trở thành cụ thể cho một vùng chứa duy nhất.

spec:
   containers:
   - name: ...
      securityContext:
         runAsUser: 454265