How do I properly store and load .jks on to my Java/Spring microservice?

Question

I need to store/load a separate JKS file for a very specific 3rd party integration on one of my microservices (Spring/JAVA). Those key/certificate pairs should be used by a separate background task that should call 3rd party servers once in a while using custom black box SDK. This SDK requires a path to JKS file as one of input params, so it must be physically stored on disk.

The simplest approach I am going with for now: JKS stored in git under resources folder, then password supplied to docker container through some custom terraform script. How bad/not secure is this? Assuming repo is private github.

I think another options might be (considering docker/terraform run by jenkins builder, deployed to aws ecs):

1. Load at runtime from aws secret manager/encrypted s3 then store on filesystem.
2. Somehow supply at image building stage.
3. Somehow supply at container startup stage.

Now the question is, how do I properly store and load this JKS on my service? What wold be the best way and would be the minimum acceptable way?

Answer 1

If we go full enterprise security mode, developers shouldn't even have access to that JKS file.

For development, they should get a different JKS file that gives them just enough permissions to do their development work.

To get a file that is only accessible at runtime from a running Docker image, you can put it on a Volume that is only mounted in production, and managed separately from your normal development deployments.

If you use Docker Swarm or Docker Compose, you can define it as an external Docker secret, and your file will be available under /run/secrets/my_secret.jks.

version: "3.8"
services:
  redis:
    image: redis:latest
    deploy:
      replicas: 1
    secrets:
      - my_secret_jks
secrets:
  my_secret_jks:
    external: true

If you use Kubernetes, you can store the file as a Kubernetes Secret and mount it as a volume of type secret:

apiVersion: v1
kind: Pod
metadata:
  name: secret-test-pod
spec:
  containers:
    - name: test-container
      image: nginx
      volumeMounts:
        # name must match the volume name below
        - name: secret-volume
          mountPath: /etc/secret-volume
          readOnly: true
  # The secret data is exposed to Containers in the Pod through a Volume.
  volumes:
    - name: secret-volume
      secret:
        secretName: test-secret