New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Environment variables from Secret include new line character #23404

Closed
motomux opened this Issue Mar 23, 2016 · 35 comments

Comments

Projects
None yet
@motomux
Copy link

motomux commented Mar 23, 2016

secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  password: MWYyZDFlMmU2N2RmCg==
  username: YWRtaW4K

secret-env-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: secret-env-pod
spec:
  containers:
    - name: mycontainer
      image: redis
      env:
        - name: SECRET_USERNAME
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: username
        - name: SECRET_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: password
  restartPolicy: Never

Run pod and export environment variables.

kubectl create -f secret.yaml
kubectl create -f secret-env-pod.yaml
kubectl exec -it secret-env-pod bash
root@secret-env-pod:/data# export

Environment variables.

declare -x GOSU_VERSION="1.7"
declare -x HOME="/root"
declare -x HOSTNAME="secret-env-pod"
declare -x KUBERNETES_PORT="tcp://10.55.240.1:443"
declare -x KUBERNETES_PORT_443_TCP="tcp://10.55.240.1:443"
declare -x KUBERNETES_PORT_443_TCP_ADDR="10.55.240.1"
declare -x KUBERNETES_PORT_443_TCP_PORT="443"
declare -x KUBERNETES_PORT_443_TCP_PROTO="tcp"
declare -x KUBERNETES_SERVICE_HOST="10.55.240.1"
declare -x KUBERNETES_SERVICE_PORT="443"
declare -x KUBERNETES_SERVICE_PORT_HTTPS="443"
declare -x OLDPWD
declare -x PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
declare -x PWD="/data"
declare -x REDIS_DOWNLOAD_SHA1="e56b4b7e033ae8dbf311f9191cf6fdf3ae974d1c"
declare -x REDIS_DOWNLOAD_URL="http://download.redis.io/releases/redis-3.0.7.tar.gz"
declare -x REDIS_VERSION="3.0.7"
declare -x SECRET_PASSWORD="1f2d1e2e67df
"
declare -x SECRET_USERNAME="admin
"
declare -x SHLVL="1"
@ghost

This comment has been minimized.

Copy link

ghost commented Mar 24, 2016

@pmorie
On Mar 23, 2016 3:07 PM, "motomux" notifications@github.com wrote:

secret.yaml

apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
password: MWYyZDFlMmU2N2RmCg==
username: YWRtaW4K

secret-env-pod.yaml

apiVersion: v1
kind: Pod
metadata:
name: secret-env-pod
spec:
containers:
- name: mycontainer
image: redis
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: mysecret
key: username
- name: SECRET_PASSWORD
valueFrom:
secretKeyRef:
name: mysecret
key: password
restartPolicy: Never

Run pod and export environment variables.

kubectl create -f secret.yaml
kubectl create -f secret-env-pod.yaml
kubectl exec -it secret-env-pod bash
root@secret-env-pod:/data# export

Environment variables.

declare -x GOSU_VERSION="1.7"
declare -x HOME="/root"
declare -x HOSTNAME="secret-env-pod"
declare -x KUBERNETES_PORT="tcp://10.55.240.1:443"
declare -x KUBERNETES_PORT_443_TCP="tcp://10.55.240.1:443"
declare -x KUBERNETES_PORT_443_TCP_ADDR="10.55.240.1"
declare -x KUBERNETES_PORT_443_TCP_PORT="443"
declare -x KUBERNETES_PORT_443_TCP_PROTO="tcp"
declare -x KUBERNETES_SERVICE_HOST="10.55.240.1"
declare -x KUBERNETES_SERVICE_PORT="443"
declare -x KUBERNETES_SERVICE_PORT_HTTPS="443"
declare -x OLDPWD
declare -x PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
declare -x PWD="/data"
declare -x REDIS_DOWNLOAD_SHA1="e56b4b7e033ae8dbf311f9191cf6fdf3ae974d1c"
declare -x REDIS_DOWNLOAD_URL="http://download.redis.io/releases/redis-3.0.7.tar.gz"
declare -x REDIS_VERSION="3.0.7"
declare -x SECRET_PASSWORD="1f2d1e2e67df
"
declare -x SECRET_USERNAME="admin
"
declare -x SHLVL="1"


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#23404

@pmorie

This comment has been minimized.

Copy link
Member

pmorie commented Mar 24, 2016

@motomux thanks for finding this; i will fix it.

@pmorie pmorie self-assigned this Mar 24, 2016

@vaijab

This comment has been minimized.

Copy link

vaijab commented Mar 30, 2016

@motomux actually they don't. The reason your secrets contain a new line \n is because the original string contained a new line:

~> echo -n 'MWYyZDFlMmU2N2RmCg==' | base64 -d
1f2d1e2e67df
~> echo -n '1f2d1e2e67df' | base64 -w0
MWYyZDFlMmU2N2Rm~>
~> echo -n 'MWYyZDFlMmU2N2Rm' | base64 -d
1f2d1e2e67df~> 

Hope this helps.

@pmorie

This comment has been minimized.

Copy link
Member

