Argo-cd: With GPG enabled, trustdb.gpg cannot be created on OpenShift/OKD

[niiku]

Describe the bug

Since v1.7.0-rc1 GPG is enabled by default. When the argocd-repo-server container isn't running as 999 (argocd user) the trustdb.pgp file in the /app/config/gpg/keys/ directory cannot be created. This affects deployments in OpenShift which uses random UIDs (e.g. 1000580000) for containers by default.

To Reproduce

• Run Argo CD v.1.7.0-rc1 in OpenShift without changing the default SCC (=restricted, using random UIDs)
• OR, presumably: Run argocd-repo-server container with an UID other than 0 or 999 (e.g. runAs: 1000580000)

Expected behavior

/app/config/gpg/keys/trustdb.pgp can be created even when the argocd-repo-server container isn't running as UID 999.

Version

$ argocd version
argocd: v1.7.0-rc1+4728412
  BuildDate: 2020-08-15T19:29:42Z
  GitCommit: 4728412cc315437c08c660ea1e58d6de432a6e4a
  GitTreeState: clean
  GoVersion: go1.14.1
  Compiler: gc
  Platform: linux/amd64

Logs

time="2020-08-19T21:59:22Z" level=info msg="Initializing GnuPG keyring at /app/config/gpg/keys"
time="2020-08-19T21:59:22Z" level=fatal msg="stat /app/config/gpg/keys/trustdb.gpg: permission denied"

Using emptyDir

time="2020-08-19T22:19:59Z" level=info msg="Initializing GnuPG keyring at /app/config/gpg/keys"
time="2020-08-19T22:19:59Z" level=fatal msg="ARGOCD_GNUPGHOME at '/app/config/gpg/keys' has too wide permissions, must be 0700"

I've tried using an emtpyDir at /app/config/gpg/keys but then during the InitializeGnuPG an error is returned.

As far as it seems, emptyDirs can only be mounted as 777 (https://github.com/kubernetes/kubernetes/issues/76158). An idea to resolve this could be if gpg.go creates the keys directory itself with the correct permissions in an emptyDir.

Current workarounds I see:

• Set ARGOCD_GPG_ENABLED to "false"
• Add SecurityContextConstraint nonroot to ServiceAccount

[jannfis]

Hey, thanks for this report. I haven't thought about OpenShift and its way to randomly generate UIDs for pods to be honest. But yeah, this is an issue with the current implementation.

I think, we could also just use an emptyDir mount for /app/config/gpg/keys and skip the permission check all-together, along with suppressing the permission warnings from gpg. Probably, the security implications on this are negligible in case of the argocd-repo-server pod, since every process spawned from the repo server will be running with the same UID as the repo server itself, too (and thus, also has same permissions on the file system). emptyDir would also have the benefit of being able with a read-only rootfs policy on the pod.

I have already prepared a patch which is under testing right now, will send in this evening.

[jessesuen]

Since v1.7.0-rc1 GPG is enabled by default

@jannfis @alexmt Is this true? I thought this feature was opt-in

[jannfis]

@jessesuen The feature is enabled by default, but enforcement is opt-in (i.e. you have to configure a project to enforce validation, and then assign applications to this project). However, the functions for managing the keys are active all times - and this is where this bug is at.