Mounting an OpenShift Secret to its own volume is straightforward. There are plenty of examples on how to do it. The Web is littered with examples. Next, the most common thing any manual, guide or tutorial would say is to encode the secret in Base64.
For example I have a SSL certificate stored in a Java KeyStore file format or JKS. The recommended way is to store it in a Secret instead of ConfigMap since it is sensitive information. Of course, that goes without saying the JKS file is password-protected.
Second, it must be as a Base64 string before I save it as OpenShift Secret.
How do I get the Base64 string to be decoded in the mounted volume? This one does not seem to get many answers.
Do I need to include shell commands to decode it and write it to a folder?
Which folder should I write it to as best practice?
#1 The encoded JKS Secret as an environment variable
This is an option but I’m not a fan of it. The JKS file when encoded can become very long, especially when the file size is large. I don’t think environment variables were meant to be used like this – hold very long text values. That said, this is an easier implementation.
Map out the secret as an env var in OpenShift or Kubernetes. Then you can use that env var to echo the value and write it out to a file.
echo -n $SECRET_JKS_VAR | base64 --decode > /file/path/to/decoded-secret.jks
#2 Mount for read, mount for write
You have the secret mounted to a file path. That is for reading. Now you need to decode, which means writing to a file so your application can read it back unencoded.
First, define a mount point as and empty directory. It must be writable. Then make it memory only.
Next, read the JKS file from its mount point, write it out to the empty dir mount point.
cat /mount/file/path/for-reading/encoded-secret.jks | base 64 --decode > /mount/file/path/for-writing/decoded-secret.jks
I like this approach better. It makes more sense rather than mapping a very long base64-encoded text value as an environment variable. The caveat is here is slightly more configurations to be made. Also if I’m not mistaken the in-memory volume count against your app memory quota. Should be negligible unless you write thousands of files into it.
#3 Lastly, write where you can
Underneath that container is a file system. Where you have permission to write, then do so there. If it’s Linux, then this decision is pretty much arbitrary IMHO. Put it in /tmp or /home or /mnt. Security wise, others might have access to your app’s pod, that means they can get to the Secret as well. But that is another topic.