pmorie commented Mar 31, 2016

I guess the question here is, should we try to protect you from yourself if you accidentally create a secret value that ends with a newline? I don't have a use-case ready for when you would want such a key to end with a newline, but I feel that it might be impossible to predict all expectations here, so I'm inclined, after thinking about it, to avoid trying to munge with values in ConfigMaps or Secrets.

@motomux since you reported this issue, I wonder your thoughts.

@derekwaynecarr

This comment has been minimized.

Copy link
Member

derekwaynecarr commented Mar 31, 2016

If the secret was created incorrectly say via a kubectl create secret command, then we should fix that bug, but I do not think we should introspect the value of a secret / configmap. what is persisted in the secret value is what the pod should get exactly.

@thockin

This comment has been minimized.

Copy link
Member

thockin commented Apr 2, 2016

We should not mutate the user's input. Period.

On Thu, Mar 31, 2016 at 11:10 AM, Derek Carr notifications@github.com
wrote:

If the secret was created incorrectly say via a kubectl create secret
command, then we should fix that bug, but I do not think we should
introspect the value of a secret / configmap. what is persisted in the
secret value is what the pod should get exactly.


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#23404 (comment)

@motomux

This comment has been minimized.

Copy link
Author

motomux commented Apr 3, 2016

Thank you for your clarifying it. I didn't know that output of echo has new line character.

I don't think kubectl should change user's input neither, but I think the document about secret should be changed to use echo -n instead of just echo or put some notes since I created secrets like the document and had the issue.

@thockin

This comment has been minimized.

Copy link
Member

thockin commented Apr 3, 2016

+100 to docs fixes. @pmorie

On Sat, Apr 2, 2016 at 5:39 PM, motomux notifications@github.com wrote:

Thank you for your clarifying it. I didn't know that output of echo has
new line character.

I don't think kubectl should change user's input neither, but I think the
document about secret http://kubernetes.io/docs/user-guide/secrets/
should be changed to use echo -n instead of just echo or put some notes
since I created secrets like the document and had the issue.


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#23404 (comment)

@pmorie

This comment has been minimized.

Copy link
Member

pmorie commented Apr 4, 2016

@motomux that's a great suggestion. I'll change this for configmap and secret.

@d-Pixie

This comment has been minimized.

Copy link

d-Pixie commented May 11, 2016

@pmorie just a ping so you don't forget. This bit me today after following the Secrets docs :/ Good thing I found this issue first thing when investigating :D

joonathan added a commit to joonathan/kubernetes.github.io that referenced this issue May 11, 2016

