Search code examples
kuberneteskubernetes-secretskustomizeargocd

The value of argocd-secret is further encoded to base64


When managing secrets in argocd, I encode the value in argocd-secret with base64 and set it to manifest.

In that case, although I use kusotomize, build and apply it, secret encoded by base64 will be encoded to base64 further.

$ echo -n "clientid" | base64
Y2xpZW50aWQ=

$ echo -n "clientsecret" | base64
Y2xpZW50c2VjcmV0
---
apiVersion: v1
kind: Secret
metadata:
  name: argocd-secret
type: Opaque
stringData:
  dex.github.clientID: Y2xpZW50aWQ=
  dex.github.clientSecret: Y2xpZW50c2VjcmV0

If you use kustomize build to build and check the difference, it looks like this

$ kustomize build --load_restrictor none overlays/dev/ap-northeast-1/argocd | k diff -f -

+  dex.github.clientID: WTJ4cFpXNTBhV1E9
+  dex.github.clientSecret: WTJ4cFpXNTBjMlZqY21WMA==

I don't understand why something encoded by base64 is encoded further. I'm going to ask for someone's help.

Thanks.


Solution

  • I reproduced your case and it looks like it isn't further encoded by kustomize but by kubectl (either by kubectl client itself or by kube-apiserver performing the operation requested by e.g. kubectl apply command).

    And here you can find a fragment that sheds some light on why this is actually happening:

    The Secret contains two maps: data and stringData. The data field is used to store arbitrary data, encoded using base64. The stringData field is provided for convenience, and allows you to provide secret data as unencoded strings.

    The data field serves for storing the data already encoded using base64 and value of this field isn't further encoded when we apply the Secret. The stringData however behaves quite differently. It allows you to provide secret data as unencoded strings and for that reason it is further encoded when you run kubectl apply. In your example you use stringData field and although it contains already encoded data, it is treated as any other string and in consequence is encoded again.

    Solution: simply use data rather than stringData map in your Secret and your base64 encoded strings won't be encoded again during the resource creation.