3 ms·

Friendly reminder that containers aren't a security control and your threat modeling should already assume the host VM running any untrusted containers is compr

Friendly reminder that containers aren't a security control and your threat modeling should already assume the host VM running any untrusted containers is compromised

mrweasel 3y ago
Multi-tenancy, in any shape or form is sadly a potential security problem. I don't care if it's VM, containers, VLANs or databases, if you absolutely need to know that no one else is going to have access to your data, you need separate physical hardware. In many circumstances you can make some tradeoffs, like running multiple customers or projects on the same vmware installation, because the risk is low or the other tenants are well known. I don't think Kubernetes is quite there yet where I'd trust multiple tenants on the same cluster.
- flaminHotSpeedo 3y ago
  Technically yes, but practically no. If you have the expertise to do it well, or cash to pay for someone else to do it well for you, you can definitely get trustworthy security boundaries without physical separation. As an example, a VM from a reputable cloud provider is secure enough for most purposes, likewise I'd trust managed containers from a reputable cloud provider (except Azure, they have a dodgy track record when it comes to container security)
- nyrikki 3y ago
  As an example of the difference directly related to k8s "Security settings that you specify for a Container apply only to the individual Container, and they override settings made at the Pod level when there is overlap." https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ https://kubernetes.io/docs/tasks/configure-pod-container/sec... While there are other Byzantine faults like this CSV, that should give you a hint. The problem is that containers depend on good actors dropping privlages on a shared kernel. Where VM's have a natural abstraction and their own kernel, containers require proper configuration of seccomp, apparmor, selinux, dropping privileges, etc... to reduce the attack surface. An easy demonstration of this is to launch a privlaged container and run insmod with some random kernel module on the host OS. In namespaces, you start with no isolation, and you add whatever you want or more realistically remember to add. They are not jails where you start with a reasonable secure baseline. In fact the k8s 'baseline' pod security standard still has MKNOD caps which can result in issues like CVE-2021-25741. While /proc now has filtering /sys doesn't and you can find the major minor numbers of the hosts root filesystem and read it from a container. It is not that containers can't be made reasonably secure, but that they aren't inherently secure. They are default allow all because they are inherently just namespaces implemented basically through value remapping.
2OEH8eoCRo0 3y ago
Why is it all or nothing? It's absolutely a security control.
- flaminHotSpeedo 3y ago
  If you know what you're doing sure, you could justify it as one layer of security controls as part of a defense-in-depth, but it's totally unacceptable to rely on containers for "real" security, e.g. isolation between tenants.

Friendly reminder that containers aren't a security control and your threat modeling should already assume the host VM running any untrusted containers is compromised

mrweasel 3y ago

Multi-tenancy, in any shape or form is sadly a potential security problem. I don't care if it's VM, containers, VLANs or databases, if you absolutely need to know that no one else is going to have access to your data, you need separate physical hardware. In many circumstances you can make some tradeoffs, like running multiple customers or projects on the same vmware installation, because the risk is low or the other tenants are well known. I don't think Kubernetes is quite there yet where I'd trust multiple tenants on the same cluster.

flaminHotSpeedo 3y ago
Technically yes, but practically no. If you have the expertise to do it well, or cash to pay for someone else to do it well for you, you can definitely get trustworthy security boundaries without physical separation. As an example, a VM from a reputable cloud provider is secure enough for most purposes, likewise I'd trust managed containers from a reputable cloud provider (except Azure, they have a dodgy track record when it comes to container security)
nyrikki 3y ago
As an example of the difference directly related to k8s "Security settings that you specify for a Container apply only to the individual Container, and they override settings made at the Pod level when there is overlap." https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ https://kubernetes.io/docs/tasks/configure-pod-container/sec... While there are other Byzantine faults like this CSV, that should give you a hint. The problem is that containers depend on good actors dropping privlages on a shared kernel. Where VM's have a natural abstraction and their own kernel, containers require proper configuration of seccomp, apparmor, selinux, dropping privileges, etc... to reduce the attack surface. An easy demonstration of this is to launch a privlaged container and run insmod with some random kernel module on the host OS. In namespaces, you start with no isolation, and you add whatever you want or more realistically remember to add. They are not jails where you start with a reasonable secure baseline. In fact the k8s 'baseline' pod security standard still has MKNOD caps which can result in issues like CVE-2021-25741. While /proc now has filtering /sys doesn't and you can find the major minor numbers of the hosts root filesystem and read it from a container. It is not that containers can't be made reasonably secure, but that they aren't inherently secure. They are default allow all because they are inherently just namespaces implemented basically through value remapping.

2OEH8eoCRo0 3y ago

Why is it all or nothing? It's absolutely a security control.

flaminHotSpeedo 3y ago
If you know what you're doing sure, you could justify it as one layer of security controls as part of a defense-in-depth, but it's totally unacceptable to rely on containers for "real" security, e.g. isolation between tenants.