OpenShift - ความปลอดภัย
การรักษาความปลอดภัย OpenShift ส่วนใหญ่เป็นการรวมกันของสององค์ประกอบที่จัดการกับข้อ จำกัด ด้านความปลอดภัยเป็นหลัก
- ข้อ จำกัด บริบทด้านความปลอดภัย (SCC)
- บัญชีบริการ
ข้อ จำกัด บริบทด้านความปลอดภัย (SCC)
โดยทั่วไปจะใช้สำหรับการ จำกัด พ็อดซึ่งหมายความว่าเป็นการกำหนดข้อ จำกัด ของพ็อดเช่นการดำเนินการใดที่สามารถทำได้และทุกสิ่งที่สามารถเข้าถึงได้ในคลัสเตอร์
OpenShift จัดเตรียมชุดของ SCC ที่กำหนดไว้ล่วงหน้าซึ่งผู้ดูแลระบบสามารถใช้แก้ไขและขยายได้
$ 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>
หากต้องการใช้ scc ใด ๆ ที่กำหนดไว้ล่วงหน้าสามารถทำได้โดยเพียงเพิ่มผู้ใช้หรือกลุ่มลงในกลุ่ม scc
$ oadm policy add-user-to-scc <scc_name> <user_name>
$ oadm policy add-group-to-scc <scc_name> <group_name>
บัญชีบริการ
โดยทั่วไปแล้วบัญชีบริการจะใช้เพื่อควบคุมการเข้าถึง OpenShift master API ซึ่งจะถูกเรียกเมื่อมีการเรียกคำสั่งหรือคำขอจากเครื่องหลักหรือโหนดใด ๆ
ทุกครั้งที่แอปพลิเคชันหรือกระบวนการต้องการความสามารถที่ไม่ได้รับอนุญาตจาก SCC ที่ถูก จำกัด คุณจะต้องสร้างบัญชีบริการเฉพาะและเพิ่มบัญชีไปยัง SCC ที่เกี่ยวข้อง อย่างไรก็ตามหาก SCC ไม่ตรงกับความต้องการของคุณคุณควรสร้าง SCC ใหม่เฉพาะสำหรับความต้องการของคุณแทนที่จะใช้ SCC ที่เหมาะสมที่สุด ในท้ายที่สุดตั้งค่าสำหรับการกำหนดค่าการปรับใช้
$ oc create serviceaccount Cadmin
$ oc adm policy add-scc-to-user vipin -z Cadmin
ความปลอดภัยของตู้คอนเทนเนอร์
ใน OpenShift การรักษาความปลอดภัยของคอนเทนเนอร์จะขึ้นอยู่กับแนวคิดของความปลอดภัยของแพลตฟอร์มคอนเทนเนอร์และคอนเทนเนอร์กำลังทำงานอยู่ที่ใด มีหลายสิ่งที่เกิดขึ้นในภาพเมื่อเราพูดถึงความปลอดภัยของคอนเทนเนอร์และสิ่งที่ต้องดูแล
Image Provenance - มีการติดตั้งระบบการติดฉลากที่ปลอดภัยซึ่งระบุได้อย่างแน่นอนและไม่เปลี่ยนแปลงว่าคอนเทนเนอร์ที่ทำงานในสภาพแวดล้อมการผลิตมาจากที่ใด
Security Scanning - เครื่องสแกนภาพจะตรวจสอบภาพทั้งหมดโดยอัตโนมัติเพื่อหาช่องโหว่ที่ทราบ
Auditing - สภาพแวดล้อมการผลิตได้รับการตรวจสอบอย่างสม่ำเสมอเพื่อให้แน่ใจว่าคอนเทนเนอร์ทั้งหมดเป็นไปตามคอนเทนเนอร์ที่ทันสมัยและทั้งโฮสต์และคอนเทนเนอร์ได้รับการกำหนดค่าอย่างปลอดภัย
Isolation and Least Privilege- คอนเทนเนอร์ทำงานด้วยทรัพยากรและสิทธิ์ขั้นต่ำที่จำเป็นในการทำงานอย่างมีประสิทธิภาพ พวกเขาไม่สามารถรบกวนโฮสต์หรือคอนเทนเนอร์อื่น ๆ ได้มากเกินไป
Runtime Threat Detection - ความสามารถที่ตรวจจับภัยคุกคามที่ใช้งานอยู่กับแอปพลิเคชันคอนเทนเนอร์ในรันไทม์และตอบสนองโดยอัตโนมัติ
Access Controls - โมดูลความปลอดภัยของ Linux เช่น AppArmor หรือ SELinux ใช้เพื่อบังคับใช้การควบคุมการเข้าถึง
มีวิธีการหลักสองสามวิธีในการเก็บถาวรความปลอดภัยของคอนเทนเนอร์
- การควบคุมการเข้าถึงผ่าน oAuth
- ผ่านเว็บคอนโซลแบบบริการตนเอง
- โดยใบรับรองของแพลตฟอร์ม
การควบคุมการเข้าถึงผ่าน OAuth
ในวิธีนี้การตรวจสอบสิทธิ์การเข้าถึงการควบคุม API จะถูกเก็บถาวรเพื่อรับโทเค็นที่ปลอดภัยสำหรับการพิสูจน์ตัวตนผ่านเซิร์ฟเวอร์ OAuth ซึ่งมาพร้อมกับเครื่องต้นแบบ OpenShift ในฐานะผู้ดูแลระบบคุณมีความสามารถในการแก้ไขการกำหนดค่าของการกำหนดค่าเซิร์ฟเวอร์ OAuth
สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับการกำหนดค่าเซิร์ฟเวอร์ OAuth โปรดดูบทที่ 5 ของบทช่วยสอนนี้
ผ่านเว็บคอนโซลแบบบริการตนเอง
คุณลักษณะด้านความปลอดภัยของเว็บคอนโซลนี้มีอยู่ในเว็บคอนโซล OpenShift คอนโซลนี้ช่วยให้มั่นใจได้ว่าทีมทั้งหมดที่ทำงานร่วมกันจะไม่สามารถเข้าถึงสภาพแวดล้อมอื่น ๆ ได้หากไม่มีการพิสูจน์ตัวตน multi-telnet master ใน OpenShift มีคุณสมบัติด้านความปลอดภัยดังต่อไปนี้ -
- เปิดใช้เลเยอร์ TCL แล้ว
- ใช้ใบรับรอง x.509 สำหรับการตรวจสอบสิทธิ์
- ยึดคอนฟิกูเรชัน etcd บนเครื่องหลัก
โดยใบรับรองของแพลตฟอร์ม
ในวิธีนี้ใบรับรองสำหรับแต่ละโฮสต์จะถูกกำหนดค่าระหว่างการติดตั้งผ่าน Ansible เนื่องจากใช้โปรโตคอลการสื่อสาร HTTPS ผ่าน Rest API เราจึงต้องมีการเชื่อมต่อที่ปลอดภัย TCL กับส่วนประกอบและวัตถุต่างๆ ใบรับรองเหล่านี้เป็นใบรับรองที่กำหนดไว้ล่วงหน้าอย่างไรก็ตามใบรับรองที่กำหนดเองสามารถติดตั้งบนคลัสเตอร์หลักเพื่อเข้าถึงได้ ในระหว่างการตั้งค่าเริ่มต้นของต้นแบบใบรับรองที่กำหนดเองสามารถกำหนดค่าได้โดยการแทนที่ใบรับรองที่มีอยู่โดยใช้openshift_master_overwrite_named_certificates พารามิเตอร์.
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"}]
สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับวิธีสร้างใบรับรองที่กำหนดเองโปรดไปที่ลิงค์ต่อไปนี้ -
https://www.linux.com/learn/creating-self-signed-ssl-certificates-apache-linux
ความปลอดภัยของเครือข่าย
ใน OpenShift จะใช้ Software Defined Networking (SDN) สำหรับการสื่อสาร เนมสเปซเครือข่ายใช้สำหรับแต่ละพ็อดในคลัสเตอร์โดยแต่ละพ็อดจะได้รับ IP ของตัวเองและช่วงของพอร์ตเพื่อรับทราฟฟิกเครือข่าย โดยวิธีนี้เราสามารถแยกพ็อดเนื่องจากไม่สามารถสื่อสารกับพ็อดในโครงการอื่นได้
การแยกโครงการ
ซึ่งสามารถทำได้โดยผู้ดูแลระบบคลัสเตอร์โดยใช้สิ่งต่อไปนี้ oadm command จาก CLI
$ oadm pod-network isolate-projects <project name 1> <project name 2>
ซึ่งหมายความว่าโครงการที่กำหนดไว้ข้างต้นไม่สามารถสื่อสารกับโครงการอื่นในคลัสเตอร์
ความปลอดภัยระดับเสียง
การรักษาความปลอดภัยระดับเสียงหมายถึงการรักษาความปลอดภัยของ PV และ PVC ของโครงการในคลัสเตอร์ OpenShift ส่วนใหญ่มีสี่ส่วนในการควบคุมการเข้าถึงไดรฟ์ข้อมูลใน OpenShift
- กลุ่มเสริม
- fsGroup
- runAsUser
- seLinuxOptions
Supplemental Groups - กลุ่มเสริมคือกลุ่ม Linux ปกติ เมื่อกระบวนการทำงานในระบบจะรันด้วย ID ผู้ใช้และ ID กลุ่ม กลุ่มเหล่านี้ใช้สำหรับควบคุมการเข้าถึงพื้นที่เก็บข้อมูลที่แชร์
ตรวจสอบการเมาท์ NFS โดยใช้คำสั่งต่อไปนี้
# showmount -e <nfs-server-ip-or-hostname>
Export list for f21-nfs.vm:
/opt/nfs *
ตรวจสอบรายละเอียด NFS บนเซิร์ฟเวอร์เมาท์โดยใช้คำสั่งต่อไปนี้
# 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)
/ opt / NFS /ส่งออกสามารถเข้าถึงได้โดยโพสต์454265 และกลุ่ม 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 ย่อมาจากกลุ่มระบบไฟล์ซึ่งใช้สำหรับการเพิ่มกลุ่มเสริมคอนเทนเนอร์ ID กลุ่มเสริมใช้สำหรับพื้นที่เก็บข้อมูลที่ใช้ร่วมกันและ fsGroup ใช้สำหรับบล็อกที่เก็บข้อมูล
kind: Pod
spec:
containers:
- name: ...
securityContext:
fsGroup: 2325
runAsUser
runAsUser ใช้ ID ผู้ใช้สำหรับการสื่อสาร สิ่งนี้ใช้ในการกำหนดอิมเมจคอนเทนเนอร์ในนิยามพ็อด ผู้ใช้ ID เดียวสามารถใช้ได้ในทุกคอนเทนเนอร์หากจำเป็น
ขณะเรียกใช้คอนเทนเนอร์รหัสที่กำหนดจะจับคู่กับ ID เจ้าของในการส่งออก หาก ID ที่ระบุถูกกำหนดไว้ภายนอก ID นั้นจะกลายเป็นโกลบอลสำหรับคอนเทนเนอร์ทั้งหมดในพ็อด หากมีการกำหนดด้วยพ็อดเฉพาะมันจะกลายเป็นเฉพาะสำหรับคอนเทนเนอร์เดียว
spec:
containers:
- name: ...
securityContext:
runAsUser: 454265