OpenShift - Güvenlik

OpenShift güvenliği, esas olarak güvenlik kısıtlamalarını yöneten iki bileşenin birleşimidir.

• Güvenlik Bağlamı Kısıtlamaları (SCC)
• Hizmet Hesabı

Güvenlik Bağlamı Kısıtlamaları (SCC)

Temel olarak kapsül kısıtlaması için kullanılır, yani bir kapsülün sınırlamalarını, hangi eylemleri gerçekleştirebileceği ve kümede erişebileceği her şeyde olduğu gibi tanımladığı anlamına gelir.

OpenShift, yönetici tarafından kullanılabilen, değiştirilebilen ve genişletilebilen bir dizi önceden tanımlanmış SCC sağlar.

$ 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>

Önceden tanımlanmış herhangi bir scc kullanmak istenirse, bu sadece kullanıcı veya grubu scc grubuna ekleyerek yapılabilir.

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

Hizmet Hesabı

Hizmet hesapları, temel olarak, ana makinelerin veya düğüm makinelerinin herhangi birinden bir komut veya istek çalıştırıldığında çağrılan OpenShift ana API'sine erişimi kontrol etmek için kullanılır.

Bir uygulama veya işlem, kısıtlı SCC tarafından verilmeyen bir yeteneği gerektirdiğinde, belirli bir hizmet hesabı oluşturmanız ve hesabı ilgili SCC'ye eklemeniz gerekecektir. Bununla birlikte, bir SCC gereksinimlerinize uymuyorsa, en uygun olanı kullanmak yerine gereksinimlerinize özgü yeni bir SCC oluşturmak daha iyidir. Sonunda, dağıtım yapılandırması için ayarlayın.

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

Konteyner Güvenliği

OpenShift'te, konteynerlerin güvenliği, konteyner platformunun ne kadar güvenli olduğu ve konteynerlerin nerede çalıştığı kavramına dayanır. Konteyner güvenliği ve nelere dikkat edilmesi gerektiği hakkında konuştuğumuzda ortaya çıkan birçok şey var.

Image Provenance - Üretim ortamında çalışan konteynerlerin nereden geldiğini tam olarak ve tartışılmaz bir şekilde tanımlayan güvenli bir etiketleme sistemi mevcuttur.

Security Scanning - Bir görüntü tarayıcı, tüm görüntüleri bilinen güvenlik açıklarına karşı otomatik olarak kontrol eder.

Auditing - Tüm kapların güncel kaplara dayandığından ve hem ana bilgisayarların hem de kapların güvenli bir şekilde yapılandırıldığından emin olmak için üretim ortamı düzenli olarak denetlenir.

Isolation and Least Privilege- Kapsayıcılar, etkili bir şekilde çalışması için gereken minimum kaynaklar ve ayrıcalıklarla çalışır. Ev sahibine veya diğer kaplara gereksiz yere müdahale edemezler.

Runtime Threat Detection - Çalışma zamanında kapsayıcıya alınmış uygulamaya karşı etkin tehditleri algılayan ve buna otomatik olarak yanıt veren bir yetenek.

Access Controls - Erişim kontrollerini uygulamak için AppArmor veya SELinux gibi Linux güvenlik modülleri kullanılır.

Konteyner güvenliğinin arşivlendiği birkaç anahtar yöntem vardır.

• OAuth aracılığıyla erişimi kontrol etme
• Self servis web konsolu aracılığıyla
• Platform Sertifikalarına göre

OAuth aracılığıyla Erişimi Kontrol Etme

Bu yöntemde, API kontrol erişiminde kimlik doğrulama, OpenShift ana makinesinde yerleşik olarak gelen OAuth sunucuları aracılığıyla kimlik doğrulaması için güvenli bir belirteç alınarak arşivlenir. Yönetici olarak, OAuth sunucu yapılandırmasının yapılandırmasını değiştirme olanağına sahipsiniz.

