OpenShift - Sicherheit

OpenShift-Sicherheit ist hauptsächlich eine Kombination aus zwei Komponenten, die hauptsächlich Sicherheitsbeschränkungen behandeln.

• Sicherheitskontextbeschränkungen (SCC)
• Dienstkonto

Sicherheitskontextbeschränkungen (SCC)

Es wird im Wesentlichen für die Pod-Einschränkung verwendet. Dies bedeutet, dass die Einschränkungen für einen Pod definiert werden, z. B. welche Aktionen er ausführen kann und auf welche Dinge er im Cluster zugreifen kann.

OpenShift bietet eine Reihe vordefinierter SCC, die vom Administrator verwendet, geändert und erweitert werden können.

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

Wenn Sie einen vordefinierten scc verwenden möchten, können Sie dazu einfach den Benutzer oder die Gruppe zur scc-Gruppe hinzufügen.

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

Dienstkonto

Dienstkonten werden im Wesentlichen verwendet, um den Zugriff auf die OpenShift-Master-API zu steuern, die aufgerufen wird, wenn ein Befehl oder eine Anforderung von einem der Master- oder Knotencomputer ausgelöst wird.

Jedes Mal, wenn eine Anwendung oder ein Prozess eine Funktion erfordert, die vom eingeschränkten SCC nicht gewährt wird, müssen Sie ein bestimmtes Dienstkonto erstellen und das Konto dem jeweiligen SCC hinzufügen. Wenn ein SCC jedoch nicht Ihren Anforderungen entspricht, ist es besser, einen neuen SCC zu erstellen, der für Ihre Anforderungen spezifisch ist, als den am besten geeigneten zu verwenden. Legen Sie es am Ende für die Bereitstellungskonfiguration fest.

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

Containersicherheit

In OpenShift basiert die Sicherheit von Containern auf dem Konzept, wie sicher die Containerplattform ist und wo die Container ausgeführt werden. Es gibt mehrere Dinge, die ins Bild kommen, wenn wir über Containersicherheit sprechen und was erledigt werden muss.

Image Provenance - Es gibt ein sicheres Kennzeichnungssystem, das genau und unbestreitbar identifiziert, woher die in der Produktionsumgebung laufenden Container stammen.

Security Scanning - Ein Bildscanner überprüft automatisch alle Bilder auf bekannte Sicherheitslücken.

Auditing - Die Produktionsumgebung wird regelmäßig überprüft, um sicherzustellen, dass alle Container auf aktuellen Containern basieren und sowohl Hosts als auch Container sicher konfiguriert sind.

Isolation and Least Privilege- Container werden mit den minimalen Ressourcen und Berechtigungen ausgeführt, die für ein effektives Funktionieren erforderlich sind. Sie können den Host oder andere Container nicht übermäßig stören.

Runtime Threat Detection - Eine Funktion, die aktive Bedrohungen für containerisierte Anwendungen zur Laufzeit erkennt und automatisch darauf reagiert.

Access Controls - Linux-Sicherheitsmodule wie AppArmor oder SELinux werden verwendet, um Zugriffskontrollen durchzusetzen.

Es gibt nur wenige Schlüsselmethoden, mit denen die Containersicherheit archiviert wird.

• Zugriffskontrolle über oAuth
• Über Self-Service-Webkonsole
• Durch Zertifikate der Plattform

Zugriffskontrolle über OAuth

Bei dieser Methode wird die Authentifizierung beim Zugriff auf die API-Steuerung archiviert, wobei ein gesichertes Token für die Authentifizierung über OAuth-Server abgerufen wird, das auf dem OpenShift-Mastercomputer integriert ist. Als Administrator haben Sie die Möglichkeit, die Konfiguration der OAuth-Serverkonfiguration zu ändern.

Weitere Informationen zur OAuth-Serverkonfiguration finden Sie in Kapitel 5 dieses Lernprogramms.

Über die Self-Service-Webkonsole

Diese Sicherheitsfunktion für die Webkonsole ist in die OpenShift-Webkonsole integriert. Diese Konsole stellt sicher, dass alle Teams, die zusammenarbeiten, ohne Authentifizierung keinen Zugriff auf andere Umgebungen haben. Der Multi-Telnet-Master in OpenShift verfügt über die folgenden Sicherheitsfunktionen:

• TCL-Schicht ist aktiviert
• Verwendet das x.509-Zertifikat zur Authentifizierung
• Sichert die etcd-Konfiguration auf dem Master-Computer

Durch Plattformzertifikate

Bei dieser Methode werden Zertifikate für jeden Host während der Installation über Ansible konfiguriert. Da das HTTPS-Kommunikationsprotokoll über die Rest-API verwendet wird, benötigen wir eine TCL-gesicherte Verbindung zu verschiedenen Komponenten und Objekten. Dies sind vordefinierte Zertifikate. Es kann jedoch sogar ein benutzerdefiniertes Zertifikat für den Zugriff auf dem Mastercluster installiert werden. Während der Ersteinrichtung des Masters können benutzerdefinierte Zertifikate konfiguriert werden, indem die vorhandenen Zertifikate mit überschrieben werdenopenshift_master_overwrite_named_certificates Parameter.

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

Weitere Informationen zum Generieren benutzerdefinierter Zertifikate finden Sie unter folgendem Link:

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

Netzwerksicherheit

In OpenShift wird Software Defined Networking (SDN) für die Kommunikation verwendet. Der Netzwerk-Namespace wird für jeden Pod im Cluster verwendet, wobei jeder Pod seine eigene IP und eine Reihe von Ports erhält, um den Netzwerkverkehr darauf abzurufen. Mit dieser Methode können Pods isoliert werden, aufgrund derer sie nicht mit Pods im anderen Projekt kommunizieren können.

Ein Projekt isolieren

Dies kann vom Cluster-Administrator wie folgt durchgeführt werden oadm command von CLI.

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

Dies bedeutet, dass die oben definierten Projekte nicht mit anderen Projekten im Cluster kommunizieren können.

Volumensicherheit

Volumensicherheit bedeutet eindeutig, die PV und PVC von Projekten im OpenShift-Cluster zu sichern. Es gibt hauptsächlich vier Abschnitte, um den Zugriff auf Volumes in OpenShift zu steuern.

• Ergänzende Gruppen
• fsGroup
• runAsUser
• seLinuxOptions

Ergänzungsgruppen - Ergänzungsgruppen sind reguläre Linux-Gruppen. Wenn ein Prozess im System ausgeführt wird, wird er mit einer Benutzer-ID und einer Gruppen-ID ausgeführt. Diese Gruppen werden zum Steuern des Zugriffs auf gemeinsam genutzten Speicher verwendet.

Überprüfen Sie die NFS-Bereitstellung mit dem folgenden Befehl.

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

Überprüfen Sie die NFS-Details auf dem Mount-Server mit dem folgenden Befehl.

# 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)

Auf / opt / nfs / export kann über die UID zugegriffen werden454265 und die Gruppe 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 steht für die Dateisystemgruppe, mit der zusätzliche Containergruppen hinzugefügt werden. Die Ergänzungsgruppen-ID wird für den gemeinsam genutzten Speicher und die fsGroup für die Blockspeicherung verwendet.

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

runAsUser

runAsUser verwendet die Benutzer-ID für die Kommunikation. Dies wird zum Definieren des Containerbilds in der Pod-Definition verwendet. Bei Bedarf kann in allen Containern ein einzelner ID-Benutzer verwendet werden.

Während der Ausführung des Containers wird die definierte ID beim Export mit der Eigentümer-ID abgeglichen. Wenn die angegebene ID außerhalb definiert ist, wird sie für alle Container im Pod global. Wenn es mit einem bestimmten Pod definiert ist, wird es spezifisch für einen einzelnen Container.

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