There's a LOT of ways to go over this. A short list includes:
- Web Service(s)
- Encrypted local storage
- Encrypted accessible storage shared between VMs / containers
While some of them have a lot of advanced feature(auditing, full control, much better security) they will often ALL require some sort of set up. So since you mentioned having acess to deploying containers, lets go with a frozen, hard to access method middle route.
The Best Image(s)
Since you can deploy containers easily, this option is to have a container whose SOLE purpose is to send the encrypted auth methods for the scripts and return before dying off that is only accessible from the LAN of the containers in your VPL(Virtual Private Lan) so that it NEVER communicates with the outside world. At this point all that's on the script container is a decryption key. Just with your internal containers and docker machines in your remote area no one can listen to this. This would mean your script would have the decryption key, and only be accessible locally. If it ever gets compromised, upload 2 new container images and you're done.
- Already uses a model you're deploying
- LAN only. Use a reserved internal IP(172.X.X.X range) on a controller to communicate with this docker
- Multiple points of security means that if compromised, new credentials can be upload in freshly made, clean docker images
- EXTREMELY hard to compromise(not the same machine, not the same code, would have to compromise BOTH ends to make it worthwhile)
- Easily protected(who needs SSH on a container, right?)
- EXACT port control(don't use common ones, use a really obscure one for your purposes only)
- Many more
- Two containers to co maintain with encrypted piece, and decryption piece
- Oh no, two uploads
Since this never goes out over the net no-one outside the network can grab the packets and attempt to do passes to discover it. The list of pros is definitely larger than the small amount of effort it would take to even set this up since it's a container image. Just upload the new code, done.
Now that you have no worry about storing the password on the containers with the script, or the container with the decrypt key you can be assured that at rest it is next to impossible to crack. Especially if you use TLS with cert pinning. Now you have to best of EVERY world, even if the containers somehow end up on the same host.
The only people that could crack this at this point would be you, and anyone else privy to how it was exactly setup. However that's because the most dangerous link in the Cyber Security chain is the Human(s).