You’re running around in circles…let me elaborate, how this plays out.
Hypothetically, let’s say you have a centralized service that’s a key:value store (in your case secret_id:secret_value). You can have some kind of API (e.g. http/json or plaintext) to fetch the secret on demand, so you don’t have to store it alongside the project code.
How do you build an ACL enforcement system around it that will authenticate the thing that’s fetching the secret - after all you don’t want your secrets leaking to anyone who asks.
- You could give it another secret/password?
- You could trust the network (ip based security)?
- You could trust the kernel/os?
- You could trust whoever is deploying an app to “bless” the deployment?
- You could use some combination of the above?
Both kerberos (symmetric crypto / hmac used to generate authenticate-able / identifiable tickets), and in spiffe (newer asymmetric crypto used to sign authenticate-able/identifiable certs) solve it similarly. In both you have this “attestation” step, where you use something you already trust to bootstrap trust in something new. In old kerberos, you’d rely on admins to setup principals (identities) for users and services and do so “wisely”. Additionally for human principals, you’d bootstrap trust using a password or similar and you’d trust the os to not leak credentials across users.
In SPIFFE, you have an agent on a host OS (SPIRE), that is trusted that can sign certs based on uid of the requesting process which is using some local filesystem socket (e.g. when setting up a container, you can map the uid that container is using to a “service account”, identity in “your cloud” or your bunch of machines).
In both cases you trust the host OS on the machine to be setup to not leak credentials across UIDs. (because it’s a product of a controlled setup environment / blessed by admin doing setup manually, or blessed by an installation process, … turtles all the way down).
When time comes to do things in a prod environment you shouldn’t rely on a large number of usernames / passwords for access to services across a network in the first place. Rely on secure bootstrapping processes and mTLS and certs… and kerberos for old corporate workstation/user auth. (You can build a service to exchange krb tickets for certs in <100lines of python, no big deal). And if services you run don’t look like they support it, practice using proxies that do.
At home, you can play with kerberos or ssh tunnels or TLS proxies or fancy service mesh proxies… bootstrapping something like spire/kerberos with only a handful of machines and building out that infra is also fun practice.