DevDay 2017: Christof Fetzer - SCONE: Secure Linux Container Environments with Intel SGX
•
1 like•1,041 views
In multi-tenant environments, Linux containers managed by Docker or Kubernetes have a lower resource footprint, faster startup times, and higher I/O performance compared to virtual machines (VMs) on hypervisors. Yet their weaker isolation guarantees, enforced through software kernel mechanisms, make it easier for attackers to compromise the confidentiality and integrity of application data within containers. We describe SCONE, a secure container mechanism for Docker that uses the SGX trusted execution support of Intel CPUs to protect container processes from outside attacks. The design of SCONE leads to (i) a small trusted computing base (TCB) and (ii) a low performance overhead: SCONE offers a secure C standard library interface that transparently encrypts/decrypts I/O data; to reduce the performance impact of thread synchronization and system calls within SGX enclaves, SCONE supports user-level threading and asynchronous system calls. Our evaluation shows that it protects unmodified applications with SGX, achieving 0.6x - 1.2x of native throughput.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (9)
Similar to DevDay 2017: Christof Fetzer - SCONE: Secure Linux Container Environments with Intel SGX
Similar to DevDay 2017: Christof Fetzer - SCONE: Secure Linux Container Environments with Intel SGX (20)
More from DevDay Dresden
More from DevDay Dresden (20)
Recently uploaded
Recently uploaded (20)
DevDay 2017: Christof Fetzer - SCONE: Secure Linux Container Environments with Intel SGX
- 1. SCONE Secure CONtainer Environment Christof Fetzer, TU Dresden, Germany CC0 1
- 2. MOTIVATION application serviceprovider client client Prevent unauthorized access 2 hardware old days firewall data center
- 3. OBJECTIVE: PROTECT CONFIDENTIALITY & INTEGRITY application serviceprovider client client Prevent unauthorized access 3 hardware today application cloud client client data center
- 4. ONLY ACADEMIC ISSUE? https://arstechnica.com/security/2017/03/hack-that-escapes-vm-by-exploiting-edge-browser-fetches-105000-at-pwn2own/ windows VMWare hypervisor bug in Windows 10 bug in VMware Workstation 2017 hacking contest application Linux 4
- 5. GENERAL APPROACH ➤ „Firewall“ around the application ➤ application-oriented security ➤ Cloud-Native Applications ➤ set of microservices 5
- 6. APPROACH: APPLICATION-ORIENTED SECURITY µservice … µservice µservice … µservice… (cloud native) application serviceprovider client client ➤ Protect application ➤ integrity ➤ confidentiality 6 External API
- 7. DEFENDER’S DILEMMA ➤ Attackers: ➤ success by exploiting a single vulnerability ➤ Defender: ➤ must protect against every vulnerability ➤ not only in application ➤ millions of lines of source code CC0 cloud software stack Hypervisor Operating system Application CloudStack System libraries Application libraries MaaS node … 7
- 8. CLOUD SOFTWARE STACK ➤ Applications run on top of software stack ➤ millions of lines of code ➤ Cloud stack consists of ➤ VM/container engine ➤ operating system ➤ hypervisor ➤ node management service Linux: > 20 millions line StefanPohl, CC0, https://commons.wikimedia.org/w/index.php?curid=41549243 https://www.openhub.net/p/openstack/analyses/latest/languages_summary OpenStack 8
- 9. VULNERABILITIES ➤ Coverity reports: ➤ 1 defect per 1700 lines of code ➤ Kernel self protection project: ➤ 500 security bugs fixed in Linux during the last 5 years ➤ each bug stayed about 5 years inside kernel ➤ Coverity: ➤ quality of closed source software is not better than open source software [Coverity] Open Source Report 2014 - Coverity, go.coverity.com/rs/157-LQW.../2014-Coverity-Scan-Report.pdf [KSPP] Kees Cook, The State of Kernel Self Protection Project, Linux Security Summit (LSS), 2016 9
- 10. APPLICATION-ORIENTED SECURITY µservice µservice µservice … µservice cloud-native application trusted client client host Operating system Container Engine Hypervisor 10 external API internal API µservice host … untrusted
- 11. APPLICATION PROTECTION ➤ Intel SGX protects application’s ➤ confidentiality ➤ integrity ➤ by preventing accesses to ➤ application state ➤ encrypting main memory Application System libraries Application libraries Intel SGX enclave ContainerEngine SGX protects application from accesses from outside host Operating system Container Engine Hypervisor 11
- 12. SGX PERFORMANCE CPU core core core core cache plain text Extended Page Cache (EPC) encrypted 90 MB cache line cache line page main memory encrypted page 8MB native speed slower slow! paging load encrypted 12
- 13. SAME PROBLEM: BUGS! ➤ SGX: ➤ prevent accesses via privileged / other software ➤ Smart adversary: ➤ will exploit bugs inside application code TEE application secret external API same address space 13
- 14. USE OF MICROSERVICES 14 µservice µservice µservice µservice µservice µservice µservice µservice µservice µservice TEE service secretsecret access only through internal API external API external API same address space separate address spaces
- 15. PROTECTING MICROSERVICE APIS µservice external API +type-safe programming languages + extra protection against attacks secret µservice secret internal API +no access to internal APIs + intrusion detection by monitoring internal and external APIs 15
- 16. SCONE-BASED CLOUD-NATIVE APPLICATIONS 16 µ-service closed membership µ-service cloud-native application µ-service µ-service TLS client client encrypted file encrypted file encrypted file encrypted file TLS encrypted files TLS external API internal API client client TLS
- 17. HYBRID APPLICATIONS 17 µ-service closed membership µ-service cloud-native application µ-service µ-service TLS client client encrypted file encrypted file encrypted file encrypted file TLS encrypted files TLS external API internal API client client TLS not all microservices are critical standard container secure container
- 18. CONTAINER WORKFLOW - ease of use! - CC0 18
- 19. CONTAINER WORKFLOW 19 service provider extended Dockerfile custom microservice image build secure container image
- 20. CONTAINER WORKFLOW ➤ SCONE cross compilers: ➤ C, C++ ➤ Rust ➤ GO ➤ (Fortran) ➤ Docker ➤ to build, ship and deploy images service provider extended Dockerfile custom microservice image build SCONE cross compiler image uses secure container image 20
- 21. CONTAINER WORKFLOW microservice, libraries config files build curated microservice image image curator build service provider extended Dockerfile custom microservice image 21
- 23. SCONE CURATED IMAGES (WORK IN PROGRESS) 23 nginx SCONE image hub.docker.com/explore … redis SCONE image mysql SCONE image mongo SCONE image SCONE images are shielded and tuned for SGX
- 24. CONTAINER WORKFLOW microservice, libraries config files build curated microservice image image curator 24 service provider extended Dockerfile custom microservice image container container container container containersecure container application service provider stack file deploy == customize build development operations
- 25. SERVICE PROVIDER VS CLOUD PROVIDER 25 Operating system µ-service SGX microservices deployed inside of secure containers host/VM Operating system host/VM Operating system host/VM … … MaaS/ IaaS CaaS Container Engine Container Engine Container Engine … Container Swarm untrusted cloudproviderserviceprovider untrusted µ-service SGX cloud-native applicationintegrity & confidentiality µ-service SGX … µ-service SGX availability
- 27. HOW TO DISTRIBUTE SECRETS? ➤ State of the art: ➤ put passwords in stack / compose file ➤ Problem: ➤ Docker engine is not trusted mysql-master: environment: MYSQL_ROOT_PASSWORD: rootpass MYSQL_DATABASE: messenger MYSQL_USER: messenger MYSQL_PASSWORD: messenger tty: true tty-key: mysecret image: mysql MRENCLAVE: 0x3394940494 FSPFKEY: topsecret stdin_open: true Bad practice to put secrets in compose file! 27
- 28. EXAMPLE: MYSQL mysql-master: environment: MYSQL_ROOT_PASSWORD: rootpass MYSQL_DATABASE: messenger MYSQL_USER: messenger MYSQL_PASSWORD: messenger tty: true tty-key: mysecret image: mysql MRENCLAVE: 0x3394940494 FSPFKEY: topsecret stdin_open: true mysql-master: environment: MYSQL_ROOT_PASSWORD: rootpass MYSQL_DATABASE: messenger MYSQL_USER: messenger MYSQL_PASSWORD: messenger tty-key: mysecret MRENCLAVE: 0x3394940494 FSPFKEY: topsecret mysql-master: environment: APPID: 012345 tty: true image: mysql stdin_open: true secrets no-secrets split DOCKER SCONE
- 29. SCONE: SPLIT STACK / COMPOSE FILE container containersecure container service stack file deploy == 29 split secure config stack file secrets no secrets get(sig_CPU) CAS Configuration & Attestation Service configurationTLS
- 30. PROBLEMS? ➤ Stack file ➤ secrets are in the clear ➤ Problems: ➤ service administrators might leave company ➤ access to secrets by root ➤ Approach: ➤ delegate keys to key store like vault mysql-master: environment: MYSQL_ROOT_PASSWORD: rootpass MYSQL_DATABASE: messenger MYSQL_USER: messenger MYSQL_PASSWORD: messenger tty: true tty-key: mysecret image: mysql MRENCLAVE: 0x3394940494 FSPFKEY: topsecret stdin_open: true 30
- 31. APPROACH: RETRIEVE SECRETS FROM VAULT container containersecure container service stack file deploy == 31 split secure config stack file secrets no secrets pull CAS pull Vault HashiCorp’s enclaved enclaved
- 32. EXAMPLE: INTEGRATION WITH VAULTmysql-master: environment: MYSQL_ROOT_PASSWORD: $mysql_root_pw MYSQL_DATABASE: messenger MYSQL_USER: messenger MYSQL_PASSWORD: $messenger_pw tty: true tty-key: $tty_key image: mysql MRENCLAVE: 0x3394940494 FSPFKEY: $fspfkey secrets: mysql_root_pw: vault: ascii messenger_pw: vault: ascii tty_key: vault: AES256 fspfkey: vault: AES256 mysql-master: environment: APPID: 012345 tty: true image: mysql no secrets no-secrets environment: MYSQL_ROOT_PASSWORD: xU0932hd… MYSQL_DATABASE: messenger MYSQL_USER: messenger MYSQL_PASSWORD: 9S3jDh1… tty-key: 0AF1B… MRENCLAVE: 0x3394940494 FSPFKEY: 3HDJejh… secrets split extended stack file config file DOCKER
- 34. SCONE ➤ Performance optimisations: ➤ asynchronous interface: minimise enclave exits ➤ syscalls executed by external threads ➤ TLS extensions (new) ➤ support pre-encrypted memory blocks ➤ Autotuner (new) ➤ find „optimal“ values for tuning parameters 34
- 35. Memcached Throughput 35 Latency(milliseconds) 0 0,75 1,5 2,25 3 Throughput (operations / second) 0 75000 150000 225000 300000 glibc + stunnel async sync inline encryption has less overhead than TLS proxy 1.2× •YCSB workload A (50/50) •Data fits into EPC TLS API
- 36. Memcached CPU 36 CPUUtilization(%) 0 200 400 600 800 Throughput (operations / second) 0 75000 150000 225000 300000 glibc + stunnel async sync TLS API
- 37. Redis Throughput 37 Latency(milliseconds) 0 1 2 3 4 Throughput (operations / second) 0 50000 100000 150000 200000 glibc + stunnel async sync 0.2× 0.6× TLS API
- 38. Performance Overview 38 Application Throughput w.r.t. native async (%) sync (%) Memcached 120 113 Apache 80 70 NGINX 80 36 Redis 60 20 inline encryption has less overhead inline encryption hurts performance with single thread
- 39. Performance Improvement 39 Application Throughput w.r.t. native async (%) sync (%) Memcached 120 113 Apache 80 70 NGINX 80 36 Redis >80? 20 current work: TLS offloading
- 40. SCONE SUMMARY ➤ ease of use: ➤ look and feel like Docker ➤ security: ➤ based on Intel SGX ➤ compiler extensions (bounds checker, limit accesses) ➤ performance reasonable (as long as microservice fits in EPC) ➤ combine with horizontal scaling if needed ➤ practical approach ➤ note: Intel SGX EPC will increase next year… 40
- 41. ADVERTISEMENT ➤ If you want to evaluate SCONE: ➤ now: SCONE cross compilers ➤ June: extended Docker compose ➤ I’m looking ➤ for PhD students and PostDocs ➤ for developers who want to join a SCONE startup ➤ Check out the SCONE documentation 41 ➤ christof.fetzer@gmail.com docker pull sconecuratedimages/sconedocu docker run -d -p 8080:80 sconecuratedimages/sconedocu open http://127.0.0.1:8080