external-secrets

external-secrets copied to clipboard

Hi! I am using the External-Secrets Operator and the secret brings it to me ok but… I need it to decode it in base64 since I need the flat values ​​as they are in the Secret Manager in GCP! I updated the ESO helm to version 0.5.9 and I am trying the following:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: cloudflare-auth
  namespace: external-dns
spec:
  refreshInterval: 1h
  secretStoreRef:
    kind: ClusterSecretStore
    name: secret-store
  target:
    name: cloudflare-auth
    creationPolicy: Owner
  data:
    - secretKey: cloudflare-auth
      remoteRef:
        key: cloudflare-auth
        decodingStrategy: Base64

If I load it like this, the state of the ExternalSecret is as follows:

NAME              STORE          REFRESH INTERVAL   STATUS              READY
cloudflare-auth   secret-store   1h                 SecretSyncedError   False

And the message inside is: message: could not get secret data from provider

Now… if I load it by changing the Base64 to Auto (https://external-secrets.io/v0.5.9/api-externalsecret/ - decodingStrategy: None # can be None, Base64, Base64URL or Auto) there it synchronizes OK the secret but if I see the secret it is encrypted and I need it to be brought to me as if I were loading a secret opaque by hand:

apiVersion: v1
data:
  mail: valor
  key: valor
kind: Secret
metadata:
  creationTimestamp: "2022-08-22T20:11:55Z"
  name: mysecret
  namespace: external-dns
  resourceVersion: "3338212"
  uid: 5a8b3ca6-7413-4e5b-9fdc-c46df2867cd6
type: Opaque

Am I missing something in the ExternalSecret that can't bring me the secret in plain text?

Thank a lot to everyone!!!!!

@jholowaty hello! the most probable cause for this error is that your secret is not a valid base64 in your provider. What I suggest you to do is to verify if your encoding is correct (copy the value from your secret and paste it in tools like this one: https://www.base64url.com/ (paste it under base64 encoding and see if it can give you your secret in plain text area).

Hi! if i copy the value of the secrets that generated by the external-secret in that url, the plain text it's ok! What I just did was load the values ​​in base64 in the secret and there I synchronized the external-secret ok (with the decodingStrategy: Base64) but if I look at the secret, the value is not displayed in plain text but in base64 yet.

I can't get the secret to bring it in plain text.

hi @jholowaty ! You mean when you do a kubectl get secret -o yaml the value is still base64-encoded? If so, that is fine, as it is the way kubernetes API exposes the secret.

If the content matches exactly what's on your provider, the mounted secret (or exposed via env var) to the application will be base64-decoded and your applications will work :)

But if a did kubectl get secret -o yaml to another secret that create by me:

apiVersion: v1 kind: Secret metadata: name: cloudflare-auth namespace: external-dns type: Opaque stringData: CF_API_EMAIL: xxxxxx CF_API_KEY: xxxxxx

I see this: kubectl get secrets mysecret -n external-dns -o yaml

apiVersion: v1 data: CF_API_EMAIL: xxxxxxx CF_API_KEY: xxxxxxx kind: Secret metadata: creationTimestamp: "2022-08-22T20:11:55Z" name: mysecret namespace: external-dns resourceVersion: "3338212" uid: 5a8b3ca6-7413-4e5b-9fdc-c46df2867cd6 type: Opaque

I need to see the same in the secret that synced the external secret because the pod fails because doesn't find for example the key CF_API_EMAIL.... but if a rename the secret mysecret to cloudflare-auth, the pod works fine.

AFAIK kubectl get secret will never output things in stringData. you can edit with it, but it will produce a secret with only the data block.

What are the errors that your pod is giving? Is it complaining of a missing key?

It's the difference between stringData and data in your Secret.

When you store plaintext values as stringData, running get secret mystringdata -o yaml will indeed display stringData and the plain text values.

Conversely if you store as base64 encoded data, running get secret myb64data -o yaml will display the data properties as... you guessed it, base64 data. You can easily decode this using a tool like yq, e.g. kubectl get secret -o yaml myb64data | yq '.data."tls.crt"' | base64 --decode.

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days.

This issue was closed because it has been stalled for 30 days with no activity.

I can confirm that this issue still exists. We had to use Auto while it was clearly a base64.

First encoding level does not need any decoding to happen. decodingStrategy:Base64 is expected when your secret on the provider level is stored as a base64.

Please also beware that Base64 strategy does not consider Base64URL - while auto does. This may explain your issue as well.

Hi @gusfcarvalho What solution can this be, if I have already encoded value in base64, and I don't need to encode it a second time, but the ESO does it and I get the error, how to prevent the operator from doing encoding?

Encoding is not done by the operator, but by kubernetes itself. You can set the decodingStrategy: Base64 to ask eso to decode your B64 encoded secret before storing to kubernetes (hence preventing the double encoding)