Using something like this for centralized authorization across services works well for binary access control decisions.
But the problem that remains is "authorized search" in an efficient way. Asking permify what resources a user can access and then query the app postgres db with "WHERE resource_id IN ( {list}, {with}, {many}, {IDs}, ... )" does not scale well. How to solve this?
What's considered nowadays the best practice (in terms of security) for running selfhosted workloads with containers? Daemon less, unprivileged podman containers?
And maybe updating container images with a mechanism similar to renovate with "minimumReleaseTime=7days" or something similar!?
Is there any concept of private key rotation or something else? In case a client with a nostr key on it got compromised or something similar? With a traditional password passed logins I would just set a new password from another machine. Regeneration of a new nostr key would mean it's a new account isn't it?
Instead of the luks key in tpm you can use a fido2 compatible hardware security usb token. For booting/unlocking it has to be plugged in then you can remove it. This is pretty convenient and secure against many threats like stealing the nas in my opinion.
There is the open source software project gluetun, that allows setting up a containers that are only able to communicate through a vpn network interface in an easy way.
One thing I find difficult using access control systems as a distributed service like Zanzibar is a convenient and performant way to search and filter resource data using permissions. For example defining database queries that should only return resources a subject has access to based on Zanzibar permissions.
But the problem that remains is "authorized search" in an efficient way. Asking permify what resources a user can access and then query the app postgres db with "WHERE resource_id IN ( {list}, {with}, {many}, {IDs}, ... )" does not scale well. How to solve this?