Use `echo -n` for less ambiguous base64 secret example
One could be bitten by having unexpected newline characters in base64 encoded secrets (reference: kubernetes/kubernetes#23404).
Calling `echo -n` will omit the trailing newline character.

`
     The echo utility writes any specified operands, separated by single blank (` ') characters and followed by
     a newline (`\n') character, to the standard output.

     The following option is available:

     -n    Do not print the trailing newline character.  This may also be achieved by appending `\c' to the end
           of the string, as is done by iBCS2 compatible systems.  Note that this option as well as the effect
           of `\c' are implementation-defined in IEEE Std 1003.1-2001 (``POSIX.1'') as amended by Cor. 1-2002.
           Applications aiming for maximum portability are strongly encouraged to use printf(1) to suppress the
           newline character.
`
@pmorie

This comment has been minimized.

Copy link
Member

pmorie commented May 11, 2016

@d-Pixie my bad, I had thought I fixed this already.

@javiercr

This comment has been minimized.

Copy link

javiercr commented May 25, 2016

I had the same problem a few days ago, kudos for updating the docs!

@untoreh

This comment has been minimized.

Copy link

untoreh commented Jul 4, 2016

what about an optional flag for trimming like spaces and new lines when creating secrets?

@thockin

This comment has been minimized.

Copy link
Member

thockin commented Jul 4, 2016

We should not mutate the user's input, and adding flags is feature creep. Especially since the shell tools all have this ability already..

@dims

This comment has been minimized.

Copy link
Member

dims commented Jul 8, 2016

@pmorie @thockin So we can close this issue now?

@thockin thockin closed this Jul 8, 2016

@matthughes

This comment has been minimized.

Copy link
Contributor

matthughes commented Aug 11, 2016

What version was this fixed? Using client/server 1.3.0, I create a secret from a file (that has no new lines) and my environment variable still has a new line at the end.

@thockin

This comment has been minimized.

Copy link
Member

thockin commented Aug 11, 2016

@pmorie

On Aug 10, 2016 7:50 PM, "Matt Hughes" notifications@github.com wrote:

What version was this fixed? Using client/server 1.3.0, I create a secret
from a file (that has no new lines) and my environment variable still has a
new line at the end.


You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#23404 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVOrNJu--rMdzbaCa0rDBqbCWWQnLks5qeo3sgaJpZM4H3hlf
.

@ryuheechul

This comment has been minimized.

Copy link

ryuheechul commented Dec 28, 2016

Env from secret has a newline regardless the variable has newline or not.
using 1.4.6

@thockin

This comment has been minimized.

Copy link
Member

thockin commented Dec 28, 2016

If you mean to report a bug, please open a new issue, rather than piling on the end here.

@ryuheechul

This comment has been minimized.

Copy link

ryuheechul commented Dec 29, 2016

Just for folks who's still having this issue.
I made a script to workaround this issue and it works for me.

@henry-hz

This comment has been minimized.

Copy link

henry-hz commented Mar 2, 2017

I also have this issue... lost 1 day figuring out what happened...
the URL comes from secrets, the MONGO_URL comes from env variable on deployment.yaml

bash-4.3# node                                                                                                                                                                                                                                                                    
> process.env.URL                                                                                                                                                                                                                                                                 
'mongodb://blabla@ds1.mlab.com:57469/demo\n'                                                                                                                                                                                                   
> process.env.MONGO_URL                                                                                                                                                                                                                                                           
'mongodb://blabla@ds1.mlab.com:57469/demo'                                                                                                                                                                                                     
@jrglee

This comment has been minimized.

Copy link

jrglee commented Mar 2, 2017

I started to face this issue once I started to generate secrets from files, i.e.:kubectl create secret generic mysecret --from-file=password.

The secret in this case is the content of the password file and \n when the file has only a single line. If I add an empty line in the file then my secret will contain \n\n.

Some of my apps work because they do a .trim() on the value which gets rid of the line breaks. The reason why I did not face this issue before is because I used a script with exports as a secret, the extra \n didn't cause any issues because it is just an extra line in a bash script.

@henry-hz

This comment has been minimized.

Copy link

henry-hz commented Mar 6, 2017

thanks @jrglee for the work around

@pjanuario

This comment has been minimized.

Copy link

pjanuario commented Jul 11, 2017

I had exactly the same problem and took me a bit until I found out this was the reason... :/

@vladimir-vg

This comment has been minimized.

Copy link

vladimir-vg commented Sep 22, 2017

Experienced same issue. Used kubectl create secret generic mysecret --from-file=password, file contained no '\n', but resulting env variable had it.

Client Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.5", GitCommit:"17d7182a7ccbb167074be7a87f0a68bd00d58d97", GitTreeState:"clean", BuildDate:"2017-08-31T09:14:02Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.3", GitCommit:"2c2fe6e8278a5db2d15a013987b53968c743f2a1", GitTreeState:"clean", BuildDate:"2017-08-03T06:43:48Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
@thockin

This comment has been minimized.

Copy link
Member

thockin commented Sep 22, 2017

@gtpgi

This comment has been minimized.

Copy link

gtpgi commented Sep 23, 2017

@thockin-cc Thanks for the hexdump hint. I had the same problem with k8s secrets adding an extra character and saw the Vim was adding a newline on my secret files. Using the fixes described in https://stackoverflow.com/questions/1050640/vim-disable-automatic-newline-at-end-of-file I edited the files to remove the ending newline and re-created the secrets. They worked perfectly after that.

@vladimir-vg

This comment has been minimized.

Copy link

vladimir-vg commented Sep 23, 2017

Are you SURE? Many editors include a final newline.

Tried with hexdump, and turns out that I was wrong. There is a '\n' in the file, sorry for misleading.
Vim was hiding it from me.

@zezuladp

This comment has been minimized.

Copy link

zezuladp commented Apr 25, 2018

Doesn't the idea that you have to echo the password into a file go against the philosophy in the documentation about not having passwords in terminal log?
Note that neither get nor describe shows the contents of the file by default. This is to protect the secret from being exposed accidentally to someone looking or from being stored in a terminal log.

Once echo'd it's in terminal and bash history. I feel allowing text editor with default settings to create a password that can be correctly read is more in line with the philosophy laid out in the docs.

@Franselbaer

This comment has been minimized.

Copy link

Franselbaer commented May 25, 2018

I'd like to store a multiline pem file in secret store and running into same problems

@thockin

This comment has been minimized.

Copy link
Member

thockin commented Jun 5, 2018

@Franselbaer What problems? This whole "bug" seems to have been errant newlines. Storing a multi-line string should be fine.

@zezuladp Your point is good - there are better ways than echo :)

@Franselbaer

This comment has been minimized.

Copy link

Franselbaer commented Jun 15, 2018

I sorted it by putting the multiline pem file uuencoded into the secret.... and when i pull it out, i pipe it through uudecode... works fine 👍

@Sieabah

This comment has been minimized.

Copy link

Sieabah commented Oct 17, 2018

So I bashed my head against this for a few minutes trying to figure out how I'm introducing a newline. Here is a way to always ensure the newlines are stripped before piping to base64.

echo "$SOMETHING_SECRET" | tr -d \\n | base64 -w 0

Obviously you can replace echo with cat or whatever process you want to retrieve the secret.

@thockin

This comment has been minimized.

Copy link
Member

thockin commented Oct 17, 2018

@Sieabah

This comment has been minimized.

Copy link

Sieabah commented Oct 17, 2018

Didn't realize echo added an arbitrary newline.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment