If a container is compromised does that mean host also compromised?
Clash Royale CLAN TAG#URR8PPP
Recently, I have heard of a new virtualization tech called containers. Suppose the container has been compromised, does this mean the host is also compromised (since the container is a process on a host)? In terms of security, is a VM (virtual machine) more secure than containers?
virtualization container
edited Dec 17 at 12:16
forest
31.8k1598107
asked Dec 17 at 12:05
Akhil Surapuram
36126
add a comment |
Recently, I have heard of a new virtualization tech called containers. Suppose the container has been compromised, does this mean the host is also compromised (since the container is a process on a host)? In terms of security, is a VM (virtual machine) more secure than containers?
virtualization container
edited Dec 17 at 12:16
forest
31.8k1598107
asked Dec 17 at 12:05
Akhil Surapuram
36126
16
This comic was hanging on the wall at my last gig, for a reason.
– Simon Richter
Dec 17 at 14:16
7
If the vulnerability is in the application code, a container provides pretty good protection. If, however, the vulnerability is in the kernel, you basically lost and would better have used a VM.
– caw
Dec 17 at 18:00
1
Thank You @forest for edits in Question
– Akhil Surapuram
Dec 18 at 9:25
add a comment |
Recently, I have heard of a new virtualization tech called containers. Suppose the container has been compromised, does this mean the host is also compromised (since the container is a process on a host)? In terms of security, is a VM (virtual machine) more secure than containers?
virtualization container
edited Dec 17 at 12:16
forest
31.8k1598107
asked Dec 17 at 12:05
Akhil Surapuram
36126
Recently, I have heard of a new virtualization tech called containers. Suppose the container has been compromised, does this mean the host is also compromised (since the container is a process on a host)? In terms of security, is a VM (virtual machine) more secure than containers?
virtualization container
virtualization container
edited Dec 17 at 12:16
forest
31.8k1598107
asked Dec 17 at 12:05
Akhil Surapuram
36126
edited Dec 17 at 12:16
forest
31.8k1598107
asked Dec 17 at 12:05
Akhil Surapuram
36126
edited Dec 17 at 12:16
forest
31.8k1598107
edited Dec 17 at 12:16
forest
31.8k1598107
edited Dec 17 at 12:16
forest
31.8k1598107
31.8k1598107
asked Dec 17 at 12:05
Akhil Surapuram
36126
asked Dec 17 at 12:05
Akhil Surapuram
36126
asked Dec 17 at 12:05
Akhil Surapuram
36126
36126
16
This comic was hanging on the wall at my last gig, for a reason.
– Simon Richter
Dec 17 at 14:16
7
If the vulnerability is in the application code, a container provides pretty good protection. If, however, the vulnerability is in the kernel, you basically lost and would better have used a VM.
– caw
Dec 17 at 18:00
1
Thank You @forest for edits in Question
– Akhil Surapuram
Dec 18 at 9:25
add a comment |
16
This comic was hanging on the wall at my last gig, for a reason.
– Simon Richter
Dec 17 at 14:16
7
If the vulnerability is in the application code, a container provides pretty good protection. If, however, the vulnerability is in the kernel, you basically lost and would better have used a VM.
– caw
Dec 17 at 18:00
1
Thank You @forest for edits in Question
– Akhil Surapuram
Dec 18 at 9:25
16
16
This comic was hanging on the wall at my last gig, for a reason.
– Simon Richter
Dec 17 at 14:16
This comic was hanging on the wall at my last gig, for a reason.
– Simon Richter
Dec 17 at 14:16
7
7
If the vulnerability is in the application code, a container provides pretty good protection. If, however, the vulnerability is in the kernel, you basically lost and would better have used a VM.
– caw
Dec 17 at 18:00
If the vulnerability is in the application code, a container provides pretty good protection. If, however, the vulnerability is in the kernel, you basically lost and would better have used a VM.
– caw
Dec 17 at 18:00
1
1
Thank You @forest for edits in Question
– Akhil Surapuram
Dec 18 at 9:25
Thank You @forest for edits in Question
– Akhil Surapuram
Dec 18 at 9:25
add a comment |
2 Answers
2
active
oldest
votes
If the kernel is compromised in the container, the host is compromised.
Ostensibly, a compromised container should not be able to harm the host. However, container security is not great, and there are usually many vulnerabilities that allow a privileged container user to compromise the host. In this way, containers are often less secure than full virtual machines. That does not mean that virtual machines can't be hacked. They are just not quite as bad.
If the kernel is exploited in a virtual machine, the attacker still needs to find a bug in the hypervisor. If the kernel is exploited in a container, the entire system is compromised, including the host. This means that kernel security bugs, as a class, are far more severe when containers are used.
Containers are often implemented by using namespaces:
A namespace wraps a global system resource in an abstraction that makes it appear to the process within the namespace that they have their own isolated instance of a global resource. Changes to the global resource are visible to other processes that are members of the namespace, but are invisible to other processes.
Unfortunately, Linux namespaces typically expose a much greater attack surface area from the kernel. Many kernel vulnerabilities are exploitable in namespaces. While not every container solution uses Linux namespaces, they all use the same kind of technology, with the same security issues. Some containers, like Docker, are capable of making use of a syscall filtering framework called seccomp to reduce the attack surface area of the kernel. This is an improvement, but is not always enough.
From Daniel Shapira:
[...] kernel exploits can be devastating for containerized environments. This is because containers share the same kernel as the host, thus trusting the built-in protection mechanisms alone isn’t sufficient.
answered Dec 17 at 12:06
forest
31.8k1598107
add a comment |
Because containers are not as isolated as VMs, yes, in one way they are less secure. See forest's answer.
Having said that, I think it's worth noting that containers also provide some some benefits from a application security perspective. Because they typically run a single process they limit the attack surface, there's no cron monitor or ssh daemon running inside the container, for example. Container images are immutable: on restart they load from the original binaries. You can't overwrite the application. Most container technologies also allow precise control over what ports are open and to whom. You can have a container for a DB that cannot be accessed from anything other than your other containers.
All of this assumes that these features work as advertised and do not have flaws, of course. And if an attacker manages to escape from the container, none of the above applies. It adds a bit of overhead but a belt and suspenders approach is possible: containers on top of VMs.
answered Dec 17 at 21:57
JimmyJames
2,16311122
1
Well you can also divide your VM in multiple sub networks, enable local firewall to filter port and so on. To me containers are at the very least an interesting opportunity when you want to isolate stuff and those stuff aren't worth a full VM configuration. I'd consider to put entry points in a VM and the reste eventually only in containers. With a strict watching on what happens in the VM (like typical monitoring of any files update of the system)
– Walfrat
Dec 18 at 10:23
@Walfrat You can do a lot to reduce the attack surface of a VM running a full linux distro, for sure. And maybe if you are a guru, you might even get it right. For docker, at least, the default is 'nothing available'. Everything has to be explicitly brought in and enabled. If you want to setup say a cluster of webservers that talk to a dedicated back-end, you can't hide the DB from other hosts on the network using VM configurations alone. Doing this in something like kubernetes is a trivial configuration.
– JimmyJames
Dec 18 at 14:21
I guess so, I'm from the development side so I'm far from off what system guys really can do or how easy / hard it can befor people knowing the right tools (or if there is one). My comment is what I understood in the context of the current question, which is if you really want high security without eventually doing too much security (and costs), you might at least invest specially on the entry point, and so put that in a VM under strict control and only allowing the minimum interaction with the rest of the system. If I were do to it myself, I just won't, I don't have the skills for that.
– Walfrat
Dec 18 at 15:12
@Walfrat I think you are speaking to the heart of my main point here. Application people like you and me are typically don't have the skills to secure the host environment. Containers let developers specify what their application needs from the environment in a transparent way. This lets the experts secure the host in a more or less application agnostic way. I see a lot of opportunity for people who can manage and secure container environments.
– JimmyJames
Dec 18 at 15:32
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "162"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f199905%2fif-a-container-is-compromised-does-that-mean-host-also-compromised%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
If the kernel is compromised in the container, the host is compromised.
Ostensibly, a compromised container should not be able to harm the host. However, container security is not great, and there are usually many vulnerabilities that allow a privileged container user to compromise the host. In this way, containers are often less secure than full virtual machines. That does not mean that virtual machines can't be hacked. They are just not quite as bad.
If the kernel is exploited in a virtual machine, the attacker still needs to find a bug in the hypervisor. If the kernel is exploited in a container, the entire system is compromised, including the host. This means that kernel security bugs, as a class, are far more severe when containers are used.
Containers are often implemented by using namespaces:
A namespace wraps a global system resource in an abstraction that makes it appear to the process within the namespace that they have their own isolated instance of a global resource. Changes to the global resource are visible to other processes that are members of the namespace, but are invisible to other processes.
Unfortunately, Linux namespaces typically expose a much greater attack surface area from the kernel. Many kernel vulnerabilities are exploitable in namespaces. While not every container solution uses Linux namespaces, they all use the same kind of technology, with the same security issues. Some containers, like Docker, are capable of making use of a syscall filtering framework called seccomp to reduce the attack surface area of the kernel. This is an improvement, but is not always enough.
From Daniel Shapira:
[...] kernel exploits can be devastating for containerized environments. This is because containers share the same kernel as the host, thus trusting the built-in protection mechanisms alone isn’t sufficient.
answered Dec 17 at 12:06
forest
31.8k1598107
add a comment |
If the kernel is compromised in the container, the host is compromised.
Ostensibly, a compromised container should not be able to harm the host. However, container security is not great, and there are usually many vulnerabilities that allow a privileged container user to compromise the host. In this way, containers are often less secure than full virtual machines. That does not mean that virtual machines can't be hacked. They are just not quite as bad.
If the kernel is exploited in a virtual machine, the attacker still needs to find a bug in the hypervisor. If the kernel is exploited in a container, the entire system is compromised, including the host. This means that kernel security bugs, as a class, are far more severe when containers are used.
Containers are often implemented by using namespaces:
A namespace wraps a global system resource in an abstraction that makes it appear to the process within the namespace that they have their own isolated instance of a global resource. Changes to the global resource are visible to other processes that are members of the namespace, but are invisible to other processes.
Unfortunately, Linux namespaces typically expose a much greater attack surface area from the kernel. Many kernel vulnerabilities are exploitable in namespaces. While not every container solution uses Linux namespaces, they all use the same kind of technology, with the same security issues. Some containers, like Docker, are capable of making use of a syscall filtering framework called seccomp to reduce the attack surface area of the kernel. This is an improvement, but is not always enough.
From Daniel Shapira:
[...] kernel exploits can be devastating for containerized environments. This is because containers share the same kernel as the host, thus trusting the built-in protection mechanisms alone isn’t sufficient.
answered Dec 17 at 12:06
forest
31.8k1598107
add a comment |
If the kernel is compromised in the container, the host is compromised.
Ostensibly, a compromised container should not be able to harm the host. However, container security is not great, and there are usually many vulnerabilities that allow a privileged container user to compromise the host. In this way, containers are often less secure than full virtual machines. That does not mean that virtual machines can't be hacked. They are just not quite as bad.
If the kernel is exploited in a virtual machine, the attacker still needs to find a bug in the hypervisor. If the kernel is exploited in a container, the entire system is compromised, including the host. This means that kernel security bugs, as a class, are far more severe when containers are used.
Containers are often implemented by using namespaces:
A namespace wraps a global system resource in an abstraction that makes it appear to the process within the namespace that they have their own isolated instance of a global resource. Changes to the global resource are visible to other processes that are members of the namespace, but are invisible to other processes.
Unfortunately, Linux namespaces typically expose a much greater attack surface area from the kernel. Many kernel vulnerabilities are exploitable in namespaces. While not every container solution uses Linux namespaces, they all use the same kind of technology, with the same security issues. Some containers, like Docker, are capable of making use of a syscall filtering framework called seccomp to reduce the attack surface area of the kernel. This is an improvement, but is not always enough.
From Daniel Shapira:
[...] kernel exploits can be devastating for containerized environments. This is because containers share the same kernel as the host, thus trusting the built-in protection mechanisms alone isn’t sufficient.
answered Dec 17 at 12:06
forest
31.8k1598107
If the kernel is compromised in the container, the host is compromised.
Ostensibly, a compromised container should not be able to harm the host. However, container security is not great, and there are usually many vulnerabilities that allow a privileged container user to compromise the host. In this way, containers are often less secure than full virtual machines. That does not mean that virtual machines can't be hacked. They are just not quite as bad.
If the kernel is exploited in a virtual machine, the attacker still needs to find a bug in the hypervisor. If the kernel is exploited in a container, the entire system is compromised, including the host. This means that kernel security bugs, as a class, are far more severe when containers are used.
Containers are often implemented by using namespaces:
A namespace wraps a global system resource in an abstraction that makes it appear to the process within the namespace that they have their own isolated instance of a global resource. Changes to the global resource are visible to other processes that are members of the namespace, but are invisible to other processes.
Unfortunately, Linux namespaces typically expose a much greater attack surface area from the kernel. Many kernel vulnerabilities are exploitable in namespaces. While not every container solution uses Linux namespaces, they all use the same kind of technology, with the same security issues. Some containers, like Docker, are capable of making use of a syscall filtering framework called seccomp to reduce the attack surface area of the kernel. This is an improvement, but is not always enough.
From Daniel Shapira:
[...] kernel exploits can be devastating for containerized environments. This is because containers share the same kernel as the host, thus trusting the built-in protection mechanisms alone isn’t sufficient.
answered Dec 17 at 12:06
forest
31.8k1598107
edited Dec 18 at 1:56
answered Dec 17 at 12:06
forest
31.8k1598107
answered Dec 17 at 12:06
forest
31.8k1598107
answered Dec 17 at 12:06
forest
31.8k1598107
31.8k1598107
add a comment |
add a comment |
Because containers are not as isolated as VMs, yes, in one way they are less secure. See forest's answer.
Having said that, I think it's worth noting that containers also provide some some benefits from a application security perspective. Because they typically run a single process they limit the attack surface, there's no cron monitor or ssh daemon running inside the container, for example. Container images are immutable: on restart they load from the original binaries. You can't overwrite the application. Most container technologies also allow precise control over what ports are open and to whom. You can have a container for a DB that cannot be accessed from anything other than your other containers.
All of this assumes that these features work as advertised and do not have flaws, of course. And if an attacker manages to escape from the container, none of the above applies. It adds a bit of overhead but a belt and suspenders approach is possible: containers on top of VMs.
answered Dec 17 at 21:57
JimmyJames
2,16311122
1
Well you can also divide your VM in multiple sub networks, enable local firewall to filter port and so on. To me containers are at the very least an interesting opportunity when you want to isolate stuff and those stuff aren't worth a full VM configuration. I'd consider to put entry points in a VM and the reste eventually only in containers. With a strict watching on what happens in the VM (like typical monitoring of any files update of the system)
– Walfrat
Dec 18 at 10:23
@Walfrat You can do a lot to reduce the attack surface of a VM running a full linux distro, for sure. And maybe if you are a guru, you might even get it right. For docker, at least, the default is 'nothing available'. Everything has to be explicitly brought in and enabled. If you want to setup say a cluster of webservers that talk to a dedicated back-end, you can't hide the DB from other hosts on the network using VM configurations alone. Doing this in something like kubernetes is a trivial configuration.
– JimmyJames
Dec 18 at 14:21
I guess so, I'm from the development side so I'm far from off what system guys really can do or how easy / hard it can befor people knowing the right tools (or if there is one). My comment is what I understood in the context of the current question, which is if you really want high security without eventually doing too much security (and costs), you might at least invest specially on the entry point, and so put that in a VM under strict control and only allowing the minimum interaction with the rest of the system. If I were do to it myself, I just won't, I don't have the skills for that.
– Walfrat
Dec 18 at 15:12
@Walfrat I think you are speaking to the heart of my main point here. Application people like you and me are typically don't have the skills to secure the host environment. Containers let developers specify what their application needs from the environment in a transparent way. This lets the experts secure the host in a more or less application agnostic way. I see a lot of opportunity for people who can manage and secure container environments.
– JimmyJames
Dec 18 at 15:32
add a comment |
Because containers are not as isolated as VMs, yes, in one way they are less secure. See forest's answer.
Having said that, I think it's worth noting that containers also provide some some benefits from a application security perspective. Because they typically run a single process they limit the attack surface, there's no cron monitor or ssh daemon running inside the container, for example. Container images are immutable: on restart they load from the original binaries. You can't overwrite the application. Most container technologies also allow precise control over what ports are open and to whom. You can have a container for a DB that cannot be accessed from anything other than your other containers.
All of this assumes that these features work as advertised and do not have flaws, of course. And if an attacker manages to escape from the container, none of the above applies. It adds a bit of overhead but a belt and suspenders approach is possible: containers on top of VMs.
answered Dec 17 at 21:57
JimmyJames
2,16311122
1
Well you can also divide your VM in multiple sub networks, enable local firewall to filter port and so on. To me containers are at the very least an interesting opportunity when you want to isolate stuff and those stuff aren't worth a full VM configuration. I'd consider to put entry points in a VM and the reste eventually only in containers. With a strict watching on what happens in the VM (like typical monitoring of any files update of the system)
– Walfrat
Dec 18 at 10:23
@Walfrat You can do a lot to reduce the attack surface of a VM running a full linux distro, for sure. And maybe if you are a guru, you might even get it right. For docker, at least, the default is 'nothing available'. Everything has to be explicitly brought in and enabled. If you want to setup say a cluster of webservers that talk to a dedicated back-end, you can't hide the DB from other hosts on the network using VM configurations alone. Doing this in something like kubernetes is a trivial configuration.
– JimmyJames
Dec 18 at 14:21
I guess so, I'm from the development side so I'm far from off what system guys really can do or how easy / hard it can befor people knowing the right tools (or if there is one). My comment is what I understood in the context of the current question, which is if you really want high security without eventually doing too much security (and costs), you might at least invest specially on the entry point, and so put that in a VM under strict control and only allowing the minimum interaction with the rest of the system. If I were do to it myself, I just won't, I don't have the skills for that.
– Walfrat
Dec 18 at 15:12
@Walfrat I think you are speaking to the heart of my main point here. Application people like you and me are typically don't have the skills to secure the host environment. Containers let developers specify what their application needs from the environment in a transparent way. This lets the experts secure the host in a more or less application agnostic way. I see a lot of opportunity for people who can manage and secure container environments.
– JimmyJames
Dec 18 at 15:32
add a comment |
Because containers are not as isolated as VMs, yes, in one way they are less secure. See forest's answer.
Having said that, I think it's worth noting that containers also provide some some benefits from a application security perspective. Because they typically run a single process they limit the attack surface, there's no cron monitor or ssh daemon running inside the container, for example. Container images are immutable: on restart they load from the original binaries. You can't overwrite the application. Most container technologies also allow precise control over what ports are open and to whom. You can have a container for a DB that cannot be accessed from anything other than your other containers.
All of this assumes that these features work as advertised and do not have flaws, of course. And if an attacker manages to escape from the container, none of the above applies. It adds a bit of overhead but a belt and suspenders approach is possible: containers on top of VMs.
answered Dec 17 at 21:57
JimmyJames
2,16311122
Because containers are not as isolated as VMs, yes, in one way they are less secure. See forest's answer.
Having said that, I think it's worth noting that containers also provide some some benefits from a application security perspective. Because they typically run a single process they limit the attack surface, there's no cron monitor or ssh daemon running inside the container, for example. Container images are immutable: on restart they load from the original binaries. You can't overwrite the application. Most container technologies also allow precise control over what ports are open and to whom. You can have a container for a DB that cannot be accessed from anything other than your other containers.
All of this assumes that these features work as advertised and do not have flaws, of course. And if an attacker manages to escape from the container, none of the above applies. It adds a bit of overhead but a belt and suspenders approach is possible: containers on top of VMs.
answered Dec 17 at 21:57
JimmyJames
2,16311122
answered Dec 17 at 21:57
JimmyJames
2,16311122
answered Dec 17 at 21:57
JimmyJames
2,16311122
answered Dec 17 at 21:57
JimmyJames
2,16311122
2,16311122
1
Well you can also divide your VM in multiple sub networks, enable local firewall to filter port and so on. To me containers are at the very least an interesting opportunity when you want to isolate stuff and those stuff aren't worth a full VM configuration. I'd consider to put entry points in a VM and the reste eventually only in containers. With a strict watching on what happens in the VM (like typical monitoring of any files update of the system)
– Walfrat
Dec 18 at 10:23
@Walfrat You can do a lot to reduce the attack surface of a VM running a full linux distro, for sure. And maybe if you are a guru, you might even get it right. For docker, at least, the default is 'nothing available'. Everything has to be explicitly brought in and enabled. If you want to setup say a cluster of webservers that talk to a dedicated back-end, you can't hide the DB from other hosts on the network using VM configurations alone. Doing this in something like kubernetes is a trivial configuration.
– JimmyJames
Dec 18 at 14:21
I guess so, I'm from the development side so I'm far from off what system guys really can do or how easy / hard it can befor people knowing the right tools (or if there is one). My comment is what I understood in the context of the current question, which is if you really want high security without eventually doing too much security (and costs), you might at least invest specially on the entry point, and so put that in a VM under strict control and only allowing the minimum interaction with the rest of the system. If I were do to it myself, I just won't, I don't have the skills for that.
– Walfrat
Dec 18 at 15:12
@Walfrat I think you are speaking to the heart of my main point here. Application people like you and me are typically don't have the skills to secure the host environment. Containers let developers specify what their application needs from the environment in a transparent way. This lets the experts secure the host in a more or less application agnostic way. I see a lot of opportunity for people who can manage and secure container environments.
– JimmyJames
Dec 18 at 15:32
add a comment |
1
Well you can also divide your VM in multiple sub networks, enable local firewall to filter port and so on. To me containers are at the very least an interesting opportunity when you want to isolate stuff and those stuff aren't worth a full VM configuration. I'd consider to put entry points in a VM and the reste eventually only in containers. With a strict watching on what happens in the VM (like typical monitoring of any files update of the system)
– Walfrat
Dec 18 at 10:23
@Walfrat You can do a lot to reduce the attack surface of a VM running a full linux distro, for sure. And maybe if you are a guru, you might even get it right. For docker, at least, the default is 'nothing available'. Everything has to be explicitly brought in and enabled. If you want to setup say a cluster of webservers that talk to a dedicated back-end, you can't hide the DB from other hosts on the network using VM configurations alone. Doing this in something like kubernetes is a trivial configuration.
– JimmyJames
Dec 18 at 14:21
I guess so, I'm from the development side so I'm far from off what system guys really can do or how easy / hard it can befor people knowing the right tools (or if there is one). My comment is what I understood in the context of the current question, which is if you really want high security without eventually doing too much security (and costs), you might at least invest specially on the entry point, and so put that in a VM under strict control and only allowing the minimum interaction with the rest of the system. If I were do to it myself, I just won't, I don't have the skills for that.
– Walfrat
Dec 18 at 15:12
@Walfrat I think you are speaking to the heart of my main point here. Application people like you and me are typically don't have the skills to secure the host environment. Containers let developers specify what their application needs from the environment in a transparent way. This lets the experts secure the host in a more or less application agnostic way. I see a lot of opportunity for people who can manage and secure container environments.
– JimmyJames
Dec 18 at 15:32
1
1
Well you can also divide your VM in multiple sub networks, enable local firewall to filter port and so on. To me containers are at the very least an interesting opportunity when you want to isolate stuff and those stuff aren't worth a full VM configuration. I'd consider to put entry points in a VM and the reste eventually only in containers. With a strict watching on what happens in the VM (like typical monitoring of any files update of the system)
– Walfrat
Dec 18 at 10:23
Well you can also divide your VM in multiple sub networks, enable local firewall to filter port and so on. To me containers are at the very least an interesting opportunity when you want to isolate stuff and those stuff aren't worth a full VM configuration. I'd consider to put entry points in a VM and the reste eventually only in containers. With a strict watching on what happens in the VM (like typical monitoring of any files update of the system)
– Walfrat
Dec 18 at 10:23
@Walfrat You can do a lot to reduce the attack surface of a VM running a full linux distro, for sure. And maybe if you are a guru, you might even get it right. For docker, at least, the default is 'nothing available'. Everything has to be explicitly brought in and enabled. If you want to setup say a cluster of webservers that talk to a dedicated back-end, you can't hide the DB from other hosts on the network using VM configurations alone. Doing this in something like kubernetes is a trivial configuration.
– JimmyJames
Dec 18 at 14:21
@Walfrat You can do a lot to reduce the attack surface of a VM running a full linux distro, for sure. And maybe if you are a guru, you might even get it right. For docker, at least, the default is 'nothing available'. Everything has to be explicitly brought in and enabled. If you want to setup say a cluster of webservers that talk to a dedicated back-end, you can't hide the DB from other hosts on the network using VM configurations alone. Doing this in something like kubernetes is a trivial configuration.
– JimmyJames
Dec 18 at 14:21
I guess so, I'm from the development side so I'm far from off what system guys really can do or how easy / hard it can befor people knowing the right tools (or if there is one). My comment is what I understood in the context of the current question, which is if you really want high security without eventually doing too much security (and costs), you might at least invest specially on the entry point, and so put that in a VM under strict control and only allowing the minimum interaction with the rest of the system. If I were do to it myself, I just won't, I don't have the skills for that.
– Walfrat
Dec 18 at 15:12
I guess so, I'm from the development side so I'm far from off what system guys really can do or how easy / hard it can befor people knowing the right tools (or if there is one). My comment is what I understood in the context of the current question, which is if you really want high security without eventually doing too much security (and costs), you might at least invest specially on the entry point, and so put that in a VM under strict control and only allowing the minimum interaction with the rest of the system. If I were do to it myself, I just won't, I don't have the skills for that.
– Walfrat
Dec 18 at 15:12
@Walfrat I think you are speaking to the heart of my main point here. Application people like you and me are typically don't have the skills to secure the host environment. Containers let developers specify what their application needs from the environment in a transparent way. This lets the experts secure the host in a more or less application agnostic way. I see a lot of opportunity for people who can manage and secure container environments.
– JimmyJames
Dec 18 at 15:32
@Walfrat I think you are speaking to the heart of my main point here. Application people like you and me are typically don't have the skills to secure the host environment. Containers let developers specify what their application needs from the environment in a transparent way. This lets the experts secure the host in a more or less application agnostic way. I see a lot of opportunity for people who can manage and secure container environments.
– JimmyJames
Dec 18 at 15:32
add a comment |
Thanks for contributing an answer to Information Security Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f199905%2fif-a-container-is-compromised-does-that-mean-host-also-compromised%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
16
This comic was hanging on the wall at my last gig, for a reason.
– Simon Richter
Dec 17 at 14:16
7
If the vulnerability is in the application code, a container provides pretty good protection. If, however, the vulnerability is in the kernel, you basically lost and would better have used a VM.
– caw
Dec 17 at 18:00
1
Thank You @forest for edits in Question
– Akhil Surapuram
Dec 18 at 9:25