coreos-kubernetes icon indicating copy to clipboard operation
coreos-kubernetes copied to clipboard

Projection of secret keys to specific paths does not work as described in the kubernetes docs

Open joonas opened this issue 9 years ago • 4 comments

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:

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

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:

  1. Create secret.yml file using the following example from the docs:

    apiVersion: v1
    kind: Secret
    metadata:
      name: debug-secret
    type: Opaque
    data:
      password: MWYyZDFlMmU2N2Rm
      username: YWRtaW4=
    
  2. Create the secret using kubectl create:

    kubectl create -f secret.yml
    
  3. Create a debug-pod.yml pod 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
    
  4. Create the example pod using kubectl create:

    kubectl create -f debug-pod.yml
    
  5. Get the debug-secret-pod logs:

    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.

joonas avatar Sep 09 '16 02:09 joonas

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 avatar Oct 02 '16 18:10 ArchiFleKs

@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.

joonas avatar Oct 02 '16 18:10 joonas

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.

joonas avatar Dec 02 '16 18:12 joonas

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.

baparici avatar Jan 27 '17 17:01 baparici