Docker Security
Architektur und Sicherheitsfunktionen von
Containervirtualisierungen
Nils Magnus
GUUG-Frühjahrsfachgespräc...
Jump on the Bandwagon
Docker ist Hype! Doch worum geht es da eigentlich genau?
●
In erster Linie keine neue Virtualisierun...
Docker und seine Grundlagen
Leichtgewichtige
Containervirtualisierung
Greift auf Kernelfunktionen
zurück, die teilweise sc...
Docker ist beliebt …

… zu beliebt?

Features beeindruckend.

Sicherheit bleibt schnell außen vor:

Security außerhalb...
Angriffsszenarien auf Docker

Chroot-Escape

Sniffer

Zugriff mit allen Capabilitys

Direkter Zugriff auf Block-Device...
Beispiel für Chroot-Outbreak
Ausbrüche sind nicht immer offensichtlich.
Den Syscall chroot() und das gleichnamige Kommando...
Virtualisierung im Vergleich
Physikalischer Host Virtuelle Maschine Container
Gemeinsame
Ressourcen
Teilen sich das Netz T...
Isolation durch Namespaces

Sichtbarkeit nur von eigenen Prozessen, Usern,
Partitionen:
$ sudo docker run -it ubuntu /bin...
Capabilitys

Entzug einiger Capabilitys verhindert trotz (scheinbarer)
Rootrechte das Wiederherstellen des Status quo ant...
Gefährliches Einfallstor

Syscall-Schnittstelle ist der Eintrittspunkt in den
gemeinsam genutzten Kernel

Capabilitys si...
Shocker

Von Sebastian Kramer aus dem Openwall im Juni 2014
veröffentlicherter Proof-of-Concept

Docker erzeugt beim Sta...
Lokale Ressourcen
Was lässt sich schützen?

Bei Zugriff auf Kernel: nichts

Bei Zugriff auf Hardware: wenig

Nicht verg...
Docker im Einsatz
Sehr praktisch und ein Erfolgsfaktor für Docker:
Der Docker-Hub/Registry. Doch:

Woher kommen die Image...
Netzwerk-Sicherheit

Üblicherweise hängen alle Container an einer Bridge

alle Container sind in einem Segment: keine be...
Architektonische Kritik am Daemon

Docker verwaltet alle Container-Operationen über
einen dauerhaften Daemon mit REST-Sch...
Empfehlungen extern (für den Host)
Nicht nur auf ein Pferd setzen: Mehrere Layer Security

AppArmor sichert Zugriff auf D...
Empfehlungen intern (für den Container)

Patchmanagement auch für Images bedenken
(entsprechende Zeilen im Dockerfile)

...
Wrap-up

Architektur und Technik von Docker:
Faszinierend, aber gefährlich komplex

Namespaces, Capabilitys, Syscalls is...
Fragen.
Sie.
Jetzt!
Vielen Dank für Ihre Aufmerksamkeit!
Kontakt
Nils Magnus
Senior Systems Engineer
inovex GmbH
Office München
Valentin-Linho...
Nächste SlideShare
Wird geladen in …5
×

Docker Security - Architektur und Sicherheitsfunktionen von Containervirtualisierungen

622 Aufrufe

Veröffentlicht am

GUUG-Frühjahrsfachgespräch
Speaker: Nils Magnus, inovex GmbH

Mehr Vorträge von uns: https://www.inovex.de/de/content-pool/vortraege/

