Why is systemd-nspawn not appropriate for production deployments?
Clash Royale CLAN TAG#URR8PPP
While reading about systemd-nspawn, it is mentioned that it should not be used in a production environment. The reason seems to be the lack of management and deployment infrastructure. Is practicality the only reason, or are there underlying security/functionality reasons too?
linux systemd container containers
asked Jan 20 '15 at 21:39
Chris MendezChris Mendez
1889
add a comment |
While reading about systemd-nspawn, it is mentioned that it should not be used in a production environment. The reason seems to be the lack of management and deployment infrastructure. Is practicality the only reason, or are there underlying security/functionality reasons too?
linux systemd container containers
asked Jan 20 '15 at 21:39
Chris MendezChris Mendez
1889
As I remember from Q&A session on Reddit link, the reasons are that it's under active development and there are some TODOs.
– kirill-a
Jan 21 '15 at 8:07
add a comment |
While reading about systemd-nspawn, it is mentioned that it should not be used in a production environment. The reason seems to be the lack of management and deployment infrastructure. Is practicality the only reason, or are there underlying security/functionality reasons too?
linux systemd container containers
asked Jan 20 '15 at 21:39
Chris MendezChris Mendez
1889
While reading about systemd-nspawn, it is mentioned that it should not be used in a production environment. The reason seems to be the lack of management and deployment infrastructure. Is practicality the only reason, or are there underlying security/functionality reasons too?
linux systemd container containers
linux systemd container containers
asked Jan 20 '15 at 21:39
Chris MendezChris Mendez
1889
asked Jan 20 '15 at 21:39
Chris MendezChris Mendez
1889
asked Jan 20 '15 at 21:39
Chris MendezChris Mendez
1889
asked Jan 20 '15 at 21:39
Chris MendezChris Mendez
1889
asked Jan 20 '15 at 21:39
Chris MendezChris Mendez
1889
1889
As I remember from Q&A session on Reddit link, the reasons are that it's under active development and there are some TODOs.
– kirill-a
Jan 21 '15 at 8:07
add a comment |
As I remember from Q&A session on Reddit link, the reasons are that it's under active development and there are some TODOs.
– kirill-a
Jan 21 '15 at 8:07
As I remember from Q&A session on Reddit link, the reasons are that it's under active development and there are some TODOs.
– kirill-a
Jan 21 '15 at 8:07
As I remember from Q&A session on Reddit link, the reasons are that it's under active development and there are some TODOs.
– kirill-a
Jan 21 '15 at 8:07
add a comment |
2 Answers
2
active
oldest
votes
Your source describes a presentation by the systemd developer Lennart Poettering. Lennart is an employee of Red Hat. Both Red Hat Enterprise Linux, and the Fedora Linux community distribution, use SELinux.
The integration between systemd-nspawn and SELinux appears to be broken, e.g. see rhbz1416540. Also, if you try to access the network from a container started in a private network namespace on Fedora Linux, (the default when using systemd-nspawn@.service), it will be blocked by firewalld.
My conclusion was that systemd-nspawn is not supported for running containers as servers. It probably happens to run on non-Red Hat systems, but you won't have the benefit of any LSM-based protections. Unless you can work something out yourself.
Note that other well-known container managers include LSM-based protections. Particularly Docker, but LXC also includes some policy for AppArmor.
Being production-ready would imply people are auditing, documenting, or even marketing how to use systemd-nspawn securely. I think the systemd developers are being honest in admitting they aren't really doing this, at least at the moment.
answered Apr 23 '17 at 14:03
sourcejedisourcejedi
23.9k439106
add a comment |
That was mentioned in a presentation by Lennart Poettering in 2013, but in 2015 he was quoted saying the following:
systemd also contains the systemd-nspawn container manager. It's a relatively minimal, yet powerful implementation of a container manager. Initially we wrote it for testing purposes, but nowadays we consider it ready for many production uses. In fact CoreOS' rkt container tool makes use of it as the lower level container backend.
Reference: Where systemd and Containers Meet: Q&A with Lennart Poettering
answered Aug 7 '17 at 22:18
isapirisapir
21827
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
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
,
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%2funix.stackexchange.com%2fquestions%2f180161%2fwhy-is-systemd-nspawn-not-appropriate-for-production-deployments%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
Your source describes a presentation by the systemd developer Lennart Poettering. Lennart is an employee of Red Hat. Both Red Hat Enterprise Linux, and the Fedora Linux community distribution, use SELinux.
The integration between systemd-nspawn and SELinux appears to be broken, e.g. see rhbz1416540. Also, if you try to access the network from a container started in a private network namespace on Fedora Linux, (the default when using systemd-nspawn@.service), it will be blocked by firewalld.
My conclusion was that systemd-nspawn is not supported for running containers as servers. It probably happens to run on non-Red Hat systems, but you won't have the benefit of any LSM-based protections. Unless you can work something out yourself.
Note that other well-known container managers include LSM-based protections. Particularly Docker, but LXC also includes some policy for AppArmor.
Being production-ready would imply people are auditing, documenting, or even marketing how to use systemd-nspawn securely. I think the systemd developers are being honest in admitting they aren't really doing this, at least at the moment.
answered Apr 23 '17 at 14:03
sourcejedisourcejedi
23.9k439106
add a comment |
Your source describes a presentation by the systemd developer Lennart Poettering. Lennart is an employee of Red Hat. Both Red Hat Enterprise Linux, and the Fedora Linux community distribution, use SELinux.
The integration between systemd-nspawn and SELinux appears to be broken, e.g. see rhbz1416540. Also, if you try to access the network from a container started in a private network namespace on Fedora Linux, (the default when using systemd-nspawn@.service), it will be blocked by firewalld.
My conclusion was that systemd-nspawn is not supported for running containers as servers. It probably happens to run on non-Red Hat systems, but you won't have the benefit of any LSM-based protections. Unless you can work something out yourself.
Note that other well-known container managers include LSM-based protections. Particularly Docker, but LXC also includes some policy for AppArmor.
Being production-ready would imply people are auditing, documenting, or even marketing how to use systemd-nspawn securely. I think the systemd developers are being honest in admitting they aren't really doing this, at least at the moment.
answered Apr 23 '17 at 14:03
sourcejedisourcejedi
23.9k439106
add a comment |
Your source describes a presentation by the systemd developer Lennart Poettering. Lennart is an employee of Red Hat. Both Red Hat Enterprise Linux, and the Fedora Linux community distribution, use SELinux.
The integration between systemd-nspawn and SELinux appears to be broken, e.g. see rhbz1416540. Also, if you try to access the network from a container started in a private network namespace on Fedora Linux, (the default when using systemd-nspawn@.service), it will be blocked by firewalld.
My conclusion was that systemd-nspawn is not supported for running containers as servers. It probably happens to run on non-Red Hat systems, but you won't have the benefit of any LSM-based protections. Unless you can work something out yourself.
Note that other well-known container managers include LSM-based protections. Particularly Docker, but LXC also includes some policy for AppArmor.
Being production-ready would imply people are auditing, documenting, or even marketing how to use systemd-nspawn securely. I think the systemd developers are being honest in admitting they aren't really doing this, at least at the moment.
answered Apr 23 '17 at 14:03
sourcejedisourcejedi
23.9k439106
Your source describes a presentation by the systemd developer Lennart Poettering. Lennart is an employee of Red Hat. Both Red Hat Enterprise Linux, and the Fedora Linux community distribution, use SELinux.
The integration between systemd-nspawn and SELinux appears to be broken, e.g. see rhbz1416540. Also, if you try to access the network from a container started in a private network namespace on Fedora Linux, (the default when using systemd-nspawn@.service), it will be blocked by firewalld.
My conclusion was that systemd-nspawn is not supported for running containers as servers. It probably happens to run on non-Red Hat systems, but you won't have the benefit of any LSM-based protections. Unless you can work something out yourself.
Note that other well-known container managers include LSM-based protections. Particularly Docker, but LXC also includes some policy for AppArmor.
Being production-ready would imply people are auditing, documenting, or even marketing how to use systemd-nspawn securely. I think the systemd developers are being honest in admitting they aren't really doing this, at least at the moment.
answered Apr 23 '17 at 14:03
sourcejedisourcejedi
23.9k439106
answered Apr 23 '17 at 14:03
sourcejedisourcejedi
23.9k439106
answered Apr 23 '17 at 14:03
sourcejedisourcejedi
23.9k439106
answered Apr 23 '17 at 14:03
sourcejedisourcejedi
23.9k439106
23.9k439106
add a comment |
add a comment |
That was mentioned in a presentation by Lennart Poettering in 2013, but in 2015 he was quoted saying the following:
systemd also contains the systemd-nspawn container manager. It's a relatively minimal, yet powerful implementation of a container manager. Initially we wrote it for testing purposes, but nowadays we consider it ready for many production uses. In fact CoreOS' rkt container tool makes use of it as the lower level container backend.
Reference: Where systemd and Containers Meet: Q&A with Lennart Poettering
answered Aug 7 '17 at 22:18
isapirisapir
21827
add a comment |
That was mentioned in a presentation by Lennart Poettering in 2013, but in 2015 he was quoted saying the following:
systemd also contains the systemd-nspawn container manager. It's a relatively minimal, yet powerful implementation of a container manager. Initially we wrote it for testing purposes, but nowadays we consider it ready for many production uses. In fact CoreOS' rkt container tool makes use of it as the lower level container backend.
Reference: Where systemd and Containers Meet: Q&A with Lennart Poettering
answered Aug 7 '17 at 22:18
isapirisapir
21827
add a comment |
That was mentioned in a presentation by Lennart Poettering in 2013, but in 2015 he was quoted saying the following:
systemd also contains the systemd-nspawn container manager. It's a relatively minimal, yet powerful implementation of a container manager. Initially we wrote it for testing purposes, but nowadays we consider it ready for many production uses. In fact CoreOS' rkt container tool makes use of it as the lower level container backend.
Reference: Where systemd and Containers Meet: Q&A with Lennart Poettering
answered Aug 7 '17 at 22:18
isapirisapir
21827
That was mentioned in a presentation by Lennart Poettering in 2013, but in 2015 he was quoted saying the following:
systemd also contains the systemd-nspawn container manager. It's a relatively minimal, yet powerful implementation of a container manager. Initially we wrote it for testing purposes, but nowadays we consider it ready for many production uses. In fact CoreOS' rkt container tool makes use of it as the lower level container backend.
Reference: Where systemd and Containers Meet: Q&A with Lennart Poettering
answered Aug 7 '17 at 22:18
isapirisapir
21827
answered Aug 7 '17 at 22:18
isapirisapir
21827
answered Aug 7 '17 at 22:18
isapirisapir
21827
answered Aug 7 '17 at 22:18
isapirisapir
21827
21827
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux 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.
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%2funix.stackexchange.com%2fquestions%2f180161%2fwhy-is-systemd-nspawn-not-appropriate-for-production-deployments%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
As I remember from Q&A session on Reddit link, the reasons are that it's under active development and there are some TODOs.
– kirill-a
Jan 21 '15 at 8:07