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