coreos-kubernetes
coreos-kubernetes copied to clipboard
Projection of secret keys to specific paths does not work as described in the kubernetes docs
This issue was originally filed against kubernetes (kubernetes/kubernetes#32153), but in that thread it was confirmed that this couldn't be reproduced outside of the Vagrant multi-node setup (I've verified it myself on our own production clusters as well). As such, I thought it would be worth raising here since it does prevent the use of Secrets as described in the kubernetes docs.
I thought it would be worth mentioning that ConfigMaps can have only selected data items projected correctly, so the issue seems to be with just Secrets.
Since initially filing this, I've also upgraded my setup to use 1164.0.0 and I tried a couple of different versions of Hyperkube to see if I could identify when this may have broken, but had no luck with them:
- v1.4.0-beta.0_coreos.0
- v1.3.6_coreos.0
- v1.3.3_coreos.0
- v1.3.2_coreos.0
- v1.3.0_coreos.1
Is this a BUG REPORT or FEATURE REQUEST? (choose one):
Bug report
Kubernetes version (use kubectl version):
Client Version: version.Info{Major:"1", Minor:"3+", GitVersion:"v1.3.0-alpha.4", GitCommit:"9990f843cd62caa90445cf76b07d63ba7b5c86fd", GitTreeState:"clean", BuildDate:"2016-05-17T21:58:54Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.6+coreos.0", GitCommit:"f6f0055b8e503cbe5fb7b6f1a2ee37d0f160c1cd", GitTreeState:"clean", BuildDate:"2016-08-29T17:01:01Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"}
Environment:
- Cloud provider or hardware configuration: CoreOS Multi-Node Vagrant Cluster
- OS (e.g. from /etc/os-release):
NAME=CoreOS
ID=coreos
VERSION=1153.0.0
VERSION_ID=1153.0.0
BUILD_ID=2016-08-27-0408
PRETTY_NAME="CoreOS 1153.0.0 (MoreOS)"
ANSI_COLOR="1;32"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://github.com/coreos/bugs/issues"
- Kernel (e.g.
uname -a):
Linux w1 4.7.1-coreos #1 SMP Sat Aug 27 04:02:29 UTC 2016 x86_64 Intel(R) Core(TM) i7-4578U CPU @ 3.00GHz GenuineIntel GNU/Linux
- Install tools: CoreOS Multi-Node Vagrant Cluster
- Others: n/a
What happened:
Following the instructions/examples from the Using Secrets as Files from a Pod section of the Secrets reference documentation I tried projecting specific keys from a secret as outlined under the Projection of secret keys to specific paths bold.
When projecting only subset of the data stored in a secret as specified in the items section of my pod manifest's secret volume definition, instead I saw all of the keys from the secret being projected as if I had not specified any items at all.
What you expected to happen:
I expected only the specified subset of the secret Data to be projected on to the mounted volume within the pod, but instead all of the data in the secret was projected on to the volume.
How to reproduce it (as minimally and precisely as possible):
Using the examples from the Secret reference documentation:
-
Create
secret.ymlfile using the following example from the docs:apiVersion: v1 kind: Secret metadata: name: debug-secret type: Opaque data: password: MWYyZDFlMmU2N2Rm username: YWRtaW4= -
Create the secret using kubectl create:
kubectl create -f secret.yml -
Create a
debug-pod.ymlpod manifest that consumes the secret data:kind: Pod apiVersion: v1 metadata: name: debug-secret-pod spec: volumes: - name: debug-secret-volume secret: secretName: debug-secret items: - key: username path: testing/secret containers: - name: secret-debug-container image: gcr.io/google_containers/busybox command: ["ls", "-l", "/etc/secret-volume"] volumeMounts: - name: debug-secret-volume readOnly: true mountPath: /etc/secret-volume restartPolicy: Never -
Create the example pod using kubectl create:
kubectl create -f debug-pod.yml -
Get the
debug-secret-podlogs:kubectl logs debug-secret-pod
Assuming things are not working as described in the reference docs, you will see output like:
total 0
lrwxrwxrwx 1 root root 15 Sep 6 20:02 password -> ..data/password
lrwxrwxrwx 1 root root 15 Sep 6 20:02 username -> ..data/username
Anything else do we need to know:
I've verified that ConfigMaps can be used to project individual keys from data.
I recently find the subPath directive but it does not appear to be in the docs
#23748
I tried to project one config file from a config map into a file (not a directory) and it worked that way.
@ArchiFleKs - to be clear, projection of ConfigMap values works as expected. The issue in question is solely around the projection of individual items from a Secret.
Just to add to the issue since 1.4.0 was released, I've also verified that this issue is still around in 1.4.0.
Just a quick update, I updated to the latest version and tried this with K8S_VER=v1.4.6_coreos.0, still seeing the same issue.
I'd be happy to take a stab at figuring this out, but I'm not really sure where I should begin looking, so if anyone would be willing to provide pointers as to where to start, that'd be massively helpful and appreciated.
We have seen this problem but with OpenShift. It turned out to be a problem with the oc CLI that Openshift provides (and guess that it talks to the kubernetes API). By editing the yaml file form the Openshift graphical interface, it worked as expected.
Also we've seen that editing the yaml file a posteriori, the application reformatted that section as follows:
items:
- {key: username, path: testing/secret}
You might give this a try as well.