|
|
| Page 1 of 1 |
|
|
 Posted: Thu, 25th Mar 2021 20:45 Post subject: Looking for a cryptographic protocol (like ssh-agent) |
|
 |
To my fellow humpers and coders I am sending out my war cry of desparation in the search for a particular cryptographic protocol I want to implement at work.
Here is the scenario:
You know how you can decrypt an encrypted openssh private key using a ssh-agent and the ssh-add command, right?
Basically, the principle is that there is a ssh-agent which runs in the background as a daemon with or without a "timeout".
Then, you run "ssh-add ~/some-private.key", which prompts you to enter the passphrase to decrypt the private key.
As per convention, ssh-add check the SSH_AGENT_PID environment variable to retrieve the PID and communication socket of the ssh-agent daemon.
Then it decrypts the private key in memory, for as long as the timeout allows it.
Usually what that means in terms of ssh is, you can connect to other servers using ssh without being prompted for a passphrase (when using public-key athentication).
Anywho's that was just the example.
What I'm looking for is somehting more generic, so let me take the terminology from above, but sprinkle in some additional requirements from my side.
I'd like to have a way, where I as the super admin on a server can run a daemon process with root rights, where I as the super admin have to enter a passphrase once per lifetime of that daemon (i.e. a timeout or every time it boots, if timeout is infinity).
Once the passphrase is entered and for as long as I allow that process to life, I want other processes to be able to "read" a secret from that process.
The way I imagine this is, that a particular technical user, say "nfohump", who runs the nfohump "appserver" is permitted to run a command per SUDO without a password.
The command may be "sudo /root_only_access/tellmethesecret.sh".
If I authenticate as user "nfohump", then I can run "sudo /root_only_access/tellmethesecret.sh" and IF ALSO the super user has entered his password to that daemon I was talking about, if those TWO factors are given, then a string is returned / written to stdout from that "tellmethesecret.sh" process.
This secret can be any arbitrary password, say the password to the MYSQL DB connection, that the "nfohump" user can use, for instance to have a connection between the nfohump appserver to it's DB.
It turns out, suprisingly, there are no standard tools that I know of that can do that.
Openssl has different cryptograhic protocols, but doesn't even have a generic "agent" like feature where I could decrypt a PKCS11 keystore, but only in memory and only for the lifespan of a "openssl-kinda-agent" - not that I know of.
The only thing remotely similar that I found is some piece of code from MIT, written in GO and depending on some strange "build2" build system and it's own "bpkg" package manager that I'm not familiar with and I don't wanna use.
To take one step back and describe the problem more generally:
I want to make sure that my super admins don't have to blindly trust my application responsibles with passwords or anything like that, but instead build a system where one role (super admins) provides one side of the puzzle, the other side (particular application) provides the other side and both must be true at the same time for the whole thing to work.
I want to able to "revoke" access at anytime without fear that application responsibles leak passwords by hardcoding them into their configs or scripts or programm code.
Specific example:
I am root on server nfo-appserver.com.
There is a separate server, which runs the DB: nfo-db.com.
On my nfo-appserver I have root and one developer has access to "nfohump" (technical user), which runs the nfo appserver on it.
I don't want to tell that developer what the password to his DB connection is.
I want to have a process/daemon that I can enter a passphrase to decrypt the "real" DB connection's password.
When the daemon is running and "decrypted", only the technical user "nfohump" can run a special command via sudo "sudo /root_only_access/tellmethesecret.sh".
I make that the path "/root_only_access" can only be accessed by root. And "tellmethesecret.sh" also can only be run by root as well.
The developer has to call that command to retrieve the password (either inside a script, or in memory, e.g. into a environment variable) in a way that he can use it for his purpose (say, establish a DB connection).
The point is, that I don't have to tell the developer this password and the developer cannot hard-code it into cleartext configs or scripts.
One caviat: I don't care if the developer, if they were super-smart, will read out the password for himself.
We are still adults, we still have our professional conduct to uphold. The point is, never ever use it in plaintext, on files, on disk, ever again.
Is that kinda clear or was that too complicated?
Any suggestions on how to achive this with common opensource tools, e.g. openssl etc.?
"There will be no end to the troubles of humanity, until philosophers become kings, or kings become philosophers.", Plato.
"Hyperbole will destroy us all.", Matt Dillahunty.
"The hyperbole, the demonization of the other opinion and the unwillingness to even read the opposing opinion destroys the so important political discussions necessary for the well functioning of society.", Couleur
|
|
| Back to top |
|
|
|
|
|
| Back to top |
|
|
|
|
| Posted: Thu, 25th Mar 2021 22:04 Post subject: |
|
|
Last edited by paxsali on Thu, 4th Jul 2024 23:07; edited 2 times in total
|
|
| Back to top |
|
|
|
|
|
| Back to top |
|
|
|
|
| Posted: Thu, 25th Mar 2021 22:26 Post subject: |
|
|
Last edited by paxsali on Thu, 4th Jul 2024 23:07; edited 2 times in total
|
|
| Back to top |
|
|
|
|
| Posted: Thu, 25th Mar 2021 22:46 Post subject: |
|
|
Its the go-to automation tool that handles secret management either itself ansible-vault or integrating with better tooling like Hashicorp Vault. 4treyu may be assuming "Ansilbe tower" use as well though as "ansible" it doesn't come with RBAC out of the box, you can implement RBAC through your SDLC workflow tool or with Ansible Tower, Ansible Tower is a GUI driven webserver that augments ansible with RBAC and a couple of other minor features.
I don't know what UC4 is, but sounds like you may be missing some fundamental infrastructure you need to handle secret management, to avoid passwords stored on disk or stored in code etc.
Depends on your timeframe, if its got to be done asap. I just deploy what you can with what you have now to unblock the requirement. You will need more time to review secrets architecture, dev an MVP, learn the tech, and fully determine what you need to do to secure this and other requirements in future.
|
|
| Back to top |
|
|
|
|
| Posted: Sat, 27th Mar 2021 19:07 Post subject: |
|
|
Last edited by paxsali on Thu, 4th Jul 2024 23:07; edited 2 times in total
|
|
| Back to top |
|
|
|
|
| Posted: Wed, 25th Aug 2021 01:29 Post subject: |
|
|
|
|
|
| Back to top |
|
|
| Page 1 of 1 |
All times are GMT + 1 Hour |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB 2.0.8 © 2001, 2002 phpBB Group
|
|
 |
|
ansible is agentless, daemonless and free. But suit yourself 
