Linux OS - info, how-to, pitanja, novosti, savjeti, problemi...

[stef]

Za fallback trebaš minimalno 2 stroja, VIP (haproxy + keepalived), master-master replikaciju baze.
Containeri ti tu mogu pomoći samo da imaš gotov setup koji možeš brzo upogonit na drugom stroju i tu ne bih koristio mrežnu izolaciju nego host network.
Za app file sistem pretpostavljam Gluster?

[domy_os]

Da, za fallback sam mislio tako nešto, a Gluster nisam imao pojma što je. Nakon guglanja, mislim da bi mi to bio overkill za ovaj projekt, ali hvala na hintu.

[tomek@vz]

Containeri imaju prednost sto omogucavaju agilnost projekta (dakle mnogo cestih izmjena koda pa u kombinaciji sa Openshift/Kubernetes/Jenkins rijesenjima mozes sve automatizirat). Osobno ne vidim prednosti takvih rijesenja na aplikacijama ovog tipa kao sto si opisao. Mozes to i ovdje koristiti, dapace, no iskreno - sto bi falilo dobro poslozenom sustavu sa backupom sustava + baze? Ak te ovo zeza - KISS (Keep it simple, stupid). Napravis sys-level backup dodatno jednom mjesecno i u slucaju havarije u roku pol sata sustav opet radi. Uzmi kaj bolje mozes administrirat i rijesavat probleme u slucaju havarije i bok.

[Ivo_Strojnica]

Apsolutno se slazem.
Po meni ovo nije scenarij di treba container.
Native instalacija + standardni backup.

[domy_os]

OK, onda ću polako migrirati na čisti server bez Dockera. To mi je isto palo na pamet, ali containeri imaju hrpu nekih skripti pa bi to predugo potrajalo. Upogonit ću ovako kako je sada jer gori, a kasnije lako napravim migraciju baze na native OS. Hvala na prijedlozima.

[No123]

Možda nekom posluži: https://web.archive.org/web/20080224.../vi-cheat.html

[Nick7]

Ak' postoji gotov docker, zasto ne?
Lako napraviti upgrade, lako maknuti ako ne treba. Ne trosi nesto vise resursa (trosi malo vise diska).
I security je visi nego samo ak' se vrti direkt na OS-u.
Sve u svemu, dockeri su zgodna stvar.

[tomek@vz]

Autor Nick7

I security je visi nego samo ak' se vrti direkt na OS-u.
Sve u svemu, dockeri su zgodna stvar.

Daj molim te ovo elaboriraj. Ne kazem da nisi u pravu - zanima me posto se oko DevSecOps-a lome koplja...

1. Kernel exploits from a container
If someone exploits a kernel bug inside a container, they exploited it on the host OS. If this exploit allows for code execution, it will be executed on the host OS, not inside the container.
If this exploit allows for arbitrary memory access, the attacker can change or read any data for any other container.
On a VM, the process is longer: the attacker would have to exploit both the VM kernel, the hypervisor, and the host kernel (and this may not be the same as the VM kernel).
2. Resource starvation
As all the containers share the same kernel and the same resources, if the access to some resource is not constrained, one container can use it all up and starve the host OS and the other containers.
On a VM, the resources are defined by the hypervisor, so no VM can deny the host OS from any resource, as the hypervisor itself can be configured to make restricted use of resources.
3. Container breakout
If any user inside a container is able to escape the container using some exploit or misconfiguration, they will have access to all containers running on the host. That happens because the same user running the docker engine is the user running the containers. If any exploit executes code on the host, it will execute under the privileges of the docker engine, so it can access any container.
4. Data separation
On a docker container, there're some resources that are not namespaced:

• SELinux
• Cgroups
• file systems under /sys, /proc/sys,
• /proc/sysrq-trigger, /proc/irq, /proc/bus
• /dev/mem, /dev/sd* file system
• Kernel Modules

