CODEWITHSUNDEEP
kubernetesssltls1.2
Matt - Block-Farms.io
Matt - Block-Farms.io

Reputation: 594

Kubernetes env referencing a tls crt and key

I have been trying to port over some infrastructure to K8S from a VM docker setup. But I cannot seem to reference the tls certificate and key properly within the K8S env.yaml such that the container using the env can use them correctly.

In a traditional VM docker setup the .env file looks like this for referencing the tls cert+key:

TLS_CERT_PATH=/tls/server.crt
TLS_KEY_PATH=/tls/server.key

In my K8S I create the tls cert+key via:

kubectl create secret tls cl-tls --key "server.key" --cert "server.crt"

And I reference the tls cert+key via within the env-configmap.yaml via:

apiVersion: v1
kind: ConfigMap
metadata:
  name: env-config
data:
  TLS_CERT_PATH: "cl-tls"
  TLS_KEY_PATH: "cl-tls"

I have additionally tried with no luck either:

kubectl create secret generic tls-cert --from-file="server.crt"
kubectl create secret generic tls-key --from-file="server.key"

With a env-configmap.yaml:

TLS_CERT_PATH: "tls-cert"
TLS_KEY_PATH: "tls-key"

Upvotes: 0

Views: 2199

Answers (1)

zer0
zer0

Reputation: 2919

You are mixing two different concepts.

  1. You want to make the server.key and server.cert files available to your pods, and want to reference them in your pod specification in the form of PATH variables. This is a separate implementation. LEGACY APPROACH
  2. You want to convert the server.key and server.cert to a secret object. And you want to use the secret in your pods to inject the server.key and server.cert information directly in the pod. KUBERNETES NATIVE APPROACH

Note: You do not need a ConfigMap in any case. (You should never use ConfigMap type for sensitive data anyway).

Procedure for Approach 1

  1. Put the server.cert and server.key in a directory on the worker node where your pod will run. Let's call it ~/certs/.
  2. Mount this directory as a volume to your pods, with type hostPath. You can read more about them here.
  3. Add TLS_CERT_PATH: "~/.certs/server.cert" and TLS_KEY_PATH: "~/.certs/server.key" as environment variable to your pod. This will work as expected.

This is it. You do not need config maps or secrets and this approach will work. This is not a recommended approach since if you want to rotate the certificates when they are about to expire, you'll have to manually update the server.key and server.cert files on your node for the pod authentication to work. But this is how it will be done.

Procedure for Approach 2

  1. Create a tls type secret with your server.cert and server.key files. (You're already doing this correctly). You can use this doc for more details.
  2. Use that secret to inject the server.cert and server.key into your pods. You will mount this secret as a volume to your pod. And then you can reference the secret parameters as "files" in your pod specification. When secrets are used in this way the parameter name becomes a file at the mount point, and the parameter value becomes the contents of that file. You'll configure your pod specification with environment as TLS_CERT_PATH: "secret/mount/path/server.cert" and TLS_KEY_PATH:"secret/mount/path/server.key". You can find the recipe to do that in the docs here.

Both approaches will work. Except this time, you can very easily rotate your TLS certificates by simply updating the Secret object and the volume mount sync will automatically update it in all the pods that have it mounted. Understand that secrets are functionally equivalent to ConfigMaps. Both are key/value pairs. It is just that Secrets have special attributes and features that make them more suitable to be used for sensitive data.

Hope this helps!

Upvotes: 2

Related Questions