podman
podman copied to clipboard
podman secrets --driver=pass hardware token
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
secrets with --driver=pass uses new gpg-agent (systemd) causing hardware tokens like yubikey to not work (since they require user authentication)
Steps to reproduce the issue:
- Create password store using gpg key with hardware token e.g.: https://support.yubico.com/hc/en-us/articles/360013790259-Using-Your-YubiKey-with-OpenPGP
- Create podman secret
echo test1 | podman secret create --driver=pass pass_secret -
a461f4dee15d5e915cc686ff2
- Read secret in container
podman run --rm -it --secret pass_secret alpine cat /run/secrets/pass_secret
Describe the results you received: Error: a461f4dee15d5e915cc686ff2: no secret data with ID
Describe the results you expected: test1
Additional information you deem important (e.g. issue happens only occasionally):
This fixes the issue:
rm ~/.gnupg/S.gpg-agent*
ln -s {$XDG_RUNTIME_DIR/gnupg/,~/.gnupg/}S.gpg-agent
Although I would not say this is a good solution.
strace shows podman trying to access /run/user/0 probably in order to read /run/user/0/gnupg/S.gpg-agent rather than ${XDG_RUNTIME_DIR}/gnupg/S.gpg-agent of user 1000 so I suspect that this is a user namespace problem, but have not verified.
Output of podman version:
Version: 3.4.4
API Version: 3.4.4
Go Version: go1.17.3
Built: Thu Jan 1 01:00:00 1970
OS/Arch: linux/amd64
Output of podman info --debug:
host:
arch: amd64
buildahVersion: 1.23.1
cgroupControllers:
- memory
- pids
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: 'conmon: /usr/bin/conmon'
path: /usr/bin/conmon
version: 'conmon version 2.0.25, commit: unknown'
cpus: 12
distribution:
codename: jammy
distribution: ubuntu
version: "22.04"
eventLogger: journald
hostname: redacted
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: 5.15.0-22-generic
linkmode: dynamic
logDriver: journald
memFree: 59369926656
memTotal: 67339329536
ociRuntime:
name: crun
package: 'crun: /usr/bin/crun'
path: /usr/bin/crun
version: |-
crun version 0.17
commit: 0e9229ae34caaebcb86f1fde18de3acaf18c6d9a
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
os: linux
remoteSocket:
exists: true
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: /usr/bin/slirp4netns'
version: |-
slirp4netns version 1.0.1
commit: 6a7b16babc95b6a3056b33fb45b74a6f62262dd4
libslirp: 4.6.1
swapFree: 4294963200
swapTotal: 4294963200
uptime: 2h 59m 54.93s (Approximately 0.08 days)
plugins:
log:
- k8s-file
- none
- journald
network:
- bridge
- macvlan
volume:
- local
registries:
search:
- redacted
store:
configFile: /home/redacted/.config/containers/storage.conf
containerStore:
number: 3
paused: 0
running: 1
stopped: 2
graphDriverName: overlay
graphOptions: {}
graphRoot: /home/redacted/.local/share/containers/storage
graphStatus:
Backing Filesystem: extfs
Native Overlay Diff: "true"
Supports d_type: "true"
Using metacopy: "false"
imageStore:
number: 28
runRoot: /run/user/1000/containers
volumePath: /home/redacted/.local/share/containers/storage/volumes
version:
APIVersion: 3.4.4
Built: 0
BuiltTime: Thu Jan 1 01:00:00 1970
GitCommit: ""
GoVersion: go1.17.3
OsArch: linux/amd64
Version: 3.4.4
Package info (e.g. output of rpm -q podman or apt list podman):
podman/jammy,now 3.4.4+ds1-1ubuntu1 amd64 [installed]
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/No Latest on ubuntu jammy, have not compiled 4.0.x
Additional environment details (AWS, VirtualBox, physical, etc.):
@ashley-cui PTAL
A friendly reminder that this issue had no activity for 30 days.
A friendly reminder that this issue had no activity for 30 days.
@cdoern @ashley-cui Any movement on this?
@rhatdan I have a PR open in c/common but the tests are near impossible. the fix works I know that so I might look for a way to merge with minimal new tests b/c the more I try to make a test the more I break other things...
A friendly reminder that this issue had no activity for 30 days.
Coming back to this during this week
A friendly reminder that this issue had no activity for 30 days.
@cdoern any update?
Is there an update here? I unfortunately also have the problem.
@ashley-cui PTAL
I have a pr open for this but the issue is, it's not testable
@k33pn3xtlvl Care to test @cdoern PR? @cdoern what is the PR?
Has this issue gone stale?
This is the commit @rhatdan https://github.com/cdoern/common/commit/98cfad7c318647ddb0d70ba2259f034862d5a033 the issue is lack of testability.
Did it get merged? Is there a PR? Just don't add a test and we can ask users like @lex-ibm to test it out.
Count me in
Underlying problem here is that when gpg is invoked by podman, it does not detect running gpg-agent (with socket in /run) but instead launches a new agent with socket in .gnupg. New agent obviously has no keys, so decryption fails.
It is not clear to me why agent is not found - probably something to do with the context in which podman invokes gpg.
A workaround is to put the following text in ~/.gnupg/S.gpg-agent:
%Assuan%
socket=/run/user/1000/gnupg/S.gpg-agent
After this gpg is able to find existing agent, and decryption works as expected.
Is this an environement variable thing? Do we need to pass a Environment variable from the podman environment through to the GPG to allow it to find it. I believe by default we remove the environment when we exec GPG.
Is this an environement variable thing?
I don't think so - GPG uses hardcoded socket paths, and according to here https://github.com/containers/common/blob/main/pkg/secrets/passdriver/passdriver.go#L162, podman passes through environment variables anyway.
I think there's 2 separate issues here:
The one mentioned by @cdoern is related to the ability of gpg and friends to talk to the correct TTY to ask for auth. I have not run into this issue myself since GPG pops up a GUI dialog to ask for my pin or other info.
The second issue is that GPG is not connecting to the default/running agent at the correct path (as seen in gpgconf --list-dirs) but is instead trying to start it's own agent at a different location. That's why the mentions above of symlinking (with ln or a config file) bypasses the issue. This could indeed be related to a missing environment variable. @uosis is correct that podman sets the environment before calling GPG, however I believe the driver is called from a context in which the environment has already been filtered by podman, so os.Environ() no longer contains the correct variables.
For me, these issue(s) present as gpg repeatedly popping up a GUI dialog asking me to insert my security key, since (I assume) the agent it starts can't communicate with the key via sc-daemon.
Also I think #19382 is related and possibly a duplicate
@ashley-cui WDYT?