OAuth sunucu yapılandırması hakkında daha fazla ayrıntı için bu eğiticinin 5. Bölümüne bakın.

Self Servis Web Konsolu aracılığıyla

Bu web konsolu güvenlik özelliği OpenShift web konsolunda yerleşiktir. Bu konsol, birlikte çalışan tüm ekiplerin kimlik doğrulama olmadan diğer ortamlara erişememesini sağlar. OpenShift'teki çoklu telnet ana birimi aşağıdaki güvenlik özelliklerine sahiptir:

• TCL katmanı etkinleştirildi
• Kimlik doğrulama için x.509 sertifikası kullanır
• Ana makinede etcd yapılandırmasını güvenli hale getirir

Platform Sertifikalarına Göre

Bu yöntemde, her ana bilgisayar için sertifikalar, Ansible aracılığıyla kurulum sırasında yapılandırılır. Rest API üzerinden HTTPS iletişim protokolünü kullandığından, farklı bileşenlere ve nesnelere TCL güvenli bağlantıya ihtiyacımız var. Bunlar önceden tanımlanmış sertifikalardır, ancak erişim için ana kümeye özel bir sertifika bile yüklenebilir. Ana cihazın ilk kurulumu sırasında, özel sertifikalar, mevcut sertifikalar kullanılarak geçersiz kılınarak yapılandırılabilir.openshift_master_overwrite_named_certificates parametre.

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"}]

Özel sertifikaların nasıl oluşturulacağı hakkında daha fazla ayrıntı için aşağıdaki bağlantıyı ziyaret edin -

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

Ağ güvenliği

OpenShift'te, iletişim için Yazılım Tanımlı Ağ (SDN) kullanılır. Ağ ad alanı, kümedeki her bölme için kullanılır; burada her bölme, üzerinde ağ trafiğini almak için kendi IP'sini ve bir dizi bağlantı noktasını alır. Bu yöntemle, diğer projedeki podlarla iletişim kuramadığı için podlar izole edilebilir.

Bir Projeyi İzole Etmek

Bu, aşağıdakiler kullanılarak küme yöneticisi tarafından yapılabilir oadm command CLI'den.

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

Bu, yukarıda tanımlanan projelerin kümedeki diğer projelerle iletişim kuramayacağı anlamına gelir.

Birim Güvenliği

Hacim güvenliği, OpenShift kümesindeki projelerin PV ve PVC'sini güvence altına almak anlamına gelir. OpenShift'te birimlere erişimi kontrol etmek için başlıca dört bölüm vardır.

• Ek Gruplar
• fsGroup
• runAsUser
• seLinuxOptions

Ek Gruplar - Ek gruplar, normal Linux gruplarıdır. Sistemde bir işlem çalıştığında, bir kullanıcı kimliği ve grup kimliği ile çalışır. Bu gruplar, paylaşılan depolamaya erişimi kontrol etmek için kullanılır.

Aşağıdaki komutu kullanarak NFS montajını kontrol edin.

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

Aşağıdaki komutu kullanarak bağlama sunucusundaki NFS ayrıntılarını kontrol edin.

# 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 / ihracat UID ile ulaşılabilir454265 ve grup 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, kapsayıcı ek grupları eklemek için kullanılan dosya sistemi grubunu ifade eder. Ek grup kimliği, paylaşılan depolama için kullanılır ve fsGroup, blok depolama için kullanılır.

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

runAsUser

runAsUser, iletişim için kullanıcı kimliğini kullanır. Bu, kapsayıcı görüntüsünün kapsül tanımında tanımlanmasında kullanılır. Gerekirse tüm konteynerlerde tek bir ID kullanıcı kullanılabilir.

Kapsayıcı çalıştırılırken, tanımlanmış kimlik, dışa aktarmadaki sahip kimliği ile eşleştirilir. Belirtilen kimlik dışarıda tanımlanırsa, bölmedeki tüm kaplar için genel olur. Belirli bir kapsülle tanımlanmışsa, o zaman tek bir kaba özgü hale gelir.

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