process_linux.go:398: container init caused \"setenv: invalid argument\"": unknown

[azachar]

Hello, Could you please suggest what is wrong? What kind of env variable breaks starting the container?

Thank you!

Error response from daemon: OCI runtime create failed: container_linux.go:296: starting container process caused "process_linux.go:398: container init caused \"setenv: invalid argument\"": unknown

[ghost]

We met this on Kubernetes with crio, and we attach a secret on the pod. But the secret we use is in plain text, since base64 is so flexy so the plain text can be decoded by base64. And when pass to the runtime layer, the runtime take the binary structure as the value to be setted, so got this error.

After we create the secret with base64 encoded value, worked as before.

[ghost]

According to https://golang.org/src/syscall/env_unix.go?s=1927:1963#L83 , I guess your key include "=" or "\0" Here is a piece of POC code https://play.golang.org/p/HqLjQC--jzW @azachar

[Jeffwan]

Thanks @wjiangjay. I also meet this problem. When I create secret manually, forget to encode using base64. After I encode it and store in the secrets, everything works fine.

[ghost]

@Jeffwan np, really happy to share my experience about this.

[goswamig]

Thanks @wjiangjay I hit the same issue too and base encoding helped :)

[oalexandru]

Is it mandatory for the values of a secret to be encoded manually before? I find this quite strange, and also in the documentation about secret creation there's nothing related to this https://kubernetes.io/docs/concepts/configuration/secret/. My understanding was that the values get encoded automatically when the secret is created.

[baffinch]

Also an un-encoded secret for me too, thanks!

[jbg]

Is it mandatory for the values of a secret to be encoded manually before? I find this quite strange, and also in the documentation about secret creation there's nothing related to this https://kubernetes.io/docs/concepts/configuration/secret/. My understanding was that the values get encoded automatically when the secret is created.

@oalexandru If you create the object manually, you need to encode the values. For example, if you write the .yml file yourself and then use kubectl create -f mysecret.yml etc, then you need to base64-encode the secret values in the .yml file.

[andrewmunoz6]

@oalexandru I was wondering the same thing. I found this in docs: "Note: If you do not want to perform the base64 encoding, you can choose to use the stringData field instead."

In other words, you can create the secret using stringData and not encode the string yourself. When you save your secret, the string will be automatically encoded. Now if you edit the secret, you'll see "data:" with the encoded string instead of "stringData" with the decoded string. The alternative is to use "data:" and encode the string yourself. In this case "data:" will still appear in your secret when you save and edit.