Veröffentlicht in: Technologie
0 Kommentare
2 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
622
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
4
Aktionen
Geteilt
0
Downloads
6
Kommentare
0
Gefällt mir
2
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Docker Security - Architektur und Sicherheitsfunktionen von Containervirtualisierungen

  1. 1. Docker Security Architektur und Sicherheitsfunktionen von Containervirtualisierungen Nils Magnus GUUG-Frühjahrsfachgespräch 2015, Stuttgart, 26. März 2015
  2. 2. Jump on the Bandwagon Docker ist Hype! Doch worum geht es da eigentlich genau? ● In erster Linie keine neue Virtualisierungstechnik ● Nicht wichtig, wie performant Docker ist. Standardisierung: ● einfache Schnittstelle zwischen Development und Operations ● vielleicht Katalysator für echte DevOps-Prozesse Gretchenfrage: Wie sicher ist die Technik in der Produktion? Vorwissen, Zielgruppe: Systemarchitekten mit Grundlagenwissen über Docker oder anderen Containervirtualisierungen
  3. 3. Docker und seine Grundlagen Leichtgewichtige Containervirtualisierung Greift auf Kernelfunktionen zurück, die teilweise schon ziemlich alt sind: ● LXC, ● Namespaces, ● Cgroups und ● Layered Filesystems. Fast alle Komponenten lassen sich austauschen. Fühlt sich wie eine Virtualisierung an, steht aber nicht im Wettbewerb zu KVM, Xen & Co. ● Vorstellbar wie eine aufgebohrte Chroot-Umgebung ● Isolation von Ressourcen ● Gemeinsame Kernelnutzung „Container 01 KM J“ von KM J aus der deutschsprachigen W ikipedia. Lizenziert unter CC BY-SA 3.0 über W ikimediaCommons
  4. 4. Docker ist beliebt …  … zu beliebt?  Features beeindruckend.  Sicherheit bleibt schnell außen vor:  Security außerhalb der Spielkiste vergessen  Ansatz der Docker-Entwickler: "Protect against mistake, not abuse!"
  5. 5. Angriffsszenarien auf Docker  Chroot-Escape  Sniffer  Zugriff mit allen Capabilitys  Direkter Zugriff auf Block-Devices  Potentially Hostile Tenants  Secure Administration and Management
  6. 6. Beispiel für Chroot-Outbreak Ausbrüche sind nicht immer offensichtlich. Den Syscall chroot() und das gleichnamige Kommando existieren seit 1979. Sie sind zwar nicht als Sicherheitsfunktion gedacht, erlauben aber einen Ausbruch aus dem Chroot-Jail: #include <unistd.h> #define DIR "xxx" int main() { int i; mkdir(DIR, 0755); chroot(DIR); for (i = 0; i < 1024; i++) chdir(".."); chroot("."); execl("/bin/sh", "-i", NULL); }
  7. 7. Virtualisierung im Vergleich Physikalischer Host Virtuelle Maschine Container Gemeinsame Ressourcen Teilen sich das Netz Teilen sich die Host-Hardware Teilen sich den Kernel Angriffsszenario Angriff per Netz auf offene Ports etc. Angriff auf Hypervisor Angriff per Syscall auf Kernel-Isolation (Namespaces, Cgroups, ...) Schutzmaß-nahmen Portfilter, Firewalls, Segmentierung der Netze Guter Hypervisor Absicherung im Containermanager, SE-Linux, Capabilitys Aufwand der Maßnahmen Einfach, Best Practices Komplex, aber zentral zu managen Vielschichtig durch relativ große Angriffsfläche
  8. 8. Isolation durch Namespaces  Sichtbarkeit nur von eigenen Prozessen, Usern, Partitionen: $ sudo docker run -it ubuntu /bin/bash root@257b138209be:/# ps aux USER PID %CPU %MEM VSZ RSS STAT START TIME COMMAND root 1 0.4 0.0 18176 1992 Ss 15:17 0:00 /bin/bash root 15 0.0 0.0 15568 1132 R+ 15:17 0:00 ps aux root@257b138209be:/# ip a […] 33: eth0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 02:42:ac:11:00:08 brd ff:ff:ff:ff:ff:ff inet 172.17.0.8/16 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::42:acff:fe11:8/64 scope link valid_lft forever preferred_lft forever
  9. 9. Capabilitys  Entzug einiger Capabilitys verhindert trotz (scheinbarer) Rootrechte das Wiederherstellen des Status quo ante # getpcaps $$ Capabilities for `22424': = cap_chown,cap_dac_override, cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_ setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_ne t_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,c ap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_ pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap _sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,c ap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_sy slog,cap_wake_alarm,cap_block_suspend+ep # docker run -it ubuntu /bin/bash root@39ed301e0731:/# getpcaps $$ Capabilities for `1': = cap_chown,cap_dac_override,cap_fowner, cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind _service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_ setfcap+eip
  10. 10. Gefährliches Einfallstor  Syscall-Schnittstelle ist der Eintrittspunkt in den gemeinsam genutzten Kernel  Capabilitys sind die Torwächter zu den Ressourcen der anderen Container  Innerhalb des Kernels ist das Thema komplex: Ein winziger Bug exploitet die komplette Isolation  Beispiel Shocker vom Juni 2014: Docker 0.11 (Vor- Vorgänger von 1.0) ermöglicht den Ausbruch aus dem Container
  11. 11. Shocker  Von Sebastian Kramer aus dem Openwall im Juni 2014 veröffentlicherter Proof-of-Concept  Docker erzeugt beim Start einen neuen Filesystem- Context und setzt per Bind-Mount neues „/“.  Container und Host nutzen innerhalb des Kernels die gleiche struct fs, um Bind-Mounts zu verwalten.  Wer kennt den Syscall open_by_handle_at()? Dazu braucht man die CAP_DAC_OVERRIDE, die Docker damals hatte.  Mit diesen Berechtigungen konnte man in den Inodes des Hosts suchen und dort z. B. dessen /etc/shadow lesen.
  12. 12. Lokale Ressourcen Was lässt sich schützen?  Bei Zugriff auf Kernel: nichts  Bei Zugriff auf Hardware: wenig  Nicht vergessen: Zugriff vom Host ist zwangsläufig immer möglich!  In Multi-Tenant-Umgebungen ist das durchaus eine wichtige Überlegung!
  13. 13. Docker im Einsatz Sehr praktisch und ein Erfolgsfaktor für Docker: Der Docker-Hub/Registry. Doch:  Woher kommen die Images?  Malicious Images erhalten Zugriff auf Host-System (vor Docker 1.3.3)  Wer paketiert nach welchen Kriterien? Diese Überlegung gilt für sämtliche Fremd-Software (Open Source + proprietär)! Keine Passwörter, Zertifikate, Credentials oder Unter- nehmensgeheimnisse in Container coden und uploaden!
  14. 14. Netzwerk-Sicherheit  Üblicherweise hängen alle Container an einer Bridge  alle Container sind in einem Segment: keine besondere netztechnische Trennung zwischen Containern  Host-Firewall reicht nicht aus:  Clustermanagement: (Etcd etc.) Kommunikation zwischen Nodes muss vertraulich und authentisch sein (kein Default) HostInternet Cont. 1 Cont. 4Cont. 2 Cont. 3
  15. 15. Architektonische Kritik am Daemon  Docker verwaltet alle Container-Operationen über einen dauerhaften Daemon mit REST-Schnittstelle  Nutzt normalerweise einen Unix-Domain-Socket  Mit Option -H lässt sich der Daemon an einen TCP- Port binden. Das braucht man für die Orchestrierung.  Gefährlich, wenn dieser Port extern erreichbar ist.  Nicht alle Verbindungen per Default verschlüsselt  Kritiker entwerfen neues Projekt Rocket, steckt aber noch in den Kinderschuhen.
  16. 16. Empfehlungen extern (für den Host) Nicht nur auf ein Pferd setzen: Mehrere Layer Security  AppArmor sichert Zugriff auf Dateien und Pfade.  Profil für SE-Linux trennt Host von Container  Labels und Profiles gibt’s schon fertig, sind aber trickreich im Detail  Pro Umgebung, Context oder Tenant ein separater Host  Einsatz von Seccomp als eine Art Syscall-Firewall  Allgemeines Kernel-Hardening mittels Grsecurity
  17. 17. Empfehlungen intern (für den Container)  Patchmanagement auch für Images bedenken (entsprechende Zeilen im Dockerfile)  Nur eine Anwendung pro Container  Trotz Container Least Privilege beachten  kein SSH in den Container erlauben  saubere Datenpfade (Vorsicht bei Volumes, die gesharte Verzeichnisse vom Host oder anderen Containern mounten)
  18. 18. Wrap-up  Architektur und Technik von Docker: Faszinierend, aber gefährlich komplex  Namespaces, Capabilitys, Syscalls isolieren lokal  Networking und Orchestrierung bieten noch Herausforderungen  Es gibt keine konzeptionell-inhärente Probleme, die gegen Docker sprechen  Methoden, um Probleme abzusichern, existieren!
  19. 19. Fragen. Sie. Jetzt!
  20. 20. Vielen Dank für Ihre Aufmerksamkeit! Kontakt Nils Magnus Senior Systems Engineer inovex GmbH Office München Valentin-Linhof Str. 2 81829 München Mobil: +49-173-3181-057 E-Mail: nils.magnus@inovex.de Sprechen Sie uns an auf unsere Referenzprojekte!

×