If any attacker can exploit any of those elements, they will own the host OS.
A VM OS will not have direct access to any of those elements. It will talk to the hypervisor, and the hypervisor will make the appropriate system calls to the host OS. It will filter out invalid calls, adding a layer of security.
5. Raw Sockets
The default Docker Unix socket (/var/run/docker.sock) can be mounted by any container if not properly secured. If some container mounts this socket, it can shutdown, start or create new images.
If it's properly configured and secured, you can achieve a high level of security with a docker container, but it will be less than a properly configured VM. No matter how much hardening tools are employed, a VM will always be more secure. Bare metal isolation is even more secure than a VM. Some bare metal implementations (IBM PR/SM for example) can guarantee that the partitions are as separated as if they were on separate hardware. As far as I know, there's no way to escape a PR/SM virtualization.

Edit: Naletio na jos jedan zanimljiv clanak:


https://about.gitlab.com/blog/2023/0...ource=linkedin

[Nick7]

@tomek@vz: Kao sto i sam rekao...
Prednost dockera je da je lagan deploy, nemas system dependancy-e. Sa security strane, ako je bug u aplikaciji, netko uleti u docker - docker sam po sebi je vec okrljastren, pa i nacin za izaci 'izvan' njega je manji. Kad uleti na OS gdje je sve native instalirano, puno je lakse.
Nije da je docker neprobojan, ali je ipak jos jedan layer zastite.

[tomek@vz]

Autor Nick7

@tomek@vz: Kao sto i sam rekao...
Prednost dockera je da je lagan deploy, nemas system dependancy-e. Sa security strane, ako je bug u aplikaciji, netko uleti u docker - docker sam po sebi je vec okrljastren, pa i nacin za izaci 'izvan' njega je manji. Kad uleti na OS gdje je sve native instalirano, puno je lakse.
Nije da je docker neprobojan, ali je ipak jos jedan layer zastite.

To stoji. Mene zanima vise dali postoji nacin kako povisiti sigurnost kod docker konstrukta. Imam premalo prakticnih iskustva sa containerima ,a znam da ima ekipe koja je dublje u temi, zato pitam. Najvise me brine stavka gotovih deployment Skripti s weba koje dosta ekipe jednostavno preuzima i lupa u prod bez razmisljanja jer "lagani deployment". Jos malo pa cemo zbilja trebati AV rijesenja sa Linux strane Podman mi se malo vise svida posto omogucava izvodenje podova na user razini - teoretski manji impact al ono...

[Nick7]

To je, podman se vrti na user razini, i sa te strane je 'sigurniji'. Koliko vidim, izgleda da podman ima sve vecu trakciju.
Prednost je sto podman moze odmah vrtiti i 'stare' dockere.
Ukratko, ak' sad se krece s tim: podman > docker

[stef]

@tomek
Koristis provjerene image (obicno sluzbene za neki projekt) Eventualno ih mozes poskenirati Trivy-em. Ne koristis root unutar containera, ako ne trebas, Itd. Sve isto kao za Os servis.

[tomek@vz]

Autor stef

@tomek
Koristis provjerene image (obicno sluzbene za neki projekt) Eventualno ih mozes poskenirati Trivy-em. Ne koristis root unutar containera, ako ne trebas, Itd. Sve isto kao za Os servis.

No krasno...ovi moji "strucnjaci" nist od toga ne koriste za svoje sustave...root je "normala". Image skinu s neta, drljaju po njemu malo i - eto sluzbeno je. A ja mislio da ja nemam pojma
Kolko vidim Trivy je nekaj tipa Nessus/OpenVas?


Thanks na infu decki

[Nick7]

Pa k'o svaki 'pravi' sysadmin. Slozis sve pod rootom, ali prva stvar je disable-ati firewall
Naravno, pozeljno je i dopustiti root da se spoji ssh-om s neta... je'l zasto gubiti vrijeme na tamo neke VPN-ove

[tomek@vz]

Autor Nick7

Pa k'o svaki 'pravi' sysadmin. Slozis sve pod rootom, ali prva stvar je disable-ati firewall
Naravno, pozeljno je i dopustiti root da se spoji ssh-om s neta... je'l zasto gubiti vrijeme na tamo neke VPN-ove

Exacto Al onda kukanja iducih 6 mjeseci "pa kak se to moglo dogoditi" kad Script-kiddie razvali sve