Containers and Cloud Security
Containers and Cloud Sercurity
Introduction
- Purpose: Look at how cloud security is measured and its impacts on various members of the ecosystem
- Vertical Attack Profile (VAP): all code that is traversed in order to provide a response to a request
- Database code
- OS kernel
- Network stack
- Middleware
- The more modules you have in your VAP, the greater the risk of vulnerability
- In Infrastructure-as-a-Service, there are two actors
- Tenant
- Cloud Service Provider: CSP
- Tenants have some of the VAP, whereas "lower levels" are owned by the CSP
- While tenants care mainly about their VAP, cloud service providers worry about the horizontal attack profile
- Horizontal Attack Profile: possibility that an attack can jump containment boundaries between tenants
- From the CSP's point of view, such "horizontal" attacks are potentially business-ending disasters whereas "vertical" attacks targeting a single tenants are a manageable risk
- The size of the profile is correlated with the risk of exploit
- From the tenant perspective, there are two ways to improve security:
- Invest in better monitoring of their Vertical Attack Profile
- Push more of the Vertical Attack Profile "down" into the cloud service provider
Examples:
- Physical infrastructure:
- Each tenant is on a separate physical host
- Cloud Service Provider is only responsible for providing hardware
- This is great for the cloud service provider - each tenant is on a separate physical host, so barring hardware attacks, there is no possibility for a horizontal attack
- Shared login model:
- Tenant only gets a login on a host
- CSP owns rest of stack: middleware, kernel, libraries, and hardware
- Think PHP CPanel web host
- The total attack profile is the same, but the tenant is only responsible for securing their application code - CSP is responsible for everything else
- The CSP, on the other hand, now has to deal with the fact that a single flaw anywhere in the stack (kernel, libraries, middleware, etc) can lead to a single tenant gaining control of the entire host, potentially compromising all tenants on that host
- Low VAP from the tenant's perspective, but huge HAP from the cloud service provider's perspective
- Hypervisor-based Emulation:
- From the tenant's perspective, the VAP is mostly the same as if they were on their own hardware
- However, from the CSP's perspective, the HAP is slightly worse, because flaws in the hypervisor code can lead to cross-vm exploits
- This can be mitigated however, by making the hypervisor interface extremely small, reducing the bug density and attack surface
- Simply transferring elements from the tenant VAP to the CSP's VAP doesn't necessarily improve security, if the CSP isn't motivated to fix the problems
- CSPs are motivated to fix problems in the VAP if those problems can lead to a horizontal exploit
- Container-based virtual infrastructure
- Total VAP is identical to physical infrastructure
- Tenant component, however, is much smaller, since the OS kernel accounts for ~50% of all vulnerabilities
- Pushing this responsibility off onto the CSP is a significant reduction in workload for the tenant
- Moreover, when the CSP remediates a vulnerability, all tenants immediately benefit
- However, from the CSP's perspective, their HAP is now the entire OS kernel, isntead of a relatively slim virtualization hypervisor
- From the tenant's perspective, this is also a good thing, because it means that the CSP is now motivated to keep up with security patches on the OS kernel, since any holes allowing cross-container attacks represent a real business risk
- CSPs, for their part, try to shift the work back onto the tenants by advocating nested virtualization solutions like running containers in VMs
- Unless your CSP is running bare-metal containers, they've palmed the the VAP segments that you attempted to make their responsibility back onto you
Other avenues for controlling attack profiles
- Above analysis assumes relatively constant defect densities, resulting in a linear relationship between amount of code and amount of defects
- However, not all codebases are created equal
- By choosing the codebases that you rely on carefully, it's possible to reduce vulnerability while keeping the same amount of code
- Density reduction
- Find and fix defects (or rely on someone else to find and fix defects)
- Know how actively defects are being searched for and how quickly they are being remediated
- Example: Linux kernel - popular codebase relied upon by many stakeholders - defects are found and fixed relatively quickly
- Rewrite components in languages that make certain kinds of bugs more difficult to write
- Suffers from "defect decay effect" -- most bugs in a component occur when the component is brand new
- A new component written in a defect-preventing language may still have more defects than an old battle-hardened component
- Find and fix defects (or rely on someone else to find and fix defects)
- Code reduction (minimization techniques)
- Reduce the amount of code that's exposed
- Tricky to do in many cases
- Need to make sure that the code being eliminated isn't being used
- Need to make sure that it isn't being relied upon by something that is being used
- Guarding and sandboxing
- Block off certain code paths without actually removing the code
- Example: using `seccomp` to block off certain syscalls that you know aren't being used
- Completely blocking off syscalls can be tricky, however. What if the application legitimately needs that access?
- Guarding/emulation - emulate system calls without actually calling the kernel
- Reduces HAP, since each of the guards/sandboxes is in a separate address space
- May or may not reduce VAP, depending on number of bugs in syscall emulation vs. bugs in original syscall
- Watch out for guards running in the same address space as your application - this is often used by CSPs as a way to pass that portion of the VAP back to the tenant
Conclusions
- Security is hard
- The total VAP (tenant + CSP) of a containerized system is actually better than the total VAP of hypervisor emulation
- The increased HAP that containerization brings should rightly be the CSP's responsibility to mitigate
- However, CSPs are liable to shirk this responsibility by making it seem like bare-metal containers are less secure than nested virtualized containers
- Before you, as a tenant, worry about the CSP's HAP, make sure that existing SLA and contractual remedies aren't sufficient to cover losses
- Keep responsibility for HAP with the CSP, since they're better equipped to deal with the problems of maintaing container infrastructure (even though they don't want to)
