Kubernetes secret and base64 data

[odra]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

Mounting/using a kubernetes secret does not behave the same as kubernetes.

A kubernetes secret value is is usually encoded in base64:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
data:
  foo: YmFy

Mouting the above volume in a pod results in a file called "foo" with the conents "YmFy" instead of "bar".

Now there is a way to define non-base64 secret data by using stringData instead of data:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
stringData:
  foo: bar

In this case podman ignores stringData entirely and no file gets created.

Podman is dealing with data as if it was stringData and ignoring stringData entirely, which is not the expected behaviour if your compare it to kubernetes.

Steps to reproduce the issue:

1. Create a kubernetes secret in podman:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
data:
  foo: YmFy

3. Create a pod.yaml file that mounts the above secret in a volume:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: app
      image: fedora
      command: ["/usr/bin/sleep", "infinity"]
      volumeMounts:
        - name: mysecret
          mountPath: "/etc/mysecret"
          readOnly: true
  volumes:
    - name: mysecret
      secret:
        secretName: mysecret
        optional: false

5. Run podman kube play --replace pod.yaml

6. "Get into the container": odman exec -it mypod-app /bin/bash

7. Run cat /etc/mysecret/foo

Describe the results you received:

[root@mypod /]# cat /etc/mysecret/foo 
YmFy

This is what I get, the encoded base64 string, the expected value would be the decoded base64 value "bar".

Describe the results you expected:

This is the output I get from kubernetes (deploying the same yaml files):

$ kubectl exec -it mypod -- cat /etc/mysecret/foo
bar

I get the decoded value in my secret file which is what I would expect to happen in podman.

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

Client:       Podman Engine
Version:      4.3.1
API Version:  4.3.1
Go Version:   go1.18.7
Built:        Fri Nov 11 12:24:13 2022
OS/Arch:      linux/amd64

Output of podman info:

host:
  arch: amd64
  buildahVersion: 1.28.0
  cgroupControllers:
  - cpu
  - io
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.5-1.fc36.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.5, commit: '
  cpuUtilization:
    idlePercent: 98.5
    systemPercent: 0.33
    userPercent: 1.16
  cpus: 8
  distribution:
    distribution: fedora
    variant: workstation
    version: "36"
  eventLogger: journald
  hostname: 192.168.1.16
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 6.0.9-200.fc36.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 16167878656
  memTotal: 33395277824
  networkBackend: cni
  ociRuntime:
    name: crun
    package: crun-1.7-1.fc36.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.7
      commit: 40d996ea8a827981895ce22886a9bac367f87264
      rundir: /run/user/1000/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +WASM:wasmedge +YAJL
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-0.2.beta.0.fc36.x86_64
    version: |-
      slirp4netns version 1.2.0-beta.0
      commit: 477db14a24ff1a3de3a705e51ca2c4c1fe3dda64
      libslirp: 4.6.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.3
  swapFree: 19327344640
  swapTotal: 19327344640
  uptime: 20h 21m 33.00s (Approximately 0.83 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /home/lrossett/.config/containers/storage.conf
  containerStore:
    number: 14
    paused: 0
    running: 2
    stopped: 12
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/lrossett/.local/share/containers/storage
  graphRootAllocated: 417295147008
  graphRootUsed: 209961308160
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 34
  runRoot: /run/user/1000/containers
  volumePath: /home/lrossett/.local/share/containers/storage/volumes
version:
  APIVersion: 4.3.1
  Built: 1668180253
  BuiltTime: Fri Nov 11 12:24:13 2022
  GitCommit: ""
  GoVersion: go1.18.7
  Os: linux
  OsArch: linux/amd64
  Version: 4.3.1

Package info (e.g. output of rpm -q podman or apt list podman or brew info podman):

podman-4.3.1-1.fc36.x86_64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)

Yes, I built it from the main branch and got the same results.

Additional environment details (AWS, VirtualBox, physical, etc.):