https://github.com/peteski22/1Pwned
Check all your 1Password logins against Have I Been Pwned's API to figure out which one might be Pwned.After the Synthient Stealer Log Threat Data Breach (https://synthient.com/blog/the-stealer-log-ecosystem) I realised: you can be in a vulnerable spot if you happen to have a different password for every website, BUT the same email address.Hopefully this is useful to others who want to be able...
I disagree.
You don’t sign yourself up for surgery at the first ache.
Health is a basic human right and if your country can support that I believe it has a duty to do so.
If the system was nationalised then it has massive negotiating power when buying equipment and supplies.
That’s what happens with what’s left of our NHS before greedy capitalists got hold of it.
Under the 'trusted orchestrator' model the article you linked to describes it states "you have an orchestrator which is already authenticated against Vault with privileged permissions".
https://www.vaultproject.io/guides/identity/secure-intro.htm...
In the case of the AppRole auth method and where the orchestrator is an automated app, would it be fair to suggest that you'd have an AppRole for which secret IDs are generated that do not expire based on time and/or max uses?
From the Vault documentation here: https://www.vaultproject.io/api/auth/approle/index.html#crea...
Is it possible to set 'secret_id_ttl' to something like '0' so that it never expires?
The reason behind my question is that if the automated app is initially seeded with a role and secret ID it can login to Vault and get a token, which can be renewed going forward (based on settings for the AppRole). However, if the token is not renewed in time, or the service has to be restarted, you would need to regenerate the secret ID and reseed the application with it, which would be a manual process.
Thanks for any advice :)