On 24/08/2021 08:06, Erik Skultety wrote:
On Mon, Aug 16, 2021 at 08:01:27PM +0100, lejeczek wrote:
On 16/08/2021 10:32, Martin Kletzander wrote:
On Mon, Aug 09, 2021 at 11:48:11AM +0100, lejeczek wrote:
Hi guys.
On a remote & "shared" systems - are private secrets
completely 100% safe? Can root get to those?
(naturally excluding hacking of unknown bugs & exploits and
theories such as "no computer system is ultimately safe")
Well, the secret needs to be kept somewhere. The most secure you can
get with secrets is the ephemeral ones, but those still need to be kept
in memory. You could encrypt them, but then you would need to provide
the decryption passphrase or key when you want to use them and that
would be like providing the secret itself anyway. Even thought there
are some limitations to unlimited memory access in Linux when someone
has root access you have to assume they have access to what the system
has access too.
The best you can do to mitigate that is using something like Intel SGX,
AMD SEV and such like. There is Launch Security [0] in libvirt, but I
think it only supports SEV and something on s390. But I do not have any
experience with those.
[0] https://libvirt.org/formatdomain.html#id113
Last one - would by any chance you/Redhat have a schedule for Libvirt with
SEV to go into RHELs/CentOS Stream?
TL;DR
It's been there for a while, we added SEV support in libvirt 6.5.0 and the
libvirt version in current RHEL-8 is 7.0.0. I don't remember (even if I could
I could not discuss it) the strategy, but CentOS Stream 8 will likely have
a libvirt version >7.0.0.
Any chance you(with/via Redhat) could push in something more
on pair with what is in RHEL, as you explained?
At present CentOS Stream seems to have mere 6.0.0.x version.
many thanks, L.
Note that there are essentially 3 "flavours" of SEV:
SEV, SEV-ES, SEV-SNP. The main difference is in the underlying HW changes; from
libvirt's POV SEV and SEV-ES are identical, but neither QEMU nor libvirt
support SEV-SNP fully yet - the problem here is the secure state attestation
process which is still under development. What that means for end users is that
they can create memory encrypted guests the same way as with the other SEV
flavours, but they're still unable to verify that the guest hasn't been tampered
with by a malicious QEMU or platform owner or whatnot just before it was
launched.
Erik
I know one can get that via/from oVirt repos, but that for me would not
work.
thanks, L.
And if answer is yes then - do you have any best practices
for storing & managing of those secrets?
many thanks, L.
