[Users] Best practice for securing oVirt's NFS mounts
Hi, All the documentation I've seen states that the oVirt NFS storage should use the "all_squash,anonuid=36,anongid=36" options. Obviously this isn't secure, so I'm curious how others have locked down their NFS storage? Is the best option to just limit access to these NFS exports to the IP addresses of the hypervisor nodes (and maybe the engine)? Is there a better way to go about this? -- Cheers, Prakash
Hi, just a quick reminder: unless you got strong network authentication and absolute control over the LAN it's a bad advice to trust some random IP address. In today's networking world I would advice to not trust any LAN resource without strong authentication mechanisms. Am 11.03.2014 18:23, schrieb Prakash Surya:
Is the best option to just limit access to these NFS exports to the IP addresses of the hypervisor nodes (and maybe the engine)?
-- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
Right, and agreed. We've migrated to using kerberos authentication and NFS4 for most of our NFS mounts, but since oVirt requires the all_squash and *ID of 36, that won't work. Honestly, our LAN is fairly well protected and our users are more or less "trusted", so I don't think it's _that_ big of a deal; but restricting access as much as possible is better than nothing. Do you have any suggestions? I'll admit, NFS security definitely isn't one of my strong suits. Restricting the to specific IPs, was just the best and easiest thing I thought of, keeping the insecure export options in mind. -- Cheers, Prakash On Wed, Mar 12, 2014 at 08:16:34AM +0000, Sven Kieske wrote:
Hi,
just a quick reminder:
unless you got strong network authentication and absolute control over the LAN it's a bad advice to trust some random IP address.
In today's networking world I would advice to not trust any LAN resource without strong authentication mechanisms.
Am 11.03.2014 18:23, schrieb Prakash Surya:
Is the best option to just limit access to these NFS exports to the IP addresses of the hypervisor nodes (and maybe the engine)?
-- Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Tue, 11 Mar 2014 10:23:19 -0700 Prakash Surya <surya1@llnl.gov> wrote:
Hi,
All the documentation I've seen states that the oVirt NFS storage should use the "all_squash,anonuid=36,anongid=36" options. Obviously this isn't secure, so I'm curious how others have locked down their NFS storage? Is the best option to just limit access to these NFS exports to the IP addresses of the hypervisor nodes (and maybe the engine)? Is there a better way to go about this?
Run vlans and have some active monitoring for physical ports up|down states etc... If you cannot control your environment then ask yourself if you trust your infrastructure provider at all. You can run kerberized NFS etc... but what about kerberos security? The beginning is trust towards your infrastructure. j.
On Wed, Mar 12, 2014 at 11:05:34AM +0100, Jiri Belka wrote:
On Tue, 11 Mar 2014 10:23:19 -0700 Prakash Surya <surya1@llnl.gov> wrote:
Hi,
All the documentation I've seen states that the oVirt NFS storage should use the "all_squash,anonuid=36,anongid=36" options. Obviously this isn't secure, so I'm curious how others have locked down their NFS storage? Is the best option to just limit access to these NFS exports to the IP addresses of the hypervisor nodes (and maybe the engine)? Is there a better way to go about this?
Run vlans and have some active monitoring for physical ports up|down states etc... If you cannot control your environment then ask yourself if you trust your infrastructure provider at all.
You can run kerberized NFS etc... but what about kerberos security? The beginning is trust towards your infrastructure.
It's not that I don't trust my infrastructure, because I do, I'd just like to restrict access as much as possible. All of our users are "trusted", and if a malicious user did get onto our LAN we have bigger issues to worry about; but still, limiting the storage to *only* oVirt would be better than not. Can I use kerberos with oVirt? That's what we currently use for other exports, but I assumed that would not work because of the "all_squash" and "anon" options needed. -- Cheers, Prakash
j.
participants (3)
-
Jiri Belka -
Prakash Surya -
Sven Kieske