I've written an application in NodeJS which essentially only performs a login: You send your username/password, and you retrieve an JWT (JSON Web Token).

Those tokens are being signed by a private key. Using HMAC, these tokens can be verified using the public key so that noone can change the data inside.

Other API-Endpoints on different servers will get the public-key and can check that the user is actually verified/logged in and is able to access that route.

Now, my issue being, that I put that service inside a Docker-Container. Inside the container, the application just starts up and opens its port so the HTTPS requests can be received.

Assuming I want to start the container multiple times for loadbalancing aswell as a measure against failures, how would I pass the single private key into all started instances, so they could sign the tokens that I want to hand out?

I dont think that just having a fileshare e.g. SMB/NFS where the private key is located on is a good idea. On the other hand, a custom E2E System seems to be overkill for my purpose.

How would you go ahead and share the single private key to multiple instances, without having a breach at risk?

2 Answers 2


Depending on your setup and business constraints:

  1. In a container orchestration system you can use the system's provided ways to populate the key to each container. For example, in kubernetes you can use a secrets configuration object that will allow the containers to access the key as an environment variable or a file (keep in mind that secrets do not encrypt their content - they just encode them in base64 format)
  2. Use a key management application like Hashicorp Vault that will allow you to manage the private/public key pair lifecycle in an easy way and allow your application interact with it to get the necessary keys

There are pros and cons to each approach (e.g. the first is easier to implement, the second provides extended key lifecycle support that may be useful in the long run) but which one you may choose depends on your requirements.

  • I am not using Kubernetes (yet), but I might move to it later. Is it in general a good idea to have some kind of API (smth. like REST or raw TCP) to fetch private Keys from a central storage? Commented Nov 13, 2022 at 20:03
  • It has its pros and cons. However, it really facilitates key management in the long run. For example, key rotation is much easier with a centralized system, key revocation, key distribution etc. Having said that, rolling your own solution might not be ideal, because a centralized key management system is a single point of failure in security - that is why people tend to look for solutions specifically designed for this purpose
    – user284677
    Commented Nov 14, 2022 at 5:24

If you use Kubernetes, you can save private key as a secret. All containers of particular service will see it. If you need to update the private key later on, you can just update the secret. Kubernetes will pass the secret as an environment variable to the container.

Secrets are strings. You can convert the private key in some text format, e.g. to a Base64 or to a hexadecimal string.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .