What's weird is that the Watchtowwer in the 1Password desktop app didn't show this, but the mobile app does show 'Vulernable Passwords' which it uses the Have I Been Pwned breach data for. 0_o
76 karma · joined April 3, 2014
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 :)