Kubernetes backend references non-existing pull secret: regcred

[hcsaustrup]

Component

agent

Describe the bug

Repository has registry secret for myregistry.tld Step in workflow references myregistry.tld/path/my-plugin:latest Agent creates build pod, but references non-existing pull-secret "regcred":

apiVersion: v1
kind: Pod
#...
spec:
  containers:
  - #...
    image: myregistry.tld/path/my-plugin:latest
    imagePullPolicy: Always
    name: wp-...
  #...
  imagePullSecrets:
  - name: regcred

System Info

docker.io/woodpeckerci/woodpecker-server:next (sha256:391eb21a843bf7e38bb4bfd5a529452e31733d90a494c6d3e783f8f1ac3630b3)
docker.io/woodpeckerci/woodpecker-agent:next (sha256:60a04e5b59bbec66bf5a61fc15fcbd8f4b44693602893d10e6f74270f21d2915)
kubernetes 1.28.2

Additional context

No response

Validations

• [X] Read the Contributing Guidelines.
• [X] Read the docs.
• [X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• [X] Checked that the bug isn't fixed in the next version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]
• [X] Check that this is a concrete bug. For Q&A join our Discord Chat Server or the Matrix room.

[zc-devs]

regcred it's hardcoded. What is name of your "registry secret for myregistry.tld"?

1897

[hcsaustrup]

The registry secret is the full hostname of the registry, in this example myregistry.tld.

Why would the pullsecret name be hardcoded if you can maintain a list of registries for each repository? I might be misunderstanding this, but I'd expect each repository to have their own pullsecret containing all listed registries, which would be made available to the pod running the workflow.

(Obviously there is a bit of a security flaw with images being cached on the host, but that's a whole different can of worms unrelated to this)

[qwerty287]

Isn't this fixed by #3016?

[zc-devs]

Repository has registry secret

I think @hcsaustrup meant this functionality. Draft is in #3122.

3016 is kind of a workaround, it is deployment-wide (at least namespace-wide behind Agent). While it may work well for individual, it won't suit SaaS (like Codeberg) as well as enterprises, I think.