OpenShift - bezpieczeństwo

Bezpieczeństwo OpenShift to głównie połączenie dwóch komponentów, które głównie obsługują ograniczenia bezpieczeństwa.

• Ograniczenia kontekstu bezpieczeństwa (SCC)
• Konto usługi

Ograniczenia kontekstu bezpieczeństwa (SCC)

Zasadniczo jest używany do ograniczenia kapsuły, co oznacza, że ​​definiuje ograniczenia dla kapsuły, takie jak czynności, które może wykonywać i do czego ma dostęp w klastrze.

OpenShift zapewnia zestaw predefiniowanych SCC, które mogą być używane, modyfikowane i rozszerzane przez administratora.

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

Jeśli ktoś chce użyć dowolnego wstępnie zdefiniowanego scc, można to zrobić po prostu dodając użytkownika lub grupę do grupy scc.

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

Konto usługi

Konta usług są zasadniczo używane do kontrolowania dostępu do głównego interfejsu API OpenShift, który jest wywoływany, gdy polecenie lub żądanie jest uruchamiane z dowolnej maszyny głównej lub węzła.

Za każdym razem, gdy aplikacja lub proces wymaga możliwości, która nie jest przyznana przez ograniczony SCC, będziesz musiał utworzyć określone konto usługi i dodać to konto do odpowiedniego SCC. Jeśli jednak SCC nie spełnia twoich wymagań, lepiej jest utworzyć nowy SCC specyficzny dla twoich wymagań, niż używać tego, który jest najlepiej dopasowany. Na koniec ustaw go dla konfiguracji wdrożenia.

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

Bezpieczeństwo kontenerów

W OpenShift bezpieczeństwo kontenerów opiera się na koncepcji tego, jak bezpieczna jest platforma kontenerowa i gdzie są uruchomione kontenery. Jest wiele rzeczy, które pojawiają się, kiedy mówimy o bezpieczeństwie kontenerów io tym, co należy zadbać.

Image Provenance - Wdrożono bezpieczny system etykietowania, który dokładnie i niezaprzeczalnie identyfikuje, skąd pochodzą pojemniki działające w środowisku produkcyjnym.

Security Scanning - Skaner obrazów automatycznie sprawdza wszystkie obrazy pod kątem znanych luk w zabezpieczeniach.

Auditing - Środowisko produkcyjne jest regularnie kontrolowane, aby upewnić się, że wszystkie kontenery są oparte na aktualnych kontenerach, a hosty i kontenery są bezpiecznie skonfigurowane.

Isolation and Least Privilege- Kontenery działają przy minimalnych zasobach i uprawnieniach potrzebnych do skutecznego działania. Nie są w stanie nadmiernie ingerować w hosta lub inne pojemniki.

Runtime Threat Detection - Możliwość, która wykrywa aktywne zagrożenia dla aplikacji w kontenerach w czasie wykonywania i automatycznie na nie reaguje.

Access Controls - Moduły bezpieczeństwa Linuksa, takie jak AppArmor lub SELinux, służą do egzekwowania kontroli dostępu.

Istnieje kilka kluczowych metod archiwizowania zabezpieczeń kontenerów.

• Kontrolowanie dostępu przez OAuth
• Za pomocą samoobsługowej konsoli internetowej
• Certyfikaty platformy

Kontrolowanie dostępu przez OAuth

W tej metodzie uwierzytelnianie w celu kontroli dostępu do interfejsu API jest archiwizowane, uzyskując zabezpieczony token do uwierzytelniania za pośrednictwem serwerów OAuth, który jest wbudowany w maszynę główną OpenShift. Jako administrator masz możliwość modyfikowania konfiguracji serwera OAuth.

Więcej informacji na temat konfiguracji serwera OAuth można znaleźć w rozdziale 5 tego samouczka.

Za pośrednictwem samoobsługowej konsoli internetowej

Ta funkcja bezpieczeństwa konsoli internetowej jest wbudowana w konsolę internetową OpenShift. Ta konsola zapewnia, że ​​wszystkie współpracujące ze sobą zespoły nie mają dostępu do innych środowisk bez uwierzytelnienia. Master multi-telnet w OpenShift ma następujące funkcje bezpieczeństwa -

• Warstwa TCL jest włączona
• Używa certyfikatu x.509 do uwierzytelniania
• Zabezpiecza konfigurację etcd na maszynie głównej

Za pomocą certyfikatów platformy

W tej metodzie certyfikaty dla każdego hosta są konfigurowane podczas instalacji za pośrednictwem Ansible. Ponieważ wykorzystuje protokół komunikacyjny HTTPS poprzez Rest API, potrzebujemy bezpiecznego połączenia TCL z różnymi komponentami i obiektami. Są to wstępnie zdefiniowane certyfikaty, jednak w celu uzyskania dostępu można nawet zainstalować certyfikat niestandardowy w klastrze master. Podczas początkowej konfiguracji certyfikatu głównego można skonfigurować niestandardowe certyfikaty, zastępując istniejące certyfikaty za pomocąopenshift_master_overwrite_named_certificates parametr.

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

Aby uzyskać więcej informacji na temat generowania certyfikatów niestandardowych, odwiedź poniższy link -

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

Bezpieczeństwo sieci

W OpenShift do komunikacji używana jest sieć definiowana programowo (SDN). Sieciowa przestrzeń nazw jest używana dla każdego poda w klastrze, przy czym każdy pod otrzymuje własny adres IP i zakres portów, aby uzyskać na nim ruch sieciowy. W ten sposób można izolować strąki, z powodu których nie może się komunikować z zasobnikami w innym projekcie.

Izolowanie projektu

Może to zrobić administrator klastra, korzystając z następującego polecenia oadm command z CLI.

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

Oznacza to, że projekty zdefiniowane powyżej nie mogą komunikować się z innymi projektami w klastrze.

Bezpieczeństwo wolumenu

Bezpieczeństwo wolumenu wyraźnie oznacza zabezpieczenie PV i PVC projektów w klastrze OpenShift. Istnieją głównie cztery sekcje kontrolujące dostęp do woluminów w OpenShift.

• Grupy dodatkowe
• fsGroup
• runAsUser
• seLinuxOptions

Grupy dodatkowe - grupy dodatkowe to zwykłe grupy systemu Linux. Gdy proces działa w systemie, działa z identyfikatorem użytkownika i identyfikatorem grupy. Te grupy służą do kontrolowania dostępu do pamięci współużytkowanej.

Sprawdź podłączenie NFS za pomocą następującego polecenia.

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

Sprawdź szczegóły NFS na serwerze montowania, używając następującego polecenia.

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

Plik / opt / nfs / export jest dostępny przez UID454265 i 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 oznacza grupę systemu plików, która jest używana do dodawania dodatkowych grup kontenerów. Identyfikator grupy suplementów jest używany do przechowywania współdzielonego, a fsGroup jest używany do przechowywania blokowego.

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

runAsUser

runAsUser używa identyfikatora użytkownika do komunikacji. Służy do definiowania obrazu kontenera w definicji poda. W razie potrzeby we wszystkich kontenerach można użyć jednego identyfikatora użytkownika.

Podczas uruchamiania kontenera zdefiniowany identyfikator jest dopasowywany do identyfikatora właściciela podczas eksportu. Jeśli określony identyfikator jest zdefiniowany na zewnątrz, staje się globalny dla wszystkich kontenerów w pod. Jeśli jest zdefiniowany z określonym kapsułą, staje się specyficzny dla pojedynczego kontenera.

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