On 2025-07-29 21:27:51 +0100 (+0100), Sean Mooney wrote: [...]
`in general if someone can acess the host filesystem and read the nova.conf your security evnolope has already been breached. [...]
It's not uncommon in naïve security policies that are primarily concerned with "data at rest" to require all sensitive information on disk be encrypted. Their authors are typically focused on what happens if a decommissioned hard drive or stray backup tape falls into the wrong hands. As you note, there's a substantial Catch-22 here, in that the client keys for accessing the remote service represent a similar risk unless kept isolated, e.g. in an HSM. What this fails to address, though, is that the plaintext form of passwords and keys will still be present in process memory on running systems, and in many cases these systems are configured with swap partitions or files which are themselves not encrypted, so it's still possible for the vulnerable secrets to end up on disk if they get paged out for any reason. Encrypted swap can help here, but at that point why not just encrypt the entire disk and be done with it? Measures to fully isolate secrets from storage on a system that uses them are rarely worth the operational costs. As a security professional, when presented with requirements like these my initial recommendation is to think hard about what exactly you're protecting and from whom. Essentially, "define your risks." To make sense, the cost of the solution should not exceed its value. If you can't define the value of a security measure, it probably has none in actuality. If you can't estimate the cost and likelihood of a risk being exploited, then it's likely not worth mitigating. If you can't answer these questions, then first find someone who can. -- Jeremy Stanley