A big update
A couple of fairly big new modules have recently landed in Kaya, both with security being a major part of how they've been built.
A couple of fairly big new modules have recently landed in Kaya, both with security being a major part of how they've been built.
Secure Vault
Secure Vault gives you a protected area inside Kaya for sensitive documents, notes, recovery information and other data that you wouldn't necessarily want sitting in a normal runbook or document area.
Vault contents are encrypted at rest using AES-256-GCM. Each individual record, document and uploaded file is encrypted before it is written to storage, and attachment metadata such as filenames is encrypted as well.
Each Vault gets its own encryption key and access is protected separately from your normal Kaya session with a Vault PIN/passphrase and MFA. There are also recovery and portable backup mechanisms so the Vault isn't designed around Kaya being the only possible route back to your data.
Secure Send
Secure Send is designed for securely sharing sensitive files and information without resorting to normal email attachments or leaving permanent public download links around.
Security goes a bit further than simply putting a password on a download page.
Each Secure Send package gets its own randomly generated 256-bit encryption key. The message, files and even file metadata such as filenames are encrypted at rest using AES-256-GCM.
Recipient access uses a combination of a long random access token, sender-defined PIN and a randomly generated 10-word passphrase. Recipient sessions are deliberately short-lived and packages can have expiry and one-download-only restrictions.
Expiry also means expiry. Kaya has a background cleanup process which removes the encrypted files and message data and revokes any recipient sessions once a package expires, rather than simply leaving the data sitting there behind a disabled link.
The idea with both Secure Vault and Secure Send has been to make encryption and access control part of the architecture rather than something added afterwards.
High Availability
The next area I'm currently working on is HA management, with Pi-hole being the first supported service.
The idea is for Kaya to understand a pair of Pi-hole servers, know which is active and which is standby, keep the relevant configuration synchronised, and manage controlled failover when the active node becomes unavailable.
I've already been testing proper failure scenarios, including completely killing the primary Pi-hole, allowing Kaya to fail over to the secondary and then bringing the original primary back online.
A lot of the work now is around safe failback. Before moving services back, Kaya needs to know that the recovered Pi-hole is actually healthy, reachable and fully synchronised.
That means looking at things such as peer health, configuration generations and DHCP readiness rather than simply seeing that the server responds to a ping and declaring it healthy.
The other important bit is making all of this understandable in the UI. If Kaya won't fail back, I want it to clearly tell you why and what needs to happen before it is safe to do so.
Pi-hole is the starting point, but the HA framework is being designed so that other supported services could potentially make use of it later.
Kaya is becoming rather more than the little homelab inventory app